Pipeline CI/CD : concevoir son propre robot de déploiement

L’automatisation n’a rien d’étrange

La dernière fois, j’ai retenu une leçon douloureuse à travers 10 minutes de downtime et un rapport d’incident. Le déploiement n’est pas de la magie : il doit être une succession de garde-fous stricts, “Git, trace – Test, vérification – Build, emballage – Deploy, livraison”.

Désormais, l’objectif est clair. Je ne peux pas continuer à vérifier moi-même, à chaque fois, tous ces garde-fous complexes et pénibles. Il me faut un “robot consciencieux” capable de travailler à ma place, même après mon départ du bureau ou pendant mes vacances.

« L’automatisation ? Ce n’est pas un peu trop ambitieux ? »

Au début, cela m’a fait peur, mais en y réfléchissant bien, j’avais déjà vécu quelque chose de très similaire. C’était “Docker”, dont nous avons parlé dans la série précédente.

Quand nous écrivons dans un Dockerfile « installe Ubuntu, installe Java, copie le code », Docker le lit et construit tout seul l’environnement du serveur. Grâce à cela, nous avons été libérés du travail pénible consistant à taper les commandes à la main.

Un “pipeline CI/CD”, c’est exactement la même idée. Si Docker a automatisé la “mise en place du serveur”, alors le pipeline automatise “l’ensemble du processus de déploiement”. La seule différence, c’est que la scène s’est élargie : on est passé de mon ordinateur à un monde plus grand, celui de “GitLab et du serveur de production”.

CI/CD : le tapis roulant automatisé

Installons maintenant une “ligne automatisée” dans notre “centre logistique numérique”. Cela paraît grandiose, mais le principe est simple.

1. CI (Continuous Integration, intégration continue)

• Signification : « Fusionner et vérifier en continu le code des développeurs en un seul ensemble. »
• Rôle : [build + test]. C’est l’étape où, dès que j’envoie mon code, la machine vérifie pour moi : « La syntaxe est-elle correcte ? », « Les fonctionnalités existantes ne sont-elles pas cassées ? ». Les produits défectueux sont écartés ici.

2. CD (Continuous Delivery/Deployment, livraison ou déploiement continus)

• Signification : « Livrer au client le code qui a passé les vérifications. »
• Rôle : [création de l’image + déploiement sur le serveur]. C’est l’étape où le produit conforme (Docker Image) qui a passé les contrôles est chargé dans un camion, envoyé vers le serveur de production, puis mis en marche.

Le plan du pipeline : .gitlab-ci.yml

« Alors, comment donne-t-on du travail à ce robot ? » Dans GitLab, il suffit de créer un fichier nommé .gitlab-ci.yml à la racine du projet. C’est précisément la “fiche d’instructions de travail” que l’on remet au robot.

Vous vous souvenez de la douleur du déploiement manuel que j’ai vécue la dernière fois ? Reprenons exactement ce processus et traduisons-le en code. Comme lorsqu’on écrit un Dockerfile, il suffit de le coucher ligne par ligne.

# .gitlab-ci.yml (la fiche de tache)

stages:          # 1. Definir l'ordre de toute la tache
  - test         #   (Etape 1 : verification)
  - build        #   (Etape 2 : empaquetage)
  - deploy       #   (Etape 3 : livraison)

# [Etape 1] Test : machine, verifie que mon code est bon (CI)
unit_test_job:
  stage: test
  image: openjdk:17-alpine # A executer dans un environnement avec Java
  script:
    - ./gradlew test       # "Lance les tests !" (evite l'erreur precedente)

# [Etape 2] Build : si les tests passent, en faire une image (CI)
build_image_job:
  stage: build
  image: docker:latest     # A executer dans un environnement avec Docker
  script:
    - docker build -t my-app:v1 .  # "Cree l'image !"
    - docker push my-regisry/my-app:v1 # "Pousse vers le registre !" (tag de rollback obligatoire)

# [Etape 3] Deploy : pose-le sur le serveur de prod (CD)
deploy_job:
  stage: deploy
  script:
    - ssh user@server "docker service update my-app" # "Mets a jour le serveur !"

Ce seul fichier suffit. Au moment même où je fais un git push, c’est-à-dire au trigger, GitLab lit cette fiche d’instructions et réveille un robot ouvrier appelé “GitLab Runner” pour le mettre au travail.

[Check] Les garde-fous que nous devons prévoir

Dans ce pipeline sont intégrés les trois garde-fous que j’ai ressentis si douloureusement la dernière fois.

1. Git (Trigger) :
   • Le simple fait de faire un push de mon code depuis ma machine locale devient le “bouton de démarrage” du pipeline. S’il ne reste aucune trace (Commit), le déploiement ne démarre pas non plus.
2. Unit Test (Quality Gate) :
   • Et si un test échoue dans unit_test_job ? Le pipeline “s’arrête (Fail)” immédiatement. Il empêche à la source tout produit défectueux de passer à l’étape suivante (build/déploiement). (Impossible désormais de sauter les tests sous prétexte qu’on est débordé !)
3. Docker Image (Artifact) :
   • L’image créée lors de l’étape de build est stockée en toute sécurité sur Docker Hub. Même si le serveur plante plus tard, tant qu’on a cette image, on peut le restaurer en une seconde.

Conseil pratique : un pipeline est un être vivant

N’essayez pas d’écrire un pipeline parfait dès le départ. Moi aussi, au début, je n’avais créé que deux étapes, build et deploy, et ce n’est qu’après avoir causé un incident que j’ai ajouté l’étape test en amont.

• Phase initiale : build -> déploiement (l’essentiel était d’automatiser)
• Phase intermédiaire : test -> build -> déploiement (ajout de garde-fous)
• Phase avancée : test -> analyse statique (SonarQube) -> build -> déploiement sur le serveur de dev -> (validation) -> déploiement sur le serveur de production

Un pipeline est un “système vivant” qui continue d’évoluer au rythme de la croissance de notre équipe.

Pour conclure : les instructions sont écrites, mais qui fait réellement le travail ?

Désormais, le plan parfait, .gitlab-ci.yml, est terminé. Mais une fiche d’instructions écrite sur le papier ne bouge pas toute seule. De la même manière qu’un Dockerfile a beau exister, il ne peut pas s’exécuter sans Docker Daemon, la fiche d’instructions du pipeline a elle aussi besoin d’un “robot de terrain” qui sue réellement pour construire et exécuter le code.

Le nom de ce robot est “GitLab Runner”. Le chef d’usine, c’est-à-dire le GitLab Server, ne fait que donner les ordres. Le travail concret est réalisé par ce runner.

La prochaine fois, installons ce runner sur mon ordinateur ou sur un serveur séparé, relions-le à GitLab et faisons réellement fonctionner le pipeline. C’est enfin le moment où le premier bouton de l’automatisation se ferme.