DevOps : Vercel, Heroku, & integration continue

Principe de deploiement

Il existe plusieurs solutions gratuite pour l'hébergement de son site, Netlify, ou encore GitHubPages, tous ont leurs avantages et, et inconveignants, j'ai choisi: Vercel pour le front. Etant donné que ce site est développé en Next.js et que Vercel a aussi développé Next.js, j'ai choisi ce dernier

Vercel

Contrairement à Heroku, je n'ai pas éprouvé de grandes difficultés à comprendre les bases de l'hébergement sur Vercel.

Il m'a fallu choisir le type de langage :

Et y insérer les variables d'environnement :

j'ai ajouter le fichier .vercelignore qui content :

1utils

dossier que je ne veux pas héberger sur la partie front.

et bien sur connecté la branche de github que se verra être déployée

pas de grandes difficultées donc.

Heroku

c'est une autre paire de manches !

Même chose, connecter la branche voulu, facile.

puis ça se complique dans les variables d'environnement :

1# MongoDB :
2USERNAME: ***
3PASSWORD: ***
4CLUSTER: cluster
5DB_DEV: ***
6DB_PROD: ***
7
8APOLLO_KEY: service:***
9APOLLO_GRAPH_REF: ***@current
10APOLLO_SCHEMA_REPORTING: true
11
12PROJECT_PATH: utils
13

Les informations renseignées concernant Apollo permettent de travailler sur une interface instanciée en ligne de Graphiql, c'est plutôt pratique, les schémas sont sauvegardés et exportables !

1PROJECT_PATH

.., c'est lui qui m'a causé le plus de difficultés. J'ai pris la décision de travailler sur un Mono-repo, peut être m'y suis je mal pris, mais j'aime mon architecture simple: le back dans le dossier du front.

Il est dit, sur l'internet, que déployer un dossier dans un dossier c'était facile, .. que nenni ! il m'a fallu, ajouter cette config :

1PROJECT_PATH: utils

et jouer avec les BuildPacks, il y a du bon sens la dedans, pour faire tourner un server node, il faut node, mais ce n'est pas tout. Pour acceder a un dossier dans un dossier racine, ile ne suffit malhereusement pas de "PROJECT_PATH", il faut lui forcer la main avec ce Buildpack

Bien sur il ne faut aucun fichier partagé entre les 2 projets.

Tests et integration continue (CI)

GitHub actions

Les tests d'intégration continue sont géniaux, ils permettent d'exécuter des tâches avant un déploiement, en fonction de sa configuration, en cas d'échecs, le déploiement peut ne pas se faire.

voici celui que j'utilise :

1name: Build - yarn lint & build
2
3on:
4  pull_request: { branches: master }
5  push: { branches: master }
6
7jobs:
8  build:
9    runs-on: ubuntu-latest
10    env:
11      PRODUCTION_URI: ${{ secrets.PRODUCTION_URI }}
12
13    steps:
14      - uses: actions/checkout@v2
15      - uses: actions/setup-node@v1
16        with:
17          node-version: 16.13.0
18
19      - run: npm install -g yarn
20      - run: yarn install --frozen-lockfile
21
22      - name: Test if yarn build succeeds
23        run: yarn build && echo "👌 yarn build proceeds successfully"
24
25      - name: Test if ESLint succeeds
26        run: yarn lint && echo "🥳 ESLint proceeds successfully
27

On installe node sur unbuntu, on lance le server, on build le projet, et on vérifie si ESlint nous a trouvé des erreurs.

j'ai choisi l'url de la production pour récupérer les données, je n'ai pas réussi à lancer les 2 servers.

quoi qu'il en soit .. comme souvent, ici la difficulté a été de mettre en place la variable d'environnement, finalement après quelques recherches, et farfouillage, j'ai trouver a zone : Settings/Security/Secrets/Actions sur GitHub, vous devrez faire vos recherches pour GitLab.