L’édition européenne 2009 de la CITCON a eu lieu les vendredi 18 et samedi 19 Septembre à Paris, j’ai eu la chance de pouvoir y assister et je vous livre aujourd’hui mon compte-rendu.

Vendredi après midi, arrivée dans les locaux de l’ISEP, Paul Julius et Jeffrey Fredrick nous accueille avec un mot de bienvenue et des explications sur le fonctionnement d’une conférence Open Space, puis un tour de table pour une présentation rapide des personnes présentes: environ 120 ! Un peu longuet, mais cela me permet de mettre enfin des visages sur les différents blogueurs et twitters que je suis régulièrement.

Arrive les choses sérieuses: la préparation du programme de lendemain, en effet dans le cadre d’une conférence Open Space, tous les participants sont acteurs: chaque personne souhaitant animer une session s’arme d’un stylo, d’un post-it, présente son sujet en quelques mots et l’ajoute au tableau blanc. Libre à chacun de voter, regrouper les propositions équivalentes, modifier le planning.

Et voici le résultat

Nous avons bien travaillé, il est maintenant l’heure de manger et de partager une bière en parlant d’intégration continue, de testing et de nos différentes expériences.

~~~~~~~~

Tout bon Samedi commence par un bon petit déjeuner, la CITCON ne déroge pas à cette règle et nous commençons donc la journée par des discussions informelles autour d’une montagne de croissants. Le choix des sessions n’est pas évident, il y en a 5 programmées à la fois !

A 10 heures, je commence donc la matinée par la session “Better builds“, intéressante mais qui se focalise uniquement sur Ant, du besoin de refactoring des scripts, de l’utilisation des macros et une présentation de Ant Script Library, qui comme son nom l’indique est une bibliothèaue de scipts génériques permettant de gérer les dépendances (avec Ivy), compiler, packager, lancer des tests unitaires ou d’intégration, faire du reporting, … bref tout ce qu’offre nativement Maven ! J’ai toujours du mal à comprendre pourquoi certaines personnes s’obstinent avec Ant pour cette utilisation … J’applique donc “the Law ot two feet” : je change donc de session discrètement et je rejoins “Hudson plugins“.

Lorsque j’arrive Douglas Squirrel a déjà présenté un plugin qu’il a développé et la discussion continue donc sur les points forts et faibles de la création de plugins. Du côté négatif l’utilisation particulière de jelly pour la création des vues, le wiki dont certaines pages ne sont pas mise à jour, du côté positif, kohsuke kawagushi et la communauté qui sont très actifs et l’utilisation de Maven qui permet de démarrer et déboguer un plugin extrêmement simplement via les commandes mvn hpi:create et mvn hpi:run. Nous avons ensuite évoqué les plugins existants qui pourraient être améliorés (Promoted builds par exemple) et de nouvelles idées: graph de dépendance entre builds, distribution des tests unitaires avec GridGain …

~~~~~~~~

11h15, 2ème session de la matinée (enfin 2ème et demi pour moi): “Continuous Deployment” animée par Chris Read. Tout d’abord qu’est ce que le déploiement continu ? L’idée est que chaque fois que du code est committé, il est automatiquement déployé en production ! Impossible ? Regardez donc le bas de cette page chez Flickr: http://code.flickr.com/, la dernière fois que j’y suis allé, on pouvait lire : ”Flickr was last deployed 25 hours ago, including 3 changes by 1 person. In the last week there were 46 deploys of 967 changes by 17 people.” Évidemment les contraintes pour faire du déploiement continu sont énormes, il faut être capable d’automatiser toute les étapes du commit du code jusqu’au déploiement en production: compilation, packaging, tests unitaires, d’intégration, d’acceptance, de performance et évidemment le retour à une version précédente en cas d’erreur.

Nous sommes d’ores et déjà capable de le faire avec les outils d’intégration continue, mais pour le faire de façon plus optimale, Chris introduit la notion de build pipeline c’est-à-dire le découpage en étape du processus de déploiement. Malheureusement cela sert également de support pour une promotion commerciale de Cruise, outil d’intégration continue de ThoughtWorks qui supporte nativement les pipelines … Malgré tout la discussion reste intéressante car le concept de déploiement continu permet d’avoir une vision plus globale du développement d’une application: on ne construit plus seulement un logiciel mais un environnement complet car les contraintes de la production (OS, patch, …) sont pris en compte dès le début du processus. nous dépassons alors le concept cher à XP de “Collective Code Ownership” pour arriver au “Collective Environment Ownership”.

~~~~~~~~

La pause repas est l’occasion de discuter, notamment avec Remy Sanlanville, qui présentera avec Freddy Mallet de SonarSource la session “Pour passer la crise, remboursez votre dette technique !” à l’occasion de l’agile tour 2009 à Grenoble le 20 Octobre prochain et très probablement à Genève le 12 Octobre

~~~~~~~~

14 heures, je commence l’après-midi par la session “Acceptance Testing” animée par Gojko Adzic et Antony Marcano. L’objectif de la session est de faire le top 5 (ou plus) des raisons pour lesquelles une équipe échoue à mettre en place des tests d’acceptance et de donner des pistes pour ne pas tomber dans ces travers. Lors de l’écriture de son livre “Bridging the Communication Gap, Specification by Example and Agile Acceptance Testing“, Gojko avait identifié 5 principales raisons:

• No collaboration
• Focusing on “how” not on “what”
• Tests unusable as live documentation
• Expecting acceptance tests to be a full regression suite
• Focusing on tool

• Acceptance testing is not considered as “value-adding” activity
• “test code” is not maintained with love
• Objectives of team members not aligned
• No management buy-in
• Underestimating the skill required to do this well

Alors que faire pour ne pas tomber dans le panneau:

1. Les tests d’acceptance s’écrivent en équipe: vous et votre client, ce sont des spécifications !
2. L’important n’est pas “comment” faire mais “quoi” faire et ce n’est pas si évident.
3. Vos tests d’acceptance doivent être expressifs et exhaustifs car ils seront alors la vraie documentation du projet, n’oubliez pas ce sont les spécifications !
4. Ces tests ne sont pas des tests de régression, il y a d’autres outils pour cela, ce sont des spécifications !
5. Ne venez pas voir votre client avec un outil, Fitnesse est très bien, mais vous venez écrire des spécifications ! Un tableau blanc et des crayons sont bien plus appropriés, vous aurez tout le temps de traduire ces spécifications dans votre outil préféré après.
6. L’écriture des tests d’acceptance est considérée souvent comme secondaire alors que nous parlons des spécifications !
7. Le code des tests est considérés comme moins important que le code métier, pourtant si vous n’êtes pas capable de valider votre code au regard des spécifications …
8. L’objectif des différents membres de l’équipe doit être le même: délivrer la meilleure application possible pour le client et pas le développeur code et pas plus, le testeur teste et pas plus, …
9. Le management doit percevoir les tests différemment car ce sont les spécifications !
10. Ne sous estimez pas le niveau requis pour écrire ces tests d’acceptance !

~~~~~~~~

15h15, un sujet qui m’intéresse au plus haut point: “CI in the Cloud” car j’avais commencé à écrire un plugin Hudson pour démarrer des esclaves sur EC2, le cloud d’Amazon. Malheureusement pour moi, un certain kohsuke l’a développé bien plus vite que moi (voir ici) ! Mais revenons au sujet, pourquoi les différents outils d’intégration continue lorgne du côté du cloud computing ? Les raisons sont multiples et nous les énumérons:

• réduire les coûts d’infrastructure et de maintenance
• optimiser le coût d’utilisation par CPU (chez Amazon, la tarification se fait sur le uptime)
• absorber facilement les pics de charge.

• le gros point noir: la sécurité, bien que des solutions existent (on peut monter un VPN avec des serveurs chez Amazon), peu de sociétés sont actuellement prêtes à voir leur code source partir en dehors de leur infrastructure propre.
• la confiance envers le fournisseur du cloud.  Le touilleur a d’ailleurs posé une question pertinente: “à qui faites vous le plus confiance: votre équipe d’admin système ou celle d’Amazon ?”. Personnellement je connais la réponse !
• les problèmes réseaux peuvent rendre le système quasi inopérant
• la maintenance de système complexe sera aussi difficile

~~~~~~~~

Rendez-vous pour la prochaine édition dans l’une de ces villes: Zürich, Copenhage, Belgrade, Dublin ou Prague. Je vote Dublin !

• l’Agile Testing regrouperait l’ensemble des pratiques de test appliquées à une démarche de projet Agile, c’est à dire l’implémentation et l’automatisation de tests unitaires, l’intégration continue, le Test Driven Development, etc …

• Le Testing Agile serait la mise en oeuvre d’une démarche Agile dans les processus de test, de quelque nature ou de quelque niveau qu’ils soient.  Et pourquoi pas dans une démarche projet globale en cascade.

On voit bien alors qu’il ne s’agit plus de la même chose.
J’ai suivi le cursus de Scrum Master, toutefois la place du test au sein de la démarche n’a été que survolée. J’ai donc pris la liberté de réfléchir sur le sujet, à défaut de trouver beaucoup de littérature.
Ainsi si beaucoup de choses ont été dites et écrites sur le premier point, il en reste encore beaucoup à dire sur le second.

Je vais donc programmer un  Mardi Gras sur mai ou juin (mars : Intégration continue, avril : présentation ITIL), afin de présenter mes idées sur le sujet et obtenir vos remarques et retours d’expériences.

Avis aux amateurs !