Pages

Tuesday, December 28, 2010

Intégration continue : "have fun" :-)

Je trouve que l'intégration continue est une pratique incontournable sur un projet de développement. Comme je l'avais déjà expliquée ici, la mise en place d'une démarche d'intégration continue peut ne pas prendre au niveau d'un projet de développement. Ce n'a pas été le cas sur le dernier projet auquel j'ai participé:


Un défi technique : tout doit être buildé
La mise en place d'une démarche d'intégration continue est d'abord un défi technique (en tous cas, ça peut l'être). Dans le cadre du projet dont je vous parle, nous avons un ensemble de plateformes de développements ayant des processus de builds différents (exemple : application jEE, application Iphone, application Android).

Le premier défi est donc de réussir à faire fonctionner le système d'intégration continue sur des plateformes hétérogènes. Le but est d'éviter que des membres de l'équipe plus ou moins spécialisés sur une ou deux plateformes et que celles-ci ne soient pas testées par l'intégration continue, seraient "à l'abri".

Notre serveur d'intégration continue est Hudson et notre gestionnaire de sources est Subversion. Un couple qui fonctionne bien.

Nous n'avons pas de soucis pour mettre en place l'intégration continue sur les applications jEE car nous utilisons maven pour les builder.

En ce qui concerne la plateforme Android, nous utilisons maven pour builder et signer l'application. L'intégration dans Hudson n'a pas posé de problème.

Le build Iphone est celui qui a été le plus complexe par rapport aux autres à mettre en place. Au final, avec un slave Hudson sur un de nos IMac et google comme ami pour trouver ça, ça s'est malgré tout fait assez rapidement.

Une fois de plus l'important est que tout soit buildé. Pour être transparent, on peut noter malgré tout des deltas sur le contenu des builds selon les plateformes. Par exemple, sur la plateforme Iphone, seul une compilation est effectuée alors que sur les applications jEE, il y a compilation, exécution des tests unitaires, execution des tests d'intégrations et déploiement.

Hudson notifie tous les membres de l'équipe par mail sur un build failed ou fixed.

 Un défi organisationnel : elle doit être adoptée par toute l'équipe
L'intégration continue c'est aussi et surtout une démarche et un fonctionnement d'équipe!
Comme je l'ai déjà dit, il ne sert à rien d'avoir une superbe plateforme d'intégration continue si un build cassé n'entraîne pas une mobilisation de l'équipe pour résoudre le problème. Même si normalement l'intégration continue est un outil pour aider l'équipe, il est parfois vu comme un outil "gênant".

Pour motiver l'équipe, il faut ajouter du fun :-). Le fun sur notre projet, pour simplifier, c'est d'être un peu ridicule le temps de corriger un build cassé. Voici notre règle : si tu casses l'intégration continue, c'est toi qui porte le chapeau jusqu'à ce que le build soit réparé. Et quand on dit porter le chapeau, c'est au sens propre et il y a même le choix :


Personne n'y a échappé sur le projet. Comme vous allez pouvoir le constater, il y a des têtes à chapeau ou pas.... On retiendra le "ou pas" dans l'équipe... :-). Juste pour repositionner le contexte, nous évoluions à cette époque sur un open space de 30 à 40 personnes qui n'étaient pas concernées par ce projet...

Au passage, merci à tous les membres de l'équipe d'avoir accepté que je publie les photos.

Je vous laisse découvrir ce que cela peut donner  : 

Bon ok, je commence par moi :
Une version sobre, discrete, ça passe presque inaperçu : 

Une version plus "je vous jure que c'est pas moi" :

Une version "pair programming", assez rare à obtenir :

version "total style" : 

version "j'assume" et en plus en vidéo :

version "faire abstraction, je suis au téléphone avec le client" : 

version "represent" : 

Au delà de ça, on va vu des comportements très intéressants émerger au niveau du projet :
  • Le temps de découverte du build cassé était très court : C'était en général un des membres de l'équipe qui venait gentiment déposer le chapeau sur la tête de la personne qui a cassé le build (le dernier commiteur). On devait être, la plupart du temps, en dessous des 30 secondes après que la notification par mail du "build failed".
  • Des temps de résolution de build cassé assez court aussi. De l'ordre de 15 minutes. C'est qu'en plus, ils grattent et ils tiennent chaud ces chapeaux :-)
  • Le fun, c'est contagieux : Il se trouve que le projet voisin du notre sur l'open space faisait aussi de l'intégration continue, le principe du ridicule a été réutilisé, je dirais même amélioré... Je vous laisse juger par vous même : 

Je crois qu'au final je préfère nos chapeaux :-).

Tout ça pour dire
que l'intégration continue n'a pas été vécue comme une contrainte au niveau de l'équipe. Bien au contraire : 
  • c'était un moyen d'améliorer la qualité sur le projet (notamment la qualité des commits)
  • c'était un moyen d'avoir du fun sur le projet et le fameux "team spirit".

1 comment:

Jérémie said...

Belle application du "fun factor" ou comment guider les gens a faire l'effort de ce qu'ils ne seraient pas naturellement amenés a faire ! Une illustration dans un tout autre domaine : http://www.youtube.com/watch?v=8vK4OVaR61g&feature=youtube_gdata_player