Qui a pété le build ?

L'intégration continue, c'est la pratique selon laquelle on passe régulièrement l'outil de build automatique permettant de compiler et tester le code.

Je découvre à france billet une pratique intéressante: lorsque le build casse, il notifie le ou les derniers commiters "mmh, tu es suspecté d'avoir cassé le build". Après diagnostic, ceux ci peuvent déclarer ("claimer") le build, cela signifie qu'il s'atèle à le corriger par un nouveau commit. On peut bien sûr claimer un build auquel on n'a pas contribué.

Là où cela devient interessant c'est que tant que le build n'est pas réparé, il n 'est pas possible de commiter, sauf pour celui qui l'a claimé. Imaginez un plateau d'une trentaine de personne qui attendent de pouvoir commiter.

Enfin le build est réparré après une ou plusieurs tentatives

C'est une approche de type "Stop the line", le andon du jidoka, venant du lean. Sur une chaîne de production cela se passe ainsi: l'opérateur ou la machine elle-même détecte une anomalie sur la chaîne, il appuie sur un bouton qui stoppe toute la chaîne, fait du bruit, etc... son responsable le rejoint, et ils se donnent une timebox pour corriger le problême. L'idée est de détecter et corriger les problêmes au plus tôt.

On peut voir un build cassé comme un défaut à corriger, ou encore comme un stock de tests à corriger, et dans ce cas il faut considérer ce stock comme un élément à minimiser.

Le principal avantage est de donner une grande importance au build, de détecter les erreurs et les corriger rapidement. 

L'inconvénient constaté est la rétention de commit: si le build est jugé trop long, il est tentant de passer à la story suivante, puis de faire un commit global, à l'opposé du commit atomique. On constate parfois un effet boule de neige, mais le build redevient toujours stable.

J'ai déjà joué avec un outil similaire, le jeu de l'intégration continue, ou l'on gagne des points en fonction de notre participation au build, mais cela n'avait pas le même impact.

Ici, impossible d'ignorer un build en echec.

Personnellement, j'ai déjà cassé et réparé le build.

Côté implémentation, cela est réalisé par

• hudson (non, non pas jenkins)
• plugin hudson claim
• un plugin hudson de rapport de build développé en interne
• des hooks svn écrits en groovy en interne

De plus, je trouve que les messages de notification sont marrants:

• Oh no! You're suspected of having broken ...
• You're still being suspected of having broken ...
• Yippie! Seems you've fixed ... 
• Yippie, build fixed!