Au même titre que d’avoir les histoires affichées, et que c’est un bon moyen de juger de l’avancement et de la santé du projet, avoir une lava lampe verte en pleine forme me semble être également un bon indicateur.

Il est rare tout de même qu’un membre de l’équipe soit réellement accablé lorsqu’il casse une build… La plupart du temps d’ailleurs, personne ne le relève vraiment si la personne suit le process, endosse la responsabilité du problème et publie les corrections. C’est l’intégration continue, ça sert à ça, c’est normal.

Mais je t’assure qu’il est parfois pénible de devoir gérer dans une équipe des gens qui font systématiquement les mêmes conneries, en ignorant complètement les recommandations pourtant évidentes et les outils disponibles.

Je vais prendre un exemple concret :

Dans notre projet actuel, lorsqu’un développeur ajoute une référence à un projet .NET, il doit également penser à modifier le script NAnt de build qui est versionné avec le reste de la solution. Cette modification a pour simple but de permettre au serveur d’intégration continue (TeamCity) en l’occurrence, de pouvoir compiler correctement le projet.

Lorsque le développeur travaille en local, il compile et teste à partir de VisualStudio ce qui ne lui permet pas de détecter l’erreur au niveau du build script.

Au lieu de faire le commit directement, il lui suffit d’utiliser le plugin fourni par TeamCity pour faire une “personal build”. Cette dernière échouera rapidement, lui indiquant que le projet en question ne compile pas car une référence est introuvable. Plus globalement, les personal builds permettent de tester que la solution n’a aucune dépendance locale, et qu’elle peut être compilée, testée etc. dans un environnement neutre.

Malgré ça, s’il y a 2 références à ajouter, certains vont s’arranger pour casser le trunk 5 fois de suite. C’est un peu pénible, et ça pourrait être évité facilement.

Je pense alors que le fait de donner la visibilité sur ce qui se passe au niveau du serveur est un bon moyen de sensibiliser ces personnes. Pour les autres, c’est souvent juste un rappel…

De plus j’ajouterai que la stigmatisation (sous-entendue par la responsabilisation) de ceux qui cassent le build n’est pas forcément bonne. Je rejoins en cela les nombreux commentaires sur cet article qui pose à peu près les mêmes questions que toi : http://blog.octo.com/index.php/2008/04/30/111-faites-vous-vraiment-de-l-integration-continue

Est-ce que le continuous monitoring a un réel intérêt par rapport à l’ensemble des solutions de notification existantes ? (Tray notifiers, Emails, RSS, Plugins, Alertes IM, etc.)

Par expérience, je constate que lorsque quelqu’un casse une build, tout le monde le sait aussitôt via un ou plusieurs des moyens d’avertissement sus-cités, et l’intéressé peut difficilement faire autrement que de se sentir très concerné (c’est un peu l’effet “post-it-sur-le-front”). Il n’y a donc pas forcément besoin de mettre en pratique le monitoring continu pour responsabiliser les membres, ou même tirer partie à 100% d’une solution d’intégration continue.

La plupart des gens qui ont tenté ça jusqu’à présent semblent l’avoir fait pour le fun, ou tout simplement parce qu’en gros geeks qu’ils sont, ils se doivent d’essayer des trucs exotiques à base de wifi et d’usb.

Mais je classe l’approche ludique et l’aspect original du monitoring continu dans les facteurs de motivation potentiels d’une équipe de développement. Bien que ça puisse sembler à la fois naïf et très relatif…

Je suis d’accord avec grozeille : le monitoring n’est pas superflu. Quel est l’intérêt d’un serveur d’intégration continue qui tourne seul dans son coin ?

Pour ma part, j’utilise CC Tray ou JCC Tray mais j’aimerais beaucoup mettre en place un gadget du genre lava lamp, ambiant orb, nabaztag…Je trouve que ce genre de chose apporte à la fois du fun/plaisir/détente et de la motivation. Que du bénef pour le projet et ses membres !

Il est parfois difficile d’expliquer à un membre de l’équipe qu’il faut qu’il reprenne sont travail et qu’il le fasse mieux au lieux de passer à autre chose. Un outil de monitoring est parfait pour ça surtout s’il est visible publiquement.