Introduction Maîtriser l'automatisation avec le guide complet GitLab CI/CD

Maîtriser GitLab CI/CD: Introduction

L'Intégration et le Déploiement Continus (CI/CD)

Dans le cycle de développement moderne, l'efficacité repose sur deux piliers indissociables : le CI (Continuous Integration) et le CD (Continuous Deployment). GitLab CI automatise la gestion et les tests de vos projets à chaque envoi de code, tandis que le CD prend le relais pour placer automatiquement ces changements validés en production.

Imaginez une chaîne de montage automobile ultra-moderne. Le CI est le scanner laser qui vérifie chaque soudure en temps réel. Le CD est le bras robotisé qui place la voiture finie sur le camion de livraison dès qu'elle est validée. Grâce à ce système, vous détectez les erreurs immédiatement et déployez sur la branche main en toute sérénité.

Le fichier .gitlab-ci.yml : Le Chef d'Orchestre

Qu'est-ce que ce fichier et pourquoi est-il vital ?

Le fichier .gitlab-ci.yml est le cerveau de votre automatisation. C'est un fichier texte au format YAML que vous devez impérativement placer à la racine de votre dépôt. Sans lui, GitLab n'est qu'un simple espace de stockage, avec lui, il devient une usine logicielle intelligente.

C'est une recette de cuisine technique : dès que vous effectuez un push, GitLab lit ce fichier et délègue les instructions aux GitLab Runners. Il permet de standardiser vos méthodes de travail : peu importe l'ordinateur du développeur, le code sera toujours testé et déployé de la même manière.

"Visualisation du flux de travail CI avec GitLab"

Anatomie du pipeline : Stages et Jobs

Le fonctionnement de votre pipeline CI/CD repose sur une hiérarchie stricte définie dans le fichier :

• Les Stages (Étapes) : Ils définissent la chronologie (ex: d'abord on build, ensuite on teste). Un stage ne démarre que si le précédent est réussi.
• Les Jobs (Tâches) : Ce sont les scripts réels (ex: npm test). Plusieurs jobs peuvent tourner en parallèle au sein d'un même stage pour gagner du temps.

Implémentation pratique du pipeline

Voici une configuration YAML complète pour une application Node.js :

stages:
  - build
  - test
  - deploy

job_compilation:
  stage: build
  image: node:22-alpine
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

job_tests_unitaires:
  stage: test
  image: node:22-alpine
  script:
    - npm test

job_deploiement_prod:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Déploiement sur le serveur de production..."
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Les Stages : La chronologie de votre projet

La directive stages est la colonne vertébrale de votre automatisation. Elle définit l'ordre chronologique dans lequel vos tâches vont s'exécuter. Dans votre exemple, nous avons trois étapes clés : build (construction), test et deploy (déploiement).

Imaginez une chaîne de montage automobile. Les stages garantissent que l'on ne peint pas la voiture (déploiement) avant d'avoir vérifié si le moteur fonctionne (test) et on ne teste pas le moteur avant de l'avoir assemblé (build). Si une étape échoue, GitLab arrête tout immédiatement pour protéger votre production.

Le Job : L'ouvrier spécialisé

Un job est une unité de travail concrète. Dans votre code, job_compilation ou job_tests_unitaires sont des jobs. Chaque job doit être rattaché à un stage.

• image : C'est l'environnement de travail (le conteneur Docker). Utiliser node:22-alpine garantit que votre code s'exécute avec la version exacte de Node.js dont il a besoin.
• script : C'est le cœur de l'action. Ce sont les commandes terminal que le Runner va taper à votre place. La commande npm ci installe les dépendances de manière rapide et ultra-fiable.

Les Artifacts : Transmettre les résultats

Par défaut, chaque job démarre dans un environnement totalement vide. Lorsqu'un job de compilation crée un dossier dist/, ce dossier disparaît dès que le job est fini.

Les artifacts permettent de "sauver" des fichiers pour les transmettre aux jobs suivants. Ici, le dossier de compilation est conservé pour que le job de déploiement puisse l'utiliser plus tard.

Les Rules : L'intelligence conditionnelle

Le mot-clé rules apporte une intelligence de décision à votre pipeline. Vous ne voulez pas déployer sur votre serveur de production à chaque fois qu'un développeur fait un test sur une petite branche isolée.

Dans votre code, la règle utilise des Variables CI/CD prédéfinies :

if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Cela signifie : "N'exécute ce job de déploiement QUE si le code est poussé sur la branche par défaut (généralement main)". C'est votre sécurité anti-erreur humaine.

Exécution du pipeline

Voici ce que verra un développeur dans sa console GitLab lors du lancement de ce pipeline après un push sur la branche principale.

Sortie terminal - Statut global :

Pipeline #458712 started for branch 'main'

[Stage: build]
- job_compilation: RUNNING...
  $ npm ci
  $ npm run build
  Uploading artifacts... dist/ (2.4MB)
  Job succeeded

[Stage: test]
- job_tests_unitaires: RUNNING...
  $ npm test
  7 runs, 15 assertions, 0 failures
  Job succeeded

[Stage: deploy]
- job_deploiement_prod: RUNNING...
  $ echo "Déploiement sur le serveur de production..."
  Job succeeded

Pipeline succeeded in 2m 54s

Conclusion

Le couple CI/CD et son fichier .gitlab-ci.yml transforment radicalement votre quotidien de développeur. Vous passez d'un mode manuel stressant à un flux automatisé, fiable et rapide.

Cependant, pour que votre pipeline puisse interagir avec vos serveurs en toute sécurité, il ne faut jamais écrire vos mots de passe en clair dans ce fichier. Dans le prochain chapitre, nous allons apprendre à utiliser les Variables CI/CD pour protéger vos secrets.