Ce qui doit tourner dans votre pipeline, et dans quel ordre

Un pipeline a une seule mesure de succès : l'équipe lui fait confiance. Dès qu'il devient lent ou capricieux, quelqu'un trouve le moyen de le contourner, et vous avez ajouté de la cérémonie sans ajouter de sécurité.

Séparer l'intégration de la livraison

Les deux moitiés répondent à des questions différentes.

L'intégration continue répond à « ce commit casse-t-il quelque chose ? ». Elle tourne à chaque poussée, sur chaque branche, et doit rester rapide.

La livraison continue répond à « cette version peut-elle aller en production ? ». Elle tourne sur un artefact déjà construit et validé, et a le droit d'être plus lente.

Confondre les deux donne le pire des cas : un pipeline de vingt minutes déclenché à chaque correction de faute de frappe.

Ce qui bloque, et ce qui avertit

Doit bloquer une fusion :

• La compilation.
• Les tests unitaires et d'intégration.
• L'analyse de secrets : une clé d'API dans un commit est un incident, pas un avertissement.
• Les vulnérabilités critiques et connues des dépendances.

Doit seulement avertir :

• La couverture de tests qui baisse de quelques points.
• Les règles de style et de mise en forme, si elles sont corrigées automatiquement.
• Les vulnérabilités faibles sans correctif disponible.

Une règle qui bloque sans que personne ne puisse la corriger le jour même sera désactivée dans le mois. Mieux vaut ne pas la mettre.

L'ordre des étapes

Faites échouer vite ce qui échoue souvent. Compilation d'abord, puis les tests rapides, puis les tests lents, puis les analyses de sécurité, et seulement ensuite la construction de l'image. Construire une image que la première étape de test aurait rejetée est du temps de machine gaspillé et du temps humain d'attente.

Un artefact, plusieurs environnements

C'est la règle qui évite le plus d'incidents : la même image part en recette et en production. Ce qui change entre les deux est une variable, jamais une reconstruction. Reconstruire pour la production, c'est tester une chose et livrer une autre.

La mesure qui compte

Chronométrez le délai entre la fusion d'une branche et l'arrivée du code en production. Si ce délai se compte en jours, le problème n'est pas dans vos tests : il est dans les étapes manuelles qui restent entre les deux.