Intégration continue
Chaque modification validée localement est intégrée au plus vite pour s'apercevoir des régressions sur le tout.
Principe parent : Itérations
Question pratique : Intégration
Pratique opposée : Intégration avant de livrer
Bénéfice
Intégrer le travail de chacun plusieurs fois par jour révèle aussitôt les régressions sur l'ensemble, en contournant l'obstacle du Big bang que produit une intégration reportée à la fin.
Mise en pratique
À chaque livraison de code, la chaîne d'intégration compile, joue les tests et signale les erreurs ; une intégration cassée est réparée avant toute autre chose.
Recommandation
Si l'équipe ne dispose pas encore d'une chaîne d'intégration, sa mise en place vaut une story d'investissement : c'est un travail à négocier avec le Product Owner, pas un préalable technique à faire en douce.
Antipattern
- Constatation : sous prétexte d'intégration continue, chacun travaille sur sa branche et la fusionne en fin de sprint.
- Risque : le nom est là, la pratique non : conflits et régressions se découvrent toujours à la fin, quand il est trop tard pour les traiter.
- Réduction du risque : regarder ce qui compte, la fréquence réelle d'intégration de chacun, et traiter une chaîne en échec comme un arrêt collectif.
Avec l'IA ?
- Constatation : Le code produit avec une IA arrive en volume, par gros blocs, plus vite qu'il n'est relu.
- Risque : Des modifications importantes sont intégrées sans que personne ne les ait vraiment lues ; la chaîne au vert tient lieu de compréhension.
- Réduction du risque : Garder des intégrations petites, fréquentes et relues ; les tests qui gardent la chaîne au vert doivent eux aussi être compris par l'équipe.