Ca Scrum !

Lorsque l’équipe a exprimé l’envie de faire de « l’intégration continue », je me suis bien demandé de quoi ils pouvaient me parler. Wikipédia étant notre ami, voici ce que nous avons lu :

L’intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l’application en cours de développement. Bien que le concept existait auparavant, l’intégration continue se réfère généralement à la pratique de l’extreme programming.

Et là, l’équipe était bien embêtée : « Ben, euh … On voulait surtout que notre application soit plus facilement packagée et installable. On peut faire quelque chose quand même ? Et puis t’as vu, c’est agile ! « .Touché.Wikipédia donne en effet une définition qui semble plus parler de tests automatisés, déclenchés à chaque modification de code. Nous avons donc organisé différents ateliers pour définir nos besoins et notre vision de « l’intégration continue ».

Notre contexte :

1. Nous sommes dans une entreprise client finale. (Il faut donc penser aux contraintes liées à l’hyper-réactivité en cas d’incident de production ; mais aussi savoir en tirer les bénéfices !)
2. Nous développons une application critique pour l’entreprise (Comme tout le monde ? :p)
3. Nous développons une application web (J2EE), très fortement dépendante de la base de données.
4. L’équipe contient des « DevOps » ; c’est à dire que nous intervenons sur toute la chaîne de production (De la réalisation à l’installation en production).
5. Nous avions envie de faire des tests, s’ils sont facilement réutilisables
6. Nous avions trouvé que Hudson, c’est un outil qui semble joli
7. Nous voulions améliorer nos problèmes de régression
8. Nous voulions accélérer notre processus de livraison (Cycle en V, 4 jours d’intégration, rupture de café, grande phase de recette, régression, dépression …)

Bref, on sentait qu’il y avait une idée à creuser derrière tout ca, surtout pour nous aider dans notre transition vers l’agilité ! Nous avons donc travaillé à identifier (par environnement) les différentes étapes qui composaient notre chaine de production logicielle. Nous avons essayé de trouver quelles actions étaient communes à chacune des étapes. Notre volonté était que l’étape « Critique », c’est à dire l’installation de l’application, soit identique dans tous nos environnements (sinon, ca sert à rien de faire des tests, hein ?). Toutes les particularités liées aux environnements doivent être portées par l’environnement (Variables d’environnement, fichiers de configuration, …).

Une fois ce travail réalisé, nous avons essayé de trouver quel était le meilleur outil pour chacune de ces 7 étapes : l’équipe a confirmé son intuition d’Hudson pour toute la partie gestionnaire de ressources, traçabilité, séquenceur d’évènements.

Pour les fonctionnalités plus technique, l’équipe a fait le choix de script Ant. La mise en œuvre s’est faite de manière incrémentale sur une petite semaine. (Je parlerai de la mise en œuvre des tests dans un prochain papier)

Depuis, tous les matins, l’application est prête (packagée, livrée, testée) avant la machine à café, c’est fou hein ?

L’intégration continue n’est pas une obligation ! Mais quand même … Ça aide bien !

Un des piliers du Manifeste Agile est le suivant : « l’interaction avec les personnes plus que les processus et les outils ». Certains bons processus et bons outils aident aussi à favoriser la mise en place de l’agilité !

Notre bilan après quelques mois :

1. Nous n’avons plus de problème lors de nos installations en production. Notre investissement « raisonnable » vers plus de qualité a été vraiment payant !
2. Nous avons améliorer la qualité de notre livraison : nous avons beaucoup moins de problème de régression (Merci les tests automatisés)
3. Nous avons réduit à 30 minutes (et de manière automatique) une étape qui pouvait nous prendre jusqu’à plusieurs jours à l’équipe.
4. L’équipe n’est plus inquiète de livrer l’application en production
5. Nos utilisateurs ne sont plus inquiets lorsque nous livrons une application en production :)