Integration Continue avec Play! et Jenkins

On parle souvent de Play! pour dire que c'est un super framework pour faire du web simple, efficace, génial, fun, wouahou, ...

(Pour infos, si vous n'étiez pas au courant, la version 2 de Play! vient de sortir. Plus d'infos ici)

On peut aussi dire que c'est un framework web qui permet de faire du TDD, de faire des tests unitaires, des tests d'intégrations et des tests selenium. Bref, faire du test avec Play!, ça n'est pas un problème. Je peux d'ailleurs vous le confirmer car j'ai pu tester la mise en oeuvre d'une démarche TDD sur une application play! avec succès.

Il est même possible, en faisant attention à quelques petites choses, de faire de l'intégration continue avec Jenkins et Play!  (1.X) :

Assurer que vos tests fonctionnent en local

Assurez-vous que vos tests sur votre poste de développement soit bien exécutés par Play! lorsque vous faites un :

play auto-test

Si ce n'est pas le cas, ça ne sert à rien d'aller plus loin. Il faut déjà régler ce problème. Ça a été mon cas. Cela peut provenir de là : Vos tests unitaires doivent impérativement hériter de : UnitTest ou BaseTest (une classe abstraite de Play!) sinon vos classes de tests unitaires ne seront pas exécutées : 

https://play.lighthouseapp.com/projects/57987/tickets/1074-feature-request-run-junit-tests-not-extending-basetest

Installer le Jenkins play-plugin
Comment déployer une application Play! dans Jenkins? : "There's a plugin for that"

Il y a en effet un plugin pour ça : jenkins play-plugin.

Vous pouvez suivre la procédure d'installation indiquer dans la documentation du plugin :

- Décompresser le zip de Play! sur le serveur qui héberge Jenkins dans un répertoire de votre choix.

- Installer le plugin Play! dans Jenkins par l'intermédiaire du menu d'administration de Jenkins.

Créer un Job

Il suffit ensuite de :

• créer un job freestyle.
• définir l'url de votre DVCS. (Je n'ai aucun doute, que vous allez saisir une url Git :-)).
• définir ce qui déclenche les build (personnellement, je scrute l'outil de gestion une fois par heure : 5 * * * *).
• Ajouter une étape au build : Play!
• Renseigner les commandes play à exécuter. A la différence de la documentation du plugin et comme le serveur se trouve derrière un proxy d'entreprise voici la liste des commandes que j'ai saisies : 
• clean
• dependencies --sync -Dhttp.proxyHost={your-proxy-host} -Dhttp.proxyPort={your-proxy-port}
• auto-test

(Je n'ai pas réussi à faire fonctionner l'option --deps qui aurait permis de grouper la commande 2 et 3 comme décrit dans la doc du plugin en faisant simplement :  "auto-test --deps").

• cocher : "Play! auto-test reports" pour générer les rapports Play! intégré dans Jenkins.
• notifier par email ceux qui doivent l'être.

et c'est tout : run... et hop ça marche.

Vous pouvez voir les rapports d’exécution dans le détails de l’exécution du job dans le menu latéral "Play! Test Result"

Bref, je fais de l'intégration continue avec Jenkins et Play!.

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

Causes d'échec de l'Intégration continue

Dans certain cas, aux yeux d'une équipe de développement, l'intégration continue se limite à recevoir un mail quand le "build" de l'application échoue. Le problème est que l'intégration continue ne se limite pas seulement à ça...

Il ne faut pas oublier que l'intégration continue n'est pas qu'un outil mais bien un ensemble de pratiques autour de l'ingénierie logicielle. Dans un de ces articles, Martin Fowler présente les pratiques d'intégration continue sur son site.

Voici quelques causes probables d'échecs sur la mise en place d'une démarche d'intégration continue :

• un manque de connaissances de l'ensemble des pratiques d'intégration continue par l'équipe (y compris les managers).

• une mise en place d'un serveur d'intégration continue au niveau d'une équipe projet sans communiquer, informer sur les bénéfices de ce type de démarche et intégrer les principes de fonctionnement que cette mise en place entraine.

Si la volonté de mettre en place ce type de démarche ne vient pas de l'équipe , il faut alors présenter et communiquer autour de la démarche. Il ne faut pas oublier que ce type de pratique est fait pour les équipes de développements et pour leur permettre de travailler efficacement ensemble.

L'intégration continue est avant une histoire de communication. Cela doit être une culture au niveau du projet. Il faut rendre "fun" la pratique de l'intégration continue!

Continuum, Maven2 et Clearcase

C'est possible!

Faire de l'intégration continue en utilisant le trio Continuum / Maven2 / Subversion est bien répandu. Le trio maintenant bien huilé...

Il se trouve que chez mon client, le système de gestion de contrôle de source est le produit d'IBM : Rational Clearcase.

Dans le cadre de la mise en oeuvre d'un serveur d'intégration continue, il a alors fallu faire fonctionner le trio Continuum / Maven2 / Clearcase. C'est au moment de commencer qu'on ressent un grand moment de solitude... Le but du jeu est de permettre à Continuum par l'intermédiaire de Maven de faire un "update" des sources pour vérifier si des choses ont changées et relancer une commande de build Maven.

Une particularité de Clearcase, qui reste un outil très puissant (mais un peu usine à gaz à mon gout), concerne la façon dont il structure son arborescence de sources sous forme de composants.

La difficulté principale réside dans la définition de l'url du SCM dans chacun des pom des projets.

Voici la procédure de mise en oeuvre :
*rajouter un fichier de conf clearcase sur le serveur d'intégration continue dans le fichier MAVEN_HOME/conf/clearcase-settings.xml avec ce contenu :

<clearcase-settings>
<useVWSParameter>false</useVWSParameter>
<clearcaseType>UCM</clearcaseType>
</clearcase-settings>

*rajouter l'url scm dans chacun des pom de vos projets :

 <scm>
 <connection>scm:clearcase:load \<My_Vob\My\Project\Dir>:/<PVOB_Name>:<View_Name></connection>
</scm>

où :
- My_Vob\My\Project\Dir : nom du vob dans lequel se trouve le projet + chemin d'accès à la racine du projet.
- PVOB_Name : nom du PVOB. le PVOB correspond au nom du projet racine dans le project explorer du client Clearcase.
- View_Name : nom de la vue Clearcase

*Il faut ensuite importer le pom du ou des projets dans continuum

*Il faut enfin définir des commandes maven de build dans chacun des projets. Attention! Il faut modifier le champs "Nom du fichier POM*" : au lieu de :

pom.xml

il faut préciser le chemin relatif d'accès au fichier + le nom du fichier. Il faut renseigner le champ de cette façon :

<My_Vob\My\Project\Dir\>pom.xml