Conférence CitConf Europe 2009

La conférence CitConf signifie "Continuous Integration and Testing Conference". Autrement dit, c'est LA conférence qui traite des sujets sur les tests et l'intégration continue. Elle est proposée par l'Open Information Foundation.

La conférence CitConf existe depuis 2006. Elle a lieu chaque année, et sur trois continents : l'Amérique du Nord, l'Europe et l'Asie (à l'exception de 2006 qui n'était présente qu'aux Etats-Unis et en Europe).

Concernant les Etats-Unis, ce sont Chicago (2006), Dallas (2007), Denver (2008) et Minnéapolis (2009) qui ont accueilli la conférence. La session de 2010 aura lieu à Raleigh-Durham.

Pour l'Asie, c'est essentiellement l'Australie qui a joué le rôle de terre d'accueil, avec Sydney (2007), Melbourne (2008) et Brisbane (2009). Toutefois, la Nouvelle-Zélande a été sélectionnée pour l'édition CitConf Asia 2010.

Enfin, pour l'Europe, c'est tout d'abord Londres (2006), Bruxelles (2007), puis Amsterdam (2008), et enfin, bien sûr, Paris (2009) qui ont accueilli la conférence.

Cinq villes sont encore en lice pour recevoir la CitConf Europe 2010 : Zürich, Belgrade, Dublin, Copenhague et Prague.

Il est possible de retrouver l'intégralité des éditions de CitConf sur le Wiki du site officiel.

I-C-1. Lieu▲

I-C-2. Audience▲

I-C-3. Programme▲

Dans la quasi-totalité des conférences, le programme est défini bien à l'avance, les sujets et les orateurs sont ainsi connus de tous. CitConf a fait le pari, avec succès d'ailleurs, de miser sur le principe de l'"Open Space".
Le concept ?
Chacun est libre de proposer un sujet qui l'intéresse. Il n'y a aucune restriction, aucun sujet tabou. Lorsque l'on propose un sujet, on en fait un très court résumé en expliquant pourquoi on souhaite aborder ce sujet. Le sujet est alors écrit sur un post-it, et collé sur un tableau.

Une fois les sujets proposés, nous passons à la phase des votes, où chaque participant vote pour les sessions qui suscitent son intérêt et auxquelles il souhaite assister. Enfin, les sujets les plus populaires sont ventilés dans les différentes sessions (cinq sessions en parallèle réparties dans cinq salles).

Une autre originalité du principe de l'Open Space, est que le planning est dynamique : chaque session peut être déplacée dans le planning, et ce même quelques minutes avant son début. Et une fois encore, ce sont les participants eux-mêmes qui opérent ces changements. Nous pouvons ainsi dire que CitConf est une "wiki conférence" ou encore une "conférence pilotée par la communauté"...

Au cours d'une session, c'est généralement à la personne qui a soumis l'idée que revient le rôle de diriger la discussion, de la faciliter. D'où son nom de facilitateur. Ce n'est pas nécessairement lui qui va parler le plus dans la session. En effet, il s'agit la plupart du temps de débat, donc chaque personne de l'assistance est libre - et encouragée - de participer à la discussion.

Une dernière règle existe dans le principe de l'"Open Space" : "la règles des deux pieds". Cette règle stipule que si une discussion ne vous intéresse pas (ou plus), vous pouvez tout simplement sortir de la session et en rejoindre une autre !

Cette session avait pour but initial de savoir à quel moment on peut considérer que les tests sont terminés, finis. Sans surprise, en demandant de définir la notion de terminé à dix personnes différentes, nous obtenons dix réponses différentes !

Alors qui est en charge de cette décision ? Est-ce le chef de projet ? Les développeurs ? Le product owner ?

Ainsi, pour certains, il est nécessaire que chaque requirement soit mesurable afin de pouvoir définir si telle ou telle fonctionnalité peut être effectivement considérée comme terminée. Pour d'autres, c'est la responsabilité de l'utilisateur final de considérer qu'un produit, ou une fonctionnalité est terminée. Ou alors le simple fait de passer en production permet-elle de dire que nous avons terminé ? Enfin, certaines personnes ont également soulevé l'impact non négligeable de l'aspect commercial sur la date de livraison d'une application. Par exemple, il est parfois difficile de repousser la sortie d'un logiciel et ainsi rater un événement important (par exemple les fêtes de fin d'année), quitte à faire l'impasse sur une qualité optimale...

Evidemment, cette session ne nous a pas permis de clore définitivement le débat sur la définition de terminé ("done"). Toujours est-il qu'il a été intéressant de partager nos opinions, et pas uniquement selon le point de vue du développeur. Une chose sûre est qu'à 11 heures, la session était bel et bien terminée :)

Ici, il n'était pas vraiment important de faire de la publicité pour le TDD, le "Test Driven Development", ou encore le "Développement Piloté par les Tests". En effet, l'audience de la CitConf est généralement constituée de personnes qui sont convaincues de l'intérêt de la méthode. Pour les participants à cette session, le TDD pourrait se définir comme une méthode pour écrire plus rapidement du code qui marche ("With TDD, you write working code faster"). Alors de quoi avons nous parlé ? Essentiellement de la façon de répandre cette pratique au sein des sociétés pour lesquelles nous sommes parfois amené à travailler.

Le Coding Dojo semble être l'une des meilleures solutions pour faire adopter le TDD. Autrement dit, c'est la mise en pratique du TDD qui permet aux développeurs de changer leurs habitudes, et de développer en utilisant cette méthode. Le Coding Dojo préconise ainsi de travailler en petit groupe (quelques personnes seulement) sur un problème bien particulier. Travailler sur un sujet totalement différent des projets sur lesquels les développeurs travaillent habituellement est absolument indispensable, du moins au début. Un jeu, par exemple, peut également donner un aspect encore plus ludique à la chose. L'utilisation d'un autre langage (Ruby par exemple) peut-être aussi une bonne chose, pour vraiment exclure les (mauvaises) habitudes des développeurs. A condition toutefois d'avoir au moins une personne experte dans ce langage, pour éviter de perdre du temps avec des problèmes techniques.

Le souci principal reste tout de même de pouvoir réaliser concrètement ces exercices. Il n'est effectivement pas toujours évident de pouvoir prendre une ou deux heures des développeurs pour réaliser un travail qui ne semble pas être productif pour les managers. Antony Marcano, de pairwith.us, nous a donné quelques conseils pour arriver à cette tâche avec succès. Ainsi, on pourra commencer doucement, en prennant une heure (ou un peu moins) durant la pause du midi pour débuter ces exercices.

Un autre détail notable est que pour certaines personnes présentes dans ce débat, il est plus facile de faire apprendre le TDD à des développeurs juniors qu'à des "séniors", peut-être trop attachés à leurs habitudes... Toutefois, une relative mise en concurrence de ces personnes peut amener les refractaires à changer leur vision du TDD et de l'adopter.

Dernier point abordé dans la session : que faire du legacy code (code hérité et théoriquement plus supporté) en TDD ? La réponse est assez claire : il ne faut pas y toucher ! Le code legacy doit donc être évité, et éventuellement refactorisé par petits morceaux.

Lors de cette session, nous avons beaucoup parlé d'intégration continue et de Cloud Computing. Pour rappel, le Cloud Computing fait "référence à l'utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau". Autrement dit, il s'agit d'un service vous permettant d'installer une application ou un service sur un parc important d'ordinateurs, sans avoir à se soucier des aspects techniques, de maintenance. Nous avons essentiellement pris en exemple le serveur d'intégration continue Hudson et le service Amazon EC2 (Amazon Elastic Compute Cloud). Un plugin existe d'ailleurs pour relier les deux.

Tout d'abord, nous avons commencé par un petit sondage : combien de personnes dans l'audience utilisent le Cloud Computing pour optimiser son intégration continue ? Très peu de mains levées. Le concept est sans doute encore trop neuf ?

Les intérêts du Cloud Computing pour l'intégration continue sont pourtant assez clairs :

• Réduction des coûts pour la maintenance de l'infrastructure.
• Optimisation de l'utilisation des CPU.
• Répartition de la charge, permettant ainsi de mieux gérer les pics d'utilisation du service.

Toutefois, cette solution a également ses désavantages :

• La sécurité. Utiliser un service de Cloud Computing implique de devoir mettre à disposition son code source.
• La confiance envers le fournisseur de services. Toutefois, certaines personnes dans l'assemblée se sont demandées si elles avaient plus confiance dans un service payant que dans leur propre service IT ;o)
• Les problèmes de réseaux pouvant rendre indisponible l'intégration continue.

Laurent Bossavit, entre autre président de l'association XP-France, a réalisé une session amusante et intéractive pour clôturer cette conférence. Il nous a indiqué avoir déjà pratiqué ce petit jeu lors de la conférence Agile 2009 de Chicago en août dernier. Le principe de "100 learning ideas" est basé sur l'approche de la "boîte morphologique" ou encore appelée "Zwicky box". Il s'agit tout d'abord d'établir une matrice dont les lignes correspondent à des concepts et les colonnes à des catégories. Etant donné que nous sommes restés dans le monde de l'informatique et du développement logiciel, nous avons choisi pour les lignes les concepts suivants :

• Shared notebook (ordinateur partagé)
• Tweeting
• Daily meeting (meeting journalier)
• Open space
• Review (revue)
• Visible signs (signes visuels)
• Coding dojo
• Pairing (travail en binôme)
• ...

Pour les catégories, nous avons pris :

• Target audience (public visé)
• Format
• Involvement (implication)
• Required material (matériel requis)
• Inspiration
• Frequency (fréquence)

Dès que la matrice est établie, on la remplit avec des valeurs toutes différentes. Par exemple, dans la colonne "fréquence", on utilisera les valeurs "chaque lundi", "une fois par semaine", "trop souvent ;)", etc. Pour l'"audience cible", on utilisera "décideurs", "managers", "développeurs", etc. Pour l'"implication", nous avions ainsi choisi des valeurs de type "--", "-", "+" ou encore "++". Et ainsi de suite, jusqu'à remplir tout ou partie de la matrice (compte tenu du temps imparti, nous n'avons pas rempli la matrice entièrement, ce qui n'est pas très grave toutefois).

Une fois ceci fait, chaque participant pioche au hasard une valeur dans chaque catégorie. Par exemple, en ce qui me concerne, j'ai hérité des valeurs suivantes :

• Public cible : les décideurs.
• Format : en ligne.
• Implication : +.
• Matériel requis : enregistreur vidéo.
• Inspiration : esprit de groupe.

Une fois ces tirages réalisés, chaque participant doit alors essayer de trouver un concept répondant aux valeurs des catégories choisies. Le résultat est plutôt amusant, et demande une certaine créativité, surtout si l'on choisit beaucoup de catégories plutôt variées.

Nous avons terminé la session par une sorte de retrospective, en soulignant ce qui était intéressant, ce qui l'était moins et les améliorations possibles. Je pense ainsi que Laurent Bossavit nous ressortira une version encore améliorée de "100 learning ideas" lors de prochaines conférences, Agile Paris (ex-XP Day) 2010 devrait en faire partie.

D'autres sujets ont été traités durant cette journée de la conférence :

• Better Ant builds, de meilleurs builds avec Ant.
• Hudson and other plugins, Hudson et ses plugins.
• Mock objects, objects Mock.
• Build pipelines and continuous deployment, ligne de builds et déploiement continu.
• Acceptance testing, tests d'acceptance.
• Faster tests, des tests plus rapides.
• Build metrics, des métriques sur les builds.
• Putting Selenium in the right place, remettre Selenium à sa place.
• CI antipatterns and kitchen sink, les anti-patterns sur l'intégration continue.

On pourra trouver un descriptif des discussions sur ces sujets dans le Wiki de la conférence, ici. Un certain nombre de bloggueurs (voir chapitre sur les références) ont fait un résumé de certaines de ces sessions, je vous invite donc à y jeter un oeil !

La journée du samedi s'est finalement conclue comme elle a commencé, à savoir par un tour de "table" (ou plutôt "tour de salle", car avec 120 participants, il aurait fallu une très grande table !). Cette fois-ci, chaque participant était invité à dire quel avait été son "AA moment", autrement dit son coup de coeur de la journée. Beaucoup ont déclaré avoir vraiment adoré les divers échanges qui ont pu être menés lors de la conférence, et en particulier ceux en dehors des sessions.