Faites vous vraiment de l'intégration continue ?

Par Christian Blavier, mercredi 30 avril 2008 à 13:55 :: Agile :: #111 :: rss

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 !

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le mercredi 30 avril 2008 à 14:29, par Romain

Quelques commentaires sur ce bon article :

"le plus vite l'outil est installé, le plus vite il est oublié"... Où est la relation entre la rapidité d'installation d'un outil et son adoption ? Ce n'est pas parce qu'un outil va être très long à installer et configurer que l'équipe fera plus d'efforts pour l'adopter... Ce sera sans doute le cas pour la personne qui s'est donné le mal de l'installer, mais cela n'impactera pas à mon avis le reste de l'équipe !

Les fonctions de l'I.C. sont en effet très restreintes... Il s'agit avant tout de s'assurer que les builds et les tests passent, et d'alerter qui de droit dans le cas contraire. Ca ne corrige pas (hélas) les erreurs !
Pour moi, il faut qu'un minimum d'efforts soient faits par chaque développeur, en particulier sur les réactions à avoir lors d'une alerte de l'IC. Après tout, ignorer une telle alerte, c'est comme ignorer une erreur de compilation relevée par Eclipse par exemple !

Le jeu de l'intégration continue : Je l'ai installé sur Hudson, mais je dois admettre qu'en dehors d'un aspect ludique, c'est assez limité, d'autant plus que les valeurs sont tout simplement faussées. Si 2 développeurs viennent à commiter en même temps, et qu'un seul fasse échouer le build, alors ce seront les 2 qui seront pénalisés. Certes, on peut faire en sorte que les builds soient réalisés dès qu'un commit a lieu, limitant ainsi la possibilité d'avoir 2 personnes commitant pour un même build... De même, si Hudson (ou Maven) échoue sans lien direct avec le projet (ce qui arrive encore régulièrement), alors les développeurs seront injustement pénalisés.
Mais au delà de ça, ce genre de "jeu" peut être mal perçu par certains développeurs, et risque d'encourager de mauvaises pratiques (commits beaucoup moins fréquents par exemple).
Cela dit, j'adore le lapin communicant (j'en veux un ! ).

De manière générale, je pense qu'il faut toujours un "chef IC", qui surveillera le bon respect des règles autour de l'IC, et qui n'hésitera pas (accompagné de son lapin s'il le faut) à rappeller certains développeurs à l'ordre...
Ce "chef" doit être une personne vraiment convaincue par l'IC afin qu'il puisse vraiment pousser cette pratique au sein de son équipe...

Ma conclusion : Vive Hudson :o) !

2. Le mercredi 30 avril 2008 à 15:41, par Christian

Romain,

Effectivement installer lentement l'outil n'aidera pas particulièrement l'équipe à l'adopter. Mais d'expérience, j'ai pu constater que lorsque l'outil est installé particulièrement rapidement (par exemple lorsque l'entreprise dispose d'une infrastructure de build continue pour l'ensemble des équipes projets), l'évangélisation sur la pratique d'intégration continue était mal (voire peu) faite. Désolé pour le raccourci :)

Merci pour ton retour d'expérience sur le jeu Hudson (que je n'ai pas essayé personnellement). Pour ma part j'ai constaté un effet secondaire à la technique du lapin : les développeurs font échouer le build volontairement pour voir le lapin parler :)

Christian

3. Le mercredi 30 avril 2008 à 16:11, par Jean-Laurent

Tu n'as pas trop de "lag", entre le moment ou le build échoue effectivement et le moment ou le lapin l'annonce à l'équipe ?
J'avais parfois plus de 5 minutes d'écart entre les deux. Ce qui "tue" un peu l'apprentissage pour les sceptiques de l'intégration continue.
Autre question :
Arrives-tu à faire en sorte que l'état du build soit signifié par les lumières du lapin (et pas uniquement les oreilles) dans les périodes entre les annonces (ie: pas uniquement au moment ou il détecte le build, un peu comme les oreilles qui gardent leurs positions jusqu'à ce que le statut du build change)

4. Le mercredi 30 avril 2008 à 16:36, par Christian

Salut Jean-Laurent !

Je vais être bref : oui j'ai parfois du lag (et parfois pire : le serveur API de Nabaztag est en rade et je recois tous les messages en rafale qq heures après) et non je n'arrive pas à rendre la couleur des leds persistantes.

A+
Christian

5. Le jeudi 1 mai 2008 à 23:10, par cth

Je suis à fond pour signaler immédiatement un build cassé à l'équipe, cela me paraît une condition sine qua non de l'intégration continue.

Je ne suis pas sûr que le chapeau mou, le tableau d'honneur, ou la dénonciation en direct soit des moyens efficaces pour améliorer la situation du build continu, ni celle du projet. Ici on ne se contente pas de signaler le problème, on "marque" un responsable du problème. (Je pense que le côté fun et décalé qui atténue ce marquage peuvent disparaître assez vite dans un projet complexe et difficile).

Le statut du build continu est un témoin lumineux permanent à propos de l'intégrité du produit. Quand le produit ne "compile pas" ou ne passe plus tout ses tests, il n'est plus intègre. Et si le produit n'est pas intègre c'est que l'équipe qui le fabrique a elle même un problème d'intégrité. Par exemple :
- Stan a modifié la signature de 4 méthodes dans la couche métier sans prévenir personne. Forcément, puisqu'il était seul à travailler hier soir à 21h..
- Bert a décidé de "committer" sans repasser tous les tests unitaires sur son poste, parce qu'il a senti la pression de livrer lors du stand up meeting...
- Gus ne savait même pas qu'il fallait écrire ou modifier des tests unitaires avant de toucher au code, vu qu'il débarque et que personne n'a pris le temps de le lui (ré)expliquer.

C'est évidemment pratique de savoir sur quel poste se trouve le code qui ne passe pas l'intégration continue. Mais ça ne sert à rien d'affirmer que Stan, Bert ou Gus ont "cassé le build" (encore lui ! heureusement chez moi ça marche).

C'est l'équipe qui a cassé le build: c'est parce qu'elle n'est pas assez "intégrée" (ou alignée) que son produit n'est pas intégrable. Or lorsqu'on cherche à travailler dans une équipe plus alignée et plus efficace, souligner le nom de ceux qui font des erreurs ne sert à rien, au contraire, c'est même contre-productif.

Que faire alors ?

1) je remplacerais le message nominatif du lapin par: "My God, They Killed Kenny !" ou un autre truc plus drôle
2) quand le build est cassé, 2 ou 3 personnes se mettent en demeure de le réparer au plus vite, et plus personne ne valide de code.
3) quand le build est réparé, toute l'équipe se met en stand up et procède à une analyse 5 pourquoi.

6. Le lundi 5 mai 2008 à 14:43, par Ethan

La technique du "chapeau débile" qui consiste à faire un porter un bonnet d'âne au développeur qui casse le build.

C'est la solution la plus stupide que j'ai lu jusqu'a présent. Je crois que vous n'avez malheureusement rien compris à l'esprit de projets agiles et pire, aux relations humaines....
Vous formez une équipe, il ne sert à rien de stigmatiser les individus, dans cet exemble, vous êtes aussi coupable que lui...

7. Le lundi 5 mai 2008 à 17:50, par Mathieu Gandin

"Le chapeau débile" beuark, voilà une technique que je n'ai vraiment pas envie d'utiliser. Et je rejoins CTH, je n'aime pas trop les trois techniques proposées pour que l'équipe soit sensibilisée à la problématique d'intégration continue.

Je préfère que le build prévienne l'équipe lorsque ça pète, puis faire en sorte que l'équipe (éventuellement, aidée du coach) répare ce qui a été cassé. A charge à l'équipe d'en discuter : 5 pourquoi animé par le coach, rétro, ...

8. Le lundi 5 mai 2008 à 21:13, par Christian

Hmmm, ok je reçois vos remarques sur l'aspect "stigmatisant" du notificateur de build :) je pense en effet qu'il faut l'utiliser avec des pincettes et uniquement lorsque que l'on connait bien son équipe.
Aujourd'hui si la technique du lapin fonctionne chez moi (i.e. ne traumatise personne) c'est que :
- le build ne casse que exceptionnellement
- ce n'est pas la même personne qui casse le build à chaque fois
- lorsque le lapin parle, ça amuse et détend l'équipe (au point, comme je le disais, de retrouver un build échoué à cause d'une classe renommée en "BoumLeLapin" ... ;-)

Qui plus est j'ai pu constater les vertus suivantes :
- le temps de réparation d'un build échoué s'est sensiblement réduit ; et ceci en autre grâce au fait que la personne entend son nom. Mais je n'ai pas l'impression de tomber dans le travers "maintenant que tu as le nez dedans, répare !". Souvent les développeurs voient ça comme un rappel : 80% du temps la cause est "ah oui j'ai oublié de lancer Maven en local avant de tester" , les autres fois je constate qu'ils n'hésitent pas à faire des appels à l'aide
- le lapin permet d'évangéliser sur l'intégration continuer au delà d'une simple équipe projet : je ne compte plus le nombre de personnes passées sur l'open-space a qui j'ai expliqué la pratique !

En bref, je pense qu'il faut faire preuve de psychologie vis à vis des membres de son équipe pour savoir ce que l'on peut ou non se permettre. Je ne vois pas les top-gun du build avec qui je bosse être blessés par un chapeau ridicule, un score faible à un jeu, ou par une vanne de lapin tant ces situations restent exceptionnelles. Mais si je devais aujourd'hui rejoindre une équipe avec du code legacy, pour laquelle la stabilité du code source est une douleur, je vous rejoins sur le fait que ce serait une très mauvaise pratique d'introduire l'intégration continue avec un lapin en mode délation (le "my god, they killed kenny !" serait bien mieux adapté)