Intégration et déploiement continus : principes, pipeline, environnements

Objectif

Comprendre pourquoi les équipes automatisent leurs tests et leurs mises en production, ce que recouvrent exactement les sigles CI et CD, comment se découpe un pipeline, et à quoi servent les environnements. Vous écrirez ensuite votre premier pipeline… en simple shell, pour bien voir ce qu'un outil comme GitHub Actions ou GitLab CI automatise.

L'essentiel

• Intégration continue (CI) : chaque modification poussée est construite et testée automatiquement, plusieurs fois par jour, pour détecter les problèmes tout de suite.
• Livraison continue (continuous delivery) : chaque version qui passe la CI est prête à partir en production ; la mise en production reste un clic humain.
• Déploiement continu (continuous deployment) : chaque version qui passe tous les contrôles part automatiquement en production.
• Un pipeline enchaîne des étapes (lint, tests, build, déploiement) ; la première qui échoue arrête tout.
• Les environnements (développement, recette/staging, production) permettent de valider une version avant qu'elle n'atteigne les clients.
• Principe central : on construit une seule fois et on déploie le même artefact partout.

1. Le problème : « ça marche sur mon poste »

À l'agence Atlas Web (Casablanca), avant l'automatisation, une mise en production ressemblait à ceci :

• le vendredi soir, Youssef fusionne trois semaines de travail de quatre personnes ;
• personne n'a lancé tous les tests : certains ne passent plus depuis dix jours ;
• il construit le site sur son poste (avec sa version de Node.js), puis copie les fichiers en FTP sur le serveur ;
• le site d'un client tombe le samedi ; personne ne sait quelle modification est en cause.

L'intégration et le déploiement continus règlent ces problèmes par trois idées :

2. CI, livraison continue, déploiement continu

                         Intégration continue (CI)
            ┌──────────────────────────────────────────────┐
  push  →   │ récupérer le code → lint → tests → build      │ → artefact
            └──────────────────────────────────────────────┘
                                                              │
     Livraison continue : déploiement en recette automatique, │
     en production sur décision humaine (bouton)  ────────────┤
                                                              │
     Déploiement continu : tout est automatique jusqu'à la    │
     production, si tous les contrôles sont verts  ───────────┘

Dans la pratique, on dit souvent « CI/CD » pour l'ensemble. Une agence comme Atlas Web fait typiquement de la livraison continue : chaque fusion dans main part automatiquement en recette, et le chef de projet déclenche la production après validation du client.

3. Anatomie d'un pipeline

Un pipeline est découpé en étapes (stages) qui contiennent des jobs. Les jobs d'une même étape peuvent tourner en parallèle ; les étapes s'enchaînent dans l'ordre.

  étape « vérifier »      étape « tester »        étape « construire »    étape « déployer »
  ┌──────────┐            ┌──────────────┐        ┌──────────────┐        ┌──────────────┐
  │ lint     │            │ tests Node 20│        │ image Docker │        │ recette      │
  │ format   │   ───→     │ tests Node 22│  ───→  │ archive      │  ───→  │ production   │
  └──────────┘            └──────────────┘        └──────────────┘        │ (manuel)     │
                                                                          └──────────────┘

Le pipeline tourne sur un runner (ou exécuteur) : une machine, souvent une machine virtuelle ou un conteneur neuf, fournie par GitHub ou GitLab, ou installée sur vos propres serveurs. Comme elle part de zéro à chaque fois, le « ça marche sur mon poste » disparaît.

Les bonnes propriétés d'un pipeline

• Rapide : moins de 10 minutes pour le retour principal ; au-delà, les développeurs n'attendent plus le résultat.
• Fiable : un test qui échoue au hasard (flaky) détruit la confiance ; on le répare ou on le retire.
• Versionné : le pipeline est un fichier dans le dépôt (.github/workflows/*.yml, .gitlab-ci.yml), relu en pull request comme le code.
• Rouge = priorité : quand main est cassé, l'équipe répare avant de continuer.

4. Les environnements

Règles qui évitent les catastrophes :

• Le même artefact passe de la recette à la production : on ne reconstruit pas entre les deux, sinon ce qu'on a validé n'est pas ce qu'on déploie.
• Seule la configuration change d'un environnement à l'autre (adresse de la base, clés d'API), via des variables et des secrets propres à chaque environnement.
• La production est protégée : déploiement réservé à certaines branches, approbation obligatoire, secrets inaccessibles aux autres jobs.
• On sait toujours revenir en arrière (rollback) vers la version précédente (leçon 3.2).

5. Le paysage des outils

Les niveaux 1 et 2 de cette formation couvrent GitHub Actions puis GitLab CI. Une fois les principes compris, passer de l'un à l'autre est surtout une affaire de vocabulaire.

6. Un pipeline à la main, pour comprendre

Avant de confier le travail à une plateforme, écrivons le même enchaînement en shell. C'est exactement ce que fera un runner : des commandes, dans l'ordre, avec arrêt à la première erreur.

#!/bin/sh
# scripts/pipeline.sh — pipeline local de la vitrine Atlas
set -e                      # s'arrêter à la première commande qui échoue

echo "== lint"
npm run lint

echo "== tests"
npm test

echo "== build"
mkdir -p dist
tar -czf dist/vitrine.tar.gz package.json src
echo "Artefact prêt : dist/vitrine.tar.gz"

chmod +x scripts/pipeline.sh
./scripts/pipeline.sh
echo "code : $?"            # 0 = pipeline vert ; autre chose = rouge

set -e est la clé : sans lui, le script continuerait après un test en échec et produirait un artefact cassé. Les plateformes de CI appliquent la même règle : une commande qui renvoie un code non nul fait échouer le job.

Vous pouvez même brancher ce pipeline sur Git avec un hook pre-push (formation Git, leçon 3.2) : le push est refusé si le pipeline échoue. C'est utile, mais cela reste sur votre poste et se contourne avec --no-verify. La vraie CI tourne sur le serveur, pour tout le monde, à chaque push.

7. Mesurer : les quatre indicateurs

Pour savoir si votre chaîne s'améliore, les équipes suivent souvent quatre indicateurs (dits « DORA ») :

Une bonne CI/CD fait monter les deux premiers et baisser les deux derniers en même temps : on livre plus souvent et plus sûrement, parce que chaque livraison est petite.

8. Par où commencer dans une équipe existante

Inutile de tout automatiser d'un coup. Voici le plan suivi par Atlas Web, sur environ un mois :

Ensuite seulement viennent l'optimisation (cache, parallélisme), la sécurité avancée (OIDC, signatures, niveau 4) et, si l'équipe le souhaite, le déploiement continu complet.

Deux conseils pour réussir ce passage :

• Mesurez avant et après : durée moyenne d'une mise en production, nombre d'incidents par mois. Ces chiffres convainquent mieux qu'un discours.
• Gardez le pipeline simple et lisible : un fichier YAML que toute l'équipe comprend vaut mieux qu'une usine à gaz que seule une personne sait réparer.

Pièges fréquents

• Automatiser le chaos : sans tests automatisés, un pipeline ne fait que déployer plus vite des bugs. Commencez par quelques tests sur les fonctions critiques (calcul des prix, paiement).
• Reconstruire pour la production ce qui a été validé en recette : ce n'est plus le même artefact.
• Pipeline de 40 minutes : les développeurs poussent moins souvent et contournent la CI. Parallélisez, mettez en cache (leçon 1.3).
• Ignorer un pipeline rouge « parce que ce test échoue toujours » : réparez-le ou supprimez-le, mais ne vous habituez pas au rouge.

Lab

Dans le projet Node.js /root/vitrine (déjà dans Git, avec un test et un lint), vous construisez un pipeline local :

1. scripts/pipeline.sh : lint puis tests, arrêt à la première erreur ;
2. une étape build qui produit l'artefact dist/vitrine.tar.gz, seulement si tout est vert ;
3. le commit du script, sans l'artefact ;
4. un hook pre-push qui lance le pipeline avant chaque push.

Les vérifications cassent volontairement un test dans une copie du projet pour s'assurer que votre pipeline devient bien rouge.

Quiz

1. Quelle différence entre livraison continue et déploiement continu ?
2. Pourquoi un pipeline s'arrête-t-il à la première étape en échec ?
3. Qu'est-ce qu'un runner, et pourquoi part-il d'une machine neuve ?
4. Pourquoi faut-il déployer en production le même artefact que celui validé en recette ?
5. Que fait set -e dans un script de pipeline ?

Sources de référence : GitHub Docs (CC BY 4.0) et GitLab Docs (CC BY-SA 4.0). Texte original MasterLinux.