Faites vous vraiment de l'intégration continue ?

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" :

• La technique du "chapeau débile" qui consiste à faire un porter un bonnet d'âne au développeur qui casse le build.
• Le jeu de l'intégration continue où l'on maintient un tableau de scores pour chaque développeur de l'équipe. Chacun gagne ou perd des points à chaque build réussi ou cassé. Voici une extension pour hudson permettant de gérer ce jeu.
• Le lapin communiquant : c'est la technique que j'utilise actuellement en clientèle ; il s'agit d'un lapin wifi dont la position des oreilles indique l'état actuel du build et qui déclame de sa petite voix nasillarde le nom du fautif ; le voici en action !

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 !