Les étapes d'un pipeline CI/CD

Un pipeline CI/CD est la suite automatisée d'étapes qui transforme un commit en version vérifiée, puis livrée : récupérer le code, installer les dépendances, analyser, tester, construire, publier, déployer. Chaque étape doit réussir pour que la suivante démarre. Ce chapitre décrit ces étapes dans l'ordre, explique comment une machine sait qu'une étape a échoué, et donne les règles qui font un bon pipeline : rapide, reproductible et digne de confiance.

Le principe : des commandes et des codes de retour

Un pipeline ne fait rien de magique : il exécute des commandes, les mêmes que tu tapes dans ton terminal. Pour savoir si une commande a réussi, il lit son code de retour (exit code) :

• 0 : la commande a réussi, l'étape est verte ;
• tout autre nombre : la commande a échoué, l'étape est rouge et le pipeline s'arrête.

npm test
echo $?        # affiche le code de retour de la dernière commande : 0 si tous les tests passent, 1 sinon

Jest, ESLint, PHPUnit, dotnet test, pytest : tous les outils de qualité renvoient un code différent de 0 quand ils trouvent un problème. C'est ce qui permet de les brancher dans n'importe quel pipeline.

Les étapes, dans l'ordre

Les étapes 1 à 8 forment l'intégration continue ; les étapes 9 à 14 la livraison ou le déploiement continu. Un projet de BTS commence par les étapes 1 à 5 et ajoute les autres au fil des besoins.

Installer avec des dépendances verrouillées

La machine qui exécute le pipeline démarre vide. Elle doit installer exactement les mêmes versions de bibliothèques que sur le poste du développeur, sinon un test peut passer chez l'un et échouer chez l'autre. Le fichier de verrouillage (lockfile) fige ces versions : il doit être versionné dans Git.

npm ci (clean install) supprime node_modules, installe exactement ce que dit package-lock.json, et échoue si ce fichier ne correspond plus à package.json. C'est voulu : une dépendance ajoutée sans mettre à jour le verrouillage est détectée tout de suite.

Échouer vite : l'ordre des étapes

Un pipeline s'arrête au premier échec. On place donc en tête les étapes rapides et souvent en échec, et en fin les étapes lentes. C'est le principe d'échec rapide (fail fast) : le développeur apprend le problème en trente secondes plutôt qu'au bout de dix minutes, et la machine ne calcule pas pour rien.

Deuxième levier : paralléliser. Le lint, les tests unitaires et l'analyse de sécurité ne dépendent pas les uns des autres. Placés dans trois jobs distincts, ils tournent en même temps sur trois machines, et la durée totale devient celle du plus long (les jobs parallèles).

Les vérifications statiques : formatage, lint, typage

Elles examinent le code sans l'exécuter.

• Le formatage vérifie la mise en page : indentation, guillemets, longueur des lignes. Dans la CI, on vérifie sans modifier : npx prettier --check .. Le développeur corrige chez lui avec npx prettier --write ..
• Le lint cherche les erreurs probables et les mauvaises pratiques : variable déclarée mais jamais utilisée, == au lieu de ===, await oublié. ESLint pour JavaScript, PHPStan ou Psalm pour PHP, les analyseurs Roslyn pour C#, Ruff pour Python.
• Le typage vérifie la cohérence des types : npx tsc --noEmit pour TypeScript, PHPStan à un niveau élevé pour PHP, le compilateur pour C# et Java.

Construire et empaqueter : l'artefact

L'étape de construction produit un artefact : l'objet qui sera livré. Selon le projet, c'est un dossier dist/ de fichiers statiques, une archive .zip, un exécutable, un .jar, ou de plus en plus souvent une image Docker qui contient l'application et tout ce dont elle a besoin pour tourner.

Deux règles rendent la livraison fiable :

1. Construire une seule fois, déployer partout (build once, deploy many). L'artefact testé en recette est exactement celui qui part en production. On ne reconstruit pas pour la production : une reconstruction pourrait tirer une dépendance différente, et l'on déploierait un objet jamais testé.
2. Identifier chaque artefact sans ambiguïté. On l'étiquette avec l'empreinte du commit (3f9c2e1) ou un numéro de version (2.4.0), jamais seulement avec latest. Ainsi, on sait toujours quel code tourne en production, et on peut redéployer la version précédente en une commande (chapitre 12).

Déployer, puis vérifier

Le déploiement installe l'artefact dans un environnement : recette d'abord, production ensuite (chapitre 10). Un déploiement n'est pas terminé quand la commande rend la main, mais quand on a vérifié que le service répond. Le plus simple est un test de fumée (smoke test) : une requête sur une route de santé.

curl --fail --silent --show-error --retry 5 --retry-delay 3 --retry-all-errors \
  https://recette.sorbier.example/health

--fail fait renvoyer à curl un code d'erreur si le serveur répond 4xx ou 5xx ; sans cette option, une page d'erreur 500 serait considérée comme un succès. --retry laisse au service le temps de démarrer.

Où tourne le pipeline : les runners

La machine qui exécute un pipeline s'appelle un runner (GitHub, GitLab) ou un agent (Jenkins, Azure Pipelines).

Une machine neuve à chaque exécution est une force : aucun reste du job précédent, aucune configuration cachée. C'est aussi pourquoi chaque job commence par récupérer le code et installer ses outils.

Ce qu'on attend d'un bon pipeline

• Reproductible : mêmes entrées, même résultat ; versions verrouillées, environnement neuf.
• Rapide : moins de dix minutes pour une pull request.
• Fiable : un test qui échoue une fois sur dix au hasard (flaky test) apprend à l'équipe à ignorer le rouge ; on le corrige ou on le met en quarantaine (les tests instables).
• Bloquant : un échec empêche vraiment la fusion ou le déploiement (protection de branche).
• Versionné : la description du pipeline vit dans le dépôt, avec le code, et passe en revue comme lui.
• Sûr : droits minimaux, secrets protégés, actions tierces maîtrisées (chapitre 7).

Exercices

npm test || echo "Des tests ont échoué, à regarder plus tard"