L’auteur est ainsi immédiatement averti de son erreur, et peut la réparer rapidement. En général, personne en dehors du responsable de build ne se rend compte du problème, et on ne crée pas de soucis de stigmatisation ou de conflits dans l’équipe comme on pourrait l’avoir avec un mode de communication mettant tout le monde au courant.

En outre, en mettant les erreurs en copie à un responsable de build, cela permet de s’assurer du traitement de l’erreur si le « fautif » n’est pas présent ou ne réagit pas suffisamment rapidement.

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é)

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, …

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…

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 disparaitre 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.

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

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

‘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) !