Intégration continue

L'intégration continue est largement mal comprise. Ce n'est pas juste un serveur de build. Ce n'est pas juste exécuter des tests à chaque commit. Ce sont des outils qui soutiennent l'IC — mais l'IC elle-même est une pratique.

La vraie IC signifie :

• Tout le monde commite sur la branche principale (ou trunk) au moins quotidiennement
• Chaque commit déclenche une exécution de build et de tests
• Si le build échoue, le corriger est la priorité absolue
• La branche principale est toujours dans un état déployable

La partie « continue » est essentielle. Si vous intégrez chaque semaine, ce n'est pas continu. Si vous avez des branches de fonctionnalité de longue durée, ce n'est pas continu. L'IC signifie intégrer votre travail avec celui de tous les autres chaque jour, généralement plusieurs fois par jour.

La vraie IC nécessite le développement basé sur le trunk : tout le monde commite sur la branche principale (souvent appelée « trunk » ou « main »).

Ça semble effrayant. Les gens ne vont-ils pas tout casser ? C'est là que la discipline entre en jeu :

• Exécutez les tests avant de commiter (ne cassez pas le build)
• Commitez de petits changements (plus facile à intégrer, plus facile à corriger)
• Corrigez les builds cassés immédiatement (tout le monde s'arrête jusqu'à ce que ce soit vert)
• Utilisez des feature flags pour les fonctionnalités incomplètes (pour qu'elles puissent être fusionnées mais pas activées)

Les branches de longue durée sont l'ennemi de l'IC. Quand vous développez sur une branche pendant des semaines, vous n'intégrez pas. Vous ne faites que reporter l'intégration — et plus vous attendez, plus ça devient difficile.

Branchez pour des heures, pas des jours. Intégrez quotidiennement, pas chaque semaine.

Pour que l'IC fonctionne, le cycle de build et de tests doit être rapide. Martin Fowler suggère la règle des 10 minutes : le build complet, incluant tous les tests, devrait se terminer en moins de 10 minutes.

Pourquoi 10 minutes ? Parce que :

• Les développeurs ont besoin d'un retour rapide sur leurs changements
• Attendre une heure pour savoir si vous avez cassé quelque chose est trop lent
• Les builds longs encouragent les développeurs à sauter l'exécution des tests localement

Si votre build prend trop de temps :

• Parallélisez les tests
• Utilisez du matériel plus rapide
• Optimisez les tests les plus lents
• Envisagez la catégorisation des tests (tests unitaires rapides vs tests d'intégration lents)
• Revoyez la conception des tests (trop de base de données ? trop de réseau ?)

Certaines équipes exécutent un sous-ensemble rapide localement (tests unitaires) et la suite complète sur le serveur d'IC. C'est correct tant que la suite complète s'exécute assez rapidement pour fournir un retour en temps opportun.

Le build va échouer. Ce qui compte, c'est ce qui se passe ensuite.

La règle : Quand le build échoue, le corriger devient la priorité absolue. Tout le reste s'arrête.

Cela peut sembler extrême, mais considérez : un build cassé signifie que l'équipe ne peut pas faire confiance à la branche principale. Le travail de tout le monde est bloqué parce qu'ils ne peuvent pas intégrer en toute sécurité. Chaque minute où le build est cassé est une minute de risque accumulé.

Qui le corrige ? Généralement la personne qui l'a cassé. Mais si elle est bloquée, d'autres aident. Un build cassé est un problème d'équipe, pas un problème individuel.

Comment prévenir les échecs :

• Exécutez les tests localement avant de commiter
• Gardez les changements petits (petits changements = petit risque)
• Faites attention aux notifications d'IC (corrigez rapidement)
• Ne commitez pas et ne partez pas pour la journée

Certaines équipes utilisent une rotation de « shérif d'IC » — quelqu'un responsable de surveiller le build et de coordonner les corrections. Cela prévient l'effet du spectateur où tout le monde suppose que quelqu'un d'autre va le corriger.

L'IC est la fondation pour des pratiques plus avancées :

Livraison continue (CD) : Chaque commit peut être déployé en production. Le déploiement est une décision d'affaires, pas technique.

Déploiement continu : Chaque commit qui passe les tests est automatiquement déployé en production. Aucune approbation humaine requise.

Toutes les équipes n'ont pas besoin de déploiement continu. Mais toutes les équipes bénéficient de l'IC. Commencez par là.

Métriques d'IC à surveiller :

• Temps de build (devrait être sous 10 minutes)
• Fréquence de build (devrait être plusieurs fois par jour par développeur)
• Temps moyen pour corriger les builds cassés (devrait être des minutes, pas des heures)
• Couverture de tests (pas une métrique parfaite, mais un signal)

L'IC ne concerne pas seulement la détection de bogues. Il s'agit de créer un rythme où l'intégration est ennuyeuse, routinière et sûre. Quand l'intégration est sûre, tout le reste devient plus facile.