L'intégration continue (connue aussi sous le nom de "build continu") est l'une des pratiques agiles les plus populaires. C'est surement parce qu'il s'agit de l'une des plus simples à mettre en œuvre : on télécharge l'un des nombreux outils disponibles (Hudson, CruiseControl, Continuum, Bamboo....), on le fait pointer vers le référentiel de sources du projet (subversion, cvs ...), et c'est parti : tel un métronome il préviendra l'équipe toutes les 10 minutes si le code présent dans le référentiel de sources du projet ne compile pas ou ne passe pas les tests automatisés.
Mais suffit-il d'avoir un tel outil installé pour pouvoir prétendre faire de l'intégration continue ?
Je pense que non.
J'ai en effet pu remarquer que la "simplicité" de mise en oeuvre de cette pratique est à double tranchant : le plus vite l'outil est installé, le plus vite il est oublié ; quoi de plus aisé pour un développeur que de mettre une règle outlook filtrant tous les mails "Build failed" ? Et une fois oublié on peut dire que le build continu devient complètement inutile, car cet outil ne fait strictement rien pour vous : il se contente de prévenir l'équipe lorsqu'une modification des sources compromet l'intégrité du projet ; charge alors à l'équipe d'avoir le réflexe de corriger le build immédiatement ! (et le defect-cost-increase s'applique aussi au build : plus on attend pour réparer le build et plus cette réparation devient coûteuse).
Alors comment ne plus oublier l'intégration continue ? Il faut instaurer une culture projet autour de cette pratique de telle sorte à ce que l'intégrité du build devienne l'une des priorité de tout membre de l'équipe (management y compris). Voici quelques recettes permettant d'instaurer cette fameuse "culture du build" :
Si en plus d'être une pratique simple et utile, l'intégration continue peut être fun, il n'y a vraiment plus de raison de s'en priver !