Déploiement continu avec Gitlab

Introduction

Dans ce laboratoire, nous allons voir comment réaliser un déploiement en continu à partir de Gitlab ainsi que l'intégration des commentaires des utilisateurs sur la plateforme de "versionning". Pour le déploiement, vous utiliserez Render qui propose du PaaS ("Platerforme as a Service"). Le principe est que le code y sera envoyé en fonction de vos commits et c'est la plateforme qui se chargera de mettre votre application en ligne. Ce site propose une offre gratuite qui permet de facilement faire des tests pour voir si tout fonctionne. Notez juste que si votre application est inactive pendant un certain délai, l'application va se mettre "au repos". Il faudra alors un petit délai pour qu'elle se "réveille" lors d'une requête.

Nous allons avoir 2 environnements distincts : staging et production. Le premier nous permettra de mettre en ligne une version "test" pour que les utilisateurs puissent donner leurs avis sur le projet (suggestions de fonctionnalités, bugs, ergonomie, etc). Le second correspond à la version publique (que tout le monde utilise). Nous ne pourrons donc envoyer le projet que lorsque tout sera validé.

Dans ce laboratoire, nous utiliserons à nouveau la dernière version de NodeJS. Comme pour le précédent laboratoire, aucune connaissance à propos de cet outil ne sera nécessaire. Le but sera de déployer une API ("Application Programming Interface") en ligne. De nouveau, vous n'êtes pas obligés d'en comprendre le fonctionnement pour faire le laboratoire. Sachez juste que le serveur ne renverra pas des pages en HTML, mais du contenu au format JSON. Si vous désirez en apprendre plus sur les API à la fin de ce laboratoire, vous pourrez commencer par la page Wikipédia : https://fr.wikipedia.org/wiki/Interface_de_programmation

Etape 1: création du compte

Rendez-vous sur la plateforme Render et inscrivez-vous en utilisant votre compte Gitlab.

Etape 2: mise en place des pipelines

Créez un nouveau répository sur Gitlab laboratoire 3. Cette fois-ci, nous allons créer deux branches: develop et staging.

attention

N'oubliez pas de protéger ces branches !

Avant de continuer sur GitLab, retournez sur le site Render et nous allons préparer nos serveurs web pour le déploiement en continu ! Sur le dashboard, cliquez sur "web services"

Connectez votre compte Gitlab (menu à droite) et une fois cela fait, choisissez le repository que vous avez créé en début de laboratoire (cliquez sur "connect"). Remplissez le formulaire pour avoir ces informations :

Vous devriez avoir ceci à la fin:

Créez un deuxième service, mais pour la branche main. Recommencez le processus, mais en changeant les "staging" par "main".

Retournez sur la page principale de votre repository, choisissez la branche develop et utilisez le Web IDE. Supprimez le fichier présent et mettez tous les dossiers et fichiers du code fourni (dans ce fichier zip) dans le repository. Vous devriez avoir cette structure:

• routes/
  • index.js
• src/
  • fibonacci.js
  • padovan.js
  • syracuse.js
• test/
  • fibonacci.test.js
  • padovan.test.js
  • syracuse.test.js
• package.json
• package-lock.json
• vitest.config.ts
• .eslintrc.cjs

Quand vous voudrez effectuer un push, GitLab vous demandera si vous voulez créer une nouvelle branche. Répondez oui et donnez un nouveau nom (souvenez-vous que la branche develop est protégée et qu’on ne peut pas envoyer du code directement dessus).

Exercice 1: création des pipelines et artifacts

Créez un fichier .gitlab-ci.yml et complétez-le. Il vous est conseillé de vous inspirer de ce qui a été fait au laboratoire précédent. Cependant, vous avez des consignes légèrement différentes cette fois:

• Vous devez avoir 2 jobs test et lint.
• test sert à lancer les tests unitaires (comme la dernière fois), mais en plus il devrait générer un "artifact" (le dossier "coverage"). Consultez la documentation à ce sujet : https://docs.gitlab.com/ee/ci/jobs/job_artifacts.html.
• lint est un job qui sert à savoir si le code respecte les conventions de codage (espaces aux bon endroits, noms corrects, etc). Pour exécuter ce job, vous devrez exécuter cette commande : npm run lint.
• Le job test doit se lancer sur toutes les branches sauf main. Le job lint doit se lancer sur les branches develop et staging
• Ces deux jobs doivent s’exécuter en parallèle
• Ces deux jobs doivent faire partie du stage build (le nom n’est pas idéal, vous pouvez en choisir un autre si vous le désirez).

Dans la merge request que vous allez créer, n’oubliez pas de choisir develop ! La branche main est celle choisie par défaut. Effectuez ensuite la fusion des branches.

Répétez l’opération en créant une deuxième merge request develop -> staging. Une fois le merge effectuée, répétez l’opération de staging -> main.

Maintenant, testons que tout fonctionne ! Allez sur le service du staging. Vous pouvez voir une url qui permet d'aller sur le site.

Utilisez cette adresse en y ajoutant les bons paramètres dans l’URL /fibonacci?number=10, ce qui donne dans mon cas : https://staging-956d.onrender.com/fibonacci?number=10. Vous devriez voir ceci :

Ce qui n’est malheureusement pas la bonne réponse…

Etape 3: Helpdesk

En effet, l’application envoyée sur Render ne peut pas fonctionner. Nous allons donc devoir la corriger ! Nous allons simuler un client qui remarque ce bug sur la version de test et qui vous envoie un mail à ce sujet. Gitlab dispose d’un service permettant de réceptionner les emails rapportant des bugs, des manques de fonctionnalités, des demandes de corrections, etc. Allez dans les paramètres de répertoire et regardez la section "Service Desk". Vous devriez trouver le mail en question. Il vous suffit d’envoyer un email à cette adresse avec une pièce jointe (la capture d’écran du bug) et avec un petit message signalant que l’application ne fonctionne pas.

Dans les "issues", vous devriez voir l’email envoyé. Répondez que le bug sera rapidement corrigé via le système de commentaires. Vous verrez que vous recevrez une réponse via mail. Ce qui est très pratique pour que le client voit que sa remarque est bien prise en compte.

Créez une nouvelle branche à partir de develop et faites les corrections nécessaires dans les fichiers présents dans le dossier src. Au moment de la création de la "merge request", ajoutez une description en citant le numéro de l'issue. Pour cela, tapez # et choisissez l'issue voulue. Ceci aura pour conséquence de voir la progression de la résolution du bug dans l'issue. Allez voir, vous devriez voir la "merge request" en question :

Créez une seconde "merge request" de develop vers staging. N'oubliez pas de citer l'issue dans la description de la "merge request". Si tout est bon, fusionnez les branches et attendez que le déploiement soit terminé.

Vérifiez sur Render.com si tout est bon. Vous pouvez même vous amuser à tester le système. Vous devriez voir uniquement des bonnes réponses 😊

Maintenant, il faut signaler au client que tout est bon. Ajoutez un commentaire et cliquez sur "Comment and close". Vous devriez recevoir un email vous indiquant que le bug est réglé.

Exercice 2:

Il ne nous reste plus qu'à envoyer le tout en production. Modifiez le fichier .gitlab-ci.ymlpour ajoutez un nouveau stage production. Dans ce stage, vous aurez 2 jobs : test_manual et lint_manual qui ne devront se lancer que sur la branche main. Cependant, ils doivent être des jobs manuels ! Parfois, on souhaite que certains jobs ne se lancent pas automatiquement, mais uniquement suite à la demande d’une personne. N’hésitez pas à aller voir la documentation pour savoir comment faire : https://docs.gitlab.com/ee/ci/yaml/

Les modifications du fichier .gitlab-ci.yml seront "merges" dans develop, puis dans staging et ensuite dans main. Si tout est bon, vous verrez un résultat particulier dans la dernière "merge request". En cliquant dessus, vous arriverez à l’interface permettant d’enclencher le job.

Vous pouvez enclencher les deux jobs en même temps ou uniquement un des deux. Vous pouvez également retrouver ces deux jobs dans le menu "CI/CD" -> "Jobs".

Exercice 3: touche finale

Nous avons brièvement parlé des "artifacts" dans ce laboratoire. Mais avez-vous trouvé où on pouvait récupérer ce document ? Vous aurez surement vu qu’il fallait se rendre dans le "job" produisant le document pour le récupérer… Ce n’est pas très pratique. De plus, il est souvent problématique de laisser n’importe qui accéder aux "pipelines". Il n’est pas non plus envisageable que chaque développeur vous demande les documents… Vous risquez d’y passer des journées entières. La solution est de rendre ce document accessible depuis les "merge requests". Vous devrez apporter une petite modification à votre fichier .gitlab-ci.yml pour y arriver. Voici le lien vers la documentation : https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html Essayez également que l'artifact soit toujours généré même si les tests échouent. Faites-en sorte que le nom du document soit personnalisé et qu’il soit optimisé (tout le contenu du dossier "coverage" n’est pas nécessaire).

Conclusion

Dans ce laboratoire, nous avons appris comment mettre en place un système de déploiement continu. Vous comprenez l'intérêt de cette approche, permettant de rendre accessible les dernières nouveautés de notre projet. Nous savons ainsi comment recueillir les remarques des utilisateurs et les gérer dans notre flux de travail.