Archives mensuelles : février 2012

image

The Siren of Shame

J’aime utiliser des gadgets en entreprise. L’objectif de ceux-ci est d’apporter un côté ludique qui permet de faciliter le travail de l’équipe tout en dédramatisant les choses.

C’est donc avec grand plaisir que j’ai découvert la “Siren Of Shame”.

Ce gadget est en réalité constitué de deux parties :

  • L’élément visible qui est le gyrophare USB qui s’installe en 1 clic de souris
  • Un outil de monitoring qui est capable de se connecter aux principaux serveur d’intégration continue du marché (TFS, Team City, Cruise Control.net, etc.)

L’objectif est simple : alerter de manière visuelle et sonore dès qu’une build est cassé pour la réparer au plus vite.

image

L’installation du logiciel se fait de manière très simple et la configuration est également aisée. En 5 minutes, le système est fonctionnel et nous sommes capables de tester les différents styles de lumière (gyrophare tournant, fondu de lumière, etc.) et de définir jusqu’à quand nous souhaitons avoir les signaux sonores et lumineux (signal pendant un laps de temps défini ou jusqu’à ce que la build soit réparé, etc.).

L’outil propose de plus 3 fonctionnalités intéressantes :

  • Un tableau de bord permettant de voir l’état de toutes les builds
  • Un outil de réputation qui permet d’avoir une liste triée des développeurs selon un ratio nb de buils/nb de builds échouées
  • Un graphique simple d’analyse de l’état d’une build

image

Un outil donc fort simple, qui fait uniquement ce qu’on lui demande sans trop de fioritures.

Avant de vous décrire mon retour d’expérience du système (cela fait un mois que nous l’avons à présent adopté), je vais vous retracer l’historique de la mise en place du serveur de build dans le service afin de bien décrire l’intérêt d’utiliser ce type de gadget et l’effet obtenu.

Pourquoi un serveur de build ?

Une de mes premières actions lors de mon arrivée à Log’in Space il y a maintenant 1 an a été d’analyser l’environnement de développement pour voir comment il était possible de rendre l’équipe plus efficace.

Le service développement fait très fréquemment des releases des différents produits, la création d’une version prenait alors environ 1h lorsqu’il n’y avait de problèmes, et durait beaucoup plus lorsque un problème de compilation non détecté avait lieu.

Les développeurs avaient l’habitude d’effectuer leur checkin après avoir terminé sans forcément faire de getlatest réguliers. Le code présent sur le source control était différent de celui présent sur les postes de développement et de temps en temps il arrivait que le responsable de la release ait une surprise en essayant de compiler le résultat final…

Afin de résoudre ce problème et être beaucoup plus réactif en cas de problème (ie. ne plus être devant le fait accompli mais réagir dès qu’il y a un problème) un serveur de build sous Team Build a été mis en place.

La première étape a été de simplement automatiser la création d’une version, puis de mettre en place de l’intégration continue (plus proche actuellement de la compilation continue). Ainsi chaque développeur est abonné aux alertes proposées par TFS, et est ainsi notifié de la réussite ou de l’échec de la build déclenché par son check-in. De plus l’automatisation a permis de réduire le temps de création d’une version à 15min.

Il s’agit d’un progrès dans le sens où l’on est beaucoup plus réactif mais il me restait à arriver à sensibiliser l’équipe sur le fait de vraiment prêter attention à avoir un code correct et fonctionnel dans le source control, afin d’avoir le plus rarement possible un code invalide.

Et cet objectif a été atteint grâce à la sirène. Les membres de l’équipe souhaitant éviter que la sirène ne s’allume, ils pensent à présent bien aux risques apportés par leur check-in avant de faire leur commit ! La sirène est en effet mise en avant et bien visible de tous, il n’est donc pas nécessaire qu’elle s’allume pour que tout le monde ait conscience de sa présence.

Encore un (tout petit pas) de franchi vers une meilleure qualité logicielle et vers moins de stress pour l’équipe !

Il reste bien évidemment de gros progrès à accomplir  comme l’intégration de l’exécution de tests automatisés par exemple, mais il s’agit d’une évolution qui va dans le bon sens.

Les + et les –

Les +

  • Outil simple à mettre en œuvre, qui fait uniquement ce qu’on lui demande
  • Une API est disponible pour piloter la sirène dans d’autres contextes que l’intégration continue

Les –

  • Lorsque deux builds échouent “en même temps”, les signaux s’arrêtent lorsqu’une des builds a été réparé et non lorsque l’ensemble des builds ont été réparés
  • Très légers bugs dans l’affichage des changesets liés aux builds lors de check-in très rapprochés

Les risques Sourire

J’ai pu identifier deux risques durant ce premier mois d’utilisation.

Le premier concerne les prestataires intervenants sur un de nos projets. L’un deux a eu la bonne idée de casser et de réparer la build entre midi et deux. L’équipe étant en train de déjeuner la sirène a été d’une totale inefficacité ! Il peut être intéressant de garder le système d’alertes afin d’avoir un réel suivi des builds.

Second risque : Si vous mettez Kool & The Gang au bureau afin de mettre un petit d’ambiance, il se peut qu’un membre de votre équipe vous propose d’allumer le gyrophare en cassant une build histoire d’avoir une ambiance son et lumière Smile (oui, oui c’est du vécu…)