25. L'intégration continue : conserver un système toujours vérifiable
Pourquoi ce chapitre existe
Une branche qui vit plusieurs jours accumule des hypothèses sur un système qui continue de changer sans elle. Au moment de l'intégrer, le coût de compréhension, de résolution de conflits et de diagnostic augmente brutalement. La CI est parfois réduite à un serveur qui lance des tests. Sa fonction plus profonde est de maintenir une version commune du système, vérifiée assez souvent pour que les écarts restent attribuables.
Les idées essentielles
- L'intégration continue est une pratique de fréquence, de qualité de feedback et de propriété collective du tronc.
- Un pipeline doit répondre à des questions de risque précises : compilation, analyse, comportement, contrat, sécurité, artefact et déploiement.
- Un build rouge est un signal collectif à traiter rapidement ; le normaliser détruit la confiance dans toutes les barrières.
- La vitesse du pipeline est une propriété d'ingénierie qui influence directement la taille des lots et la qualité des décisions.
Concevoir un pipeline comme une chaîne de preuves
Chaque étape doit produire une information qui change une décision. Les vérifications rapides et déterministes doivent revenir tôt : formatage, compilation, tests ciblés, analyse statique. Les vérifications plus coûteuses — intégration, sécurité approfondie, charge — peuvent être échelonnées, à condition que le changement ne puisse pas contourner celles qui protègent son risque.
| Question | Preuve de CI | Danger si absente |
|---|---|---|
| L'artefact est-il construisible ? | Build reproductible depuis une source propre | Environnement local non représentatif |
| Le comportement local tient-il ? | Tests ciblés et déterministes | Régression détectée tardivement |
| Les frontières restent-elles compatibles ? | Tests de contrat et de schéma | Intégration cassée après déploiement |
| L'artefact est-il traçable ? | Version, provenance, dépendances | Impossible d'expliquer ou restaurer une livraison |
La CI n'est pas une porte qui valide un changement isolé. Elle protège le système partagé. Cela implique une règle simple : lorsqu'elle est cassée, la priorité est de rétablir un signal fiable, ou d'isoler explicitement le problème. Continuer à fusionner dans le rouge reporte le coût sur toutes les personnes qui arrivent ensuite.
Un pipeline vert après quarante minutes peut encourager des lots plus gros et des contournements. Suivre le temps avant le premier échec utile, les tests instables et les étapes les plus coûteuses permet de concentrer l'amélioration là où elle accélère réellement la qualité.
Anti-patterns
Empiler les contrôles sans propriétaire
Une étape ajoutée après chaque incident finit par ralentir tous les changements sans que personne ne sache quel risque elle couvre. Chaque contrôle doit avoir une raison, une équipe responsable de sa fiabilité et un critère de retrait ou d'évolution.
Réparer les builds rouges par le retry
Relancer un test instable peut débloquer une livraison, mais enseigne que le signal n'est pas crédible. L'instabilité doit être visible, isolée si nécessaire et traitée avec la même attention qu'une régression qui détruit la confiance des utilisateurs internes.
Construire une fois, déployer autre chose
Si les environnements reconstruisent différemment l'application, le pipeline ne prouve pas l'artefact réellement livré. Promouvoir le même artefact, avec une provenance claire et une configuration explicitement validée, ferme cette brèche.
Bonnes pratiques
Rendre chaque échec actionnable
Un échec doit nommer l'étape, la preuve et le chemin de diagnostic. Les logs, artefacts de test et liens vers le changement responsable réduisent le temps d'interruption et font de la CI un outil d'apprentissage plutôt qu'un guichet opaque.
Réduire les branches longues par la conception du travail
Petits lots intégrables, compatibilité de transition et flags temporaires permettent de fusionner tôt sans exposer immédiatement un comportement incomplet. La CI devient alors le rythme naturel du travail, et non la dernière étape d'une branche devenue trop grande.
Checklist — La CI produit-elle une confiance exploitable ?
- Chaque étape répond-elle à un risque connu et possède-t-elle un responsable ?
- Le premier feedback utile arrive-t-il assez vite pour guider le travail ?
- Les échecs sont-ils déterministes, diagnosticables et traités rapidement ?
- Le même artefact promu est-il celui qui a été vérifié ?
- Les contrats, configurations et dépendances critiques sont-ils contrôlés ?
- Un changement peut-il être intégré sans laisser le tronc dans un état trompeur ?
À retenir
L'intégration continue ne consiste pas à automatiser une validation finale. Elle maintient un système commun dans un état où chaque changement peut être vérifié, attribué et livré sans transférer son incertitude à l'équipe suivante.