Au delà de l’Intégration Continue : le Monitoring Continu
Je viens de terminer l’écoute d’un des derniers podcasts de Scott Hanselman, dans lequel il échange avec Owen Rogers. La discussion tourne autour de l’intégration continue. Owen est assez au courant : il est l’un des créateurs de CruiseControl.NET, le serveur d’intégration continue sans doute le plus utilisé dans le monde .NET.
Ce que j’ai trouvé intéressant, voire original dans cette discussion, c’est le développement qui a eu lieu autour de l’idée du monitoring.
En introduction, Scott joue l’ingénu et demande à Owen pourquoi on aurait besoin d’un serveur d’intégration continue alors qu’un pauvre script planifié pourrait très bien faire l’affaire. Owen lui fait la liste des principales caractéristiques et avantages d’une solution comme CruiseControl, et insiste tout particulièrement sur la capacité d’un tel système à produire et agréger différents rapports concernant les builds et les projets. Il explique également qu’au delà des fonctionnalités de journalisation et de statistiques, un outil d’intégration continue offre des mécanismes de notification pouvant informer les équipes en temps réel, et leur fournir des détails sur l’état des différentes builds.
En effet, la notion de feedback est indissociable de l’intégration continue.
Mais qui a encore pété la build ?
Lorsqu’un problème survient au cours d’un build process :
- On doit le savoir. Idéalement, l’information est poussée vers les différents membres de l’équipe de développement : email, instant messenger, notification via deamon, plugin de l’IDE, etc.
- On doit l’identifier. Est-qu’il s’agit d’une erreur de compilation ? Où, dans quel module, quelle ligne ? D’un test unitaire qui ne passe plus ? Quels sont les récents changements qui ont cassé la build ?
- On doit le prendre en charge. Généralement, une personne (pas forcément la bonne, d’ailleurs) décide d’endosser la responsabilité du problème et en informe l’équipe via l’outil d’intégration continue. Ensuite, elle fait en sorte de remettre la build d’aplomb en publiant les corrections.
Lorsqu’on dispose d’une bonne solution d’intégration continue et que l’équipe est rodée, tout ce processus devient quasi-automatique et les différents projets ne s’en portent que mieux.
Continuous Integration + Continuous Monitoring
Est-ce que tout le processus décrit précédemment est suffisant ? Probablement, s’il est suivi. Pourtant, après avoir cherché inspiration du côté des méthodes industrielles, certains pionniers (dont Owen) ont commencé à vouloir introduire le « continuous monitoring » dans l’ingénierie logicielle, en complément de l’intégration continue. Le monitoring continu dans ce contexte particulier, c’est un affichage :
- Visible par tous les membres de l’équipe de développement.
- Actualisé en temps réel.
- Qui donne un feedback direct sur l’état des différentes builds (ou d’une seule build importante).
- Simplifié et directement interprétable.
Ailleurs – c’est à dire dans d’autres domaines – ça peut être un panneau dans une usine qui affiche l’état de la chaine de production, ou encore un plasma dans une salle de marchés qui trace l’évolution des cours importants.
La plupart du temps, un grand écran fait l’affaire. Mais il peut y avoir pas mal d’autres solutions si on reste dans le cadre du développement logiciel. Du classique au loufoque :
- Un poste dédié, placé de façon à ce que le moniteur soit visible de tous.
- Un écran de télévision, également branché sur une unité centrale dédiée.
- Une Ambiant Orb. (Voir à ce sujet le post détaillé de Mike Swanson)
- Un cadre photo numérique wifi.
- Une Lava Lamp.
- Les LED de son Dell XPS.
- Un bonhomme de neige en verre.
- Un Nabaztag ?
La tentative du pauvre
J’ai commencé une mission de consulting il y a quelque mois dans une société pour laquelle j’ai mis en place une solution d’intégration continue pour une demie douzaine de projets .NET. Mon choix ne s’est pas porté sur CruiseControl (il s’agit pourtant d’un bon produit) mais sur TeamCity, de JetBrains, car je crois qu’il s’agit d’un produit encore meilleur.
Puisque j’en suis amoureux, j’aurai probablement l’occasion d’en reparler en détail dans un autre post. Aujourd’hui je vais juste lister les différentes fonctionnalités de notification, et proposer une piste pour mettre en place une solution de Monitoring Continu avec TeamCity.
De base, l’outil propose :
- Trois IDE Notifiers : VisualStudio, Eclipse, IntelliJ IDEA
- Un notifier par email
- Un notifier Jabber
- Un système de flux RSS complètement paramétrables
- Un notifier pour Windows
C’est très bien. Personnellement, j’ai l’habitude d’utiliser le plugin pour VisualStudio, qui me permet d’être averti et également surtout de faire des delayed commit en lançant des « private builds ». J’installe aussi le notifier pour Windows qui reste discret dans la systray entre deux notifications.
Et le continuous monitoring avec TeamCity ?
Et bien, même si cela peut sembler moins fun que l’Ambiant Orb ou le cadre photo numérique autonome et connecté à Flickr, il suffit de laisser la page concernée du dashboard TeamCity dans une session de browser web. Il est préférable évidemment d’avoir à disposition un PC dédié, et un écran visible pour lequel il n’y aura pas de veille…
Mais c’est une solution un peu triste, et relativement compromise par le manque de lisibilité de la page par défaut. Notons quand même que cette dernière se met à jour automatiquement et régulièrement. Heureusement, Jetbrains offre de nombreux moyens d’étendre TeamCity à plusieurs niveaux.
Il est notamment possible de créer des plugins pour l’interface Web, ce qui n’a pas échappé à Nat Price. Inspiré par build-o-matic, il a créé l’extension de monitoring Piazza pour TeamCity qui permet de résoudre le problème de la visibilité. Bon, on reste un peu derrière l’Ambiant Orb niveau funitude, mais on gagne quelques points grâce aux couleurs bien flashy et à la possibilité de personnaliser et d’afficher les avatars des commiters pour chaque build.
Conclusion
La plupart des outils d’intégration continue proposent aujourd’hui trop de services de notifications pour que les équipes de développement parviennent à ignorer complètement ce qui se passe sur leur serveur de build. Si un développeur ne prend pas la peine de s’en soucier, le reste de l’équipe s’en chargera et pourra éventuellement lui tirer vigoureusement les oreilles si par malheur il ose corrompre la build du trunk.
En ce sens, l’intérêt du monitoring continu peut sembler un peu limité, voire même assimilable à un délire de geek.
Je ne suis pas certain d’avoir un avis très tranché sur la question. Pour l’instant, je continue de croire qu’il s’agit d’une expérience à tenter. On pourrait même considérer le monitoring continu et son aspect techno-gadgeto-ludique comme un levier pour convaincre (ou séduire) les équipes récalcitrantes à la mise en place d’une solution d’intégration continue sérieuse. Car il y en a.
Articles
Codingly 
Je ne pense pas que ce soit superflux, je pense qu’au contraire ça responsabilise l’équipe. C’est comme si un post-it était collé sur le front « je suis encore en pause café et je suis en retard de 3mois sur mon projet » ou encore « oui je commit des bugs et j’en suis fier ».
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.
Article très intéressant, comme les autres de ton blog d’ailleurs (je m’abonne à ton flux RSS).
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 !
grozeille, Fabien > Si j’essaye de reformuler la problématique soulevée en conclusion :
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…
Il ne faut pas sous-estimer le côté ludique dans une équipe.
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
Je suis assez d’accord avec toi.
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…
J’ai l’impression personnellement que cette notion de monitoring continu s’inscrit tout à fait dans la pratique XP de « l’espace de travail informatif ».
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.