IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Conférence CitConf Europe 2009

Résumé de la conférence CitConf 2009 qui s'est tenue à Paris les 18 et 19 septembre 2009

1 commentaire Donner une note à l´article (4)

Article lu   fois.

Les deux auteurs

Profil Pro

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. La conférence CitConf

I-A. Présentation

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.

Image non disponible
Les fondateurs de CitConf, Paul Julius et Jeffrey Frederick.

I-B. Précédentes éditions

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.

Image non disponible
Les conférences CitConf aux Etats-Unis

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.

Image non disponible
Les conférences CitConf en Asie

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.

Image non disponible
Les conférences CitConf en Europe

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

Image non disponible
Laquelle de ces 5 villes accueillera CitConf Europe 2010 ?

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

I-C. CitConf Europe 2009

I-C-1. Lieu

Après Londres, Bruxelles et Amsterdam, Paris est la quatrième ville à accueillir la conférence sur le sol européen. La conférence s'est tenue dans les locaux de l'ISEP (Institut Supérieur d'Electronique de Paris), dans le 6e arrondissement.

I-C-2. Audience

CitConf Paris 2009 a réuni à peu près 120 personnes venues de 17 pays différents. La France est bien évidément arrivée en tête, avec environ 60% des participants, l'Angleterre arrivant deuxième (12,5%). Notons également qu'une dizaine de belges étaient également présents.

Image non disponible

Les sessions se sont bien entendu tenues en anglais.

La liste complète des participants est disponible ici.

I-C-3. Programme

Bien que la conférence s'est déroulée sur deux jours, CitConf Paris s'est essentiellement tenue le samedi 19 septembre. La conférence a démarré le 18 septembre au soir. Mais cette première journée n'avait pas uniquement pour rôle de réaliser les inscriptions et faire une introduction, mais surtout de définir le programme du lendemain ! Contrairement à la plupart des autres conférences, ce sont les participants qui décident des sujets abordés. Ce principe est celui de l'"Open Space".

I-D. Le principe de l'Open Space

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

Image non disponible
Voilà ce que pouvait donner, à un moment précis, le planning de la conférence...

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 !

II. Premier jour

Comme dit précédemment, la première journée a été essentiellement destinée à réaliser les présentations des participants et à introduire la conférence. Malgré la présence d'environ 120 personnes, nous avons réalisé un tour de présentation, où chacun d'entre nous se présentait, puis indiquait la raison de sa présence à la conférence. Mais c'est également ce jour-là que le programme du lendemain a été élaboré par les participants eux-mêmes.

III. Deuxième jour

III-A. Done and Testing

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 :)

III-B. TDD

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.

III-C. Cloud Computing and Continuous Integration

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.

III-D. 100 learning ideas

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

Image non disponible
Notre matrice en cours de création

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.

III-E. Autres sessions

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 !

III-F. Fin de journée

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.

Image non disponible

IV. CitConf vu par Grégory Boissinot

Grégory Boissinot, un autre membre de la communauté de developpez.com, était également présent à cette conférence. Voici son ressenti.

Pour ma part, ce fut un plaisir d'assister à la conférence CitConf 2009. Se déroulant à Paris, cela a été très pratique pour y assister. En terme d'organisation, j'ai apprécié le très grand nombre de sessions disponibles et l'organisation en open-space avec la possibilité totale de pouvoir changer de salle en cours de route si cela ne vous plaît pas. Une majorité de français était présente, rien de plus normal comme la conférence était en France (et il faut bien en profiter). Il y avait également de nombreuses personnalités très connues dans le monde de l'intégration continue comme Paul Duvall, auteur du livre Continuous Integration, ou Simon Julian, auteur du blog build-doctor.com.

Les sessions étaient passionnantes avec des nombreux sujets variés comme "De meilleurs scripts Ant", "une présentation de Hudson et de ses plugins", "les tests", "les mocks" ou la définition du done et bien d'autres encore. Voici un petit retour par exemple de la session "De meilleurs scripts Ant" à laquelle j'ai pu assister :

On y a appris quelques recommandations pour avoir de meilleurs scripts Ant :

  • Ne pas faire de copier/coller mais privilégier l'importation de cibles prédéfinies.
  • Ne jamais utiliser des antcall. Rien n'est plus mauvais que cela.
  • Ne pas mettre trop de logique de programmation dans son script de build mais privilégier l'écriture d'une tâche Ant. Et limiter au maximum l'utilisation de AntContrib.

Cette réutilisation de cibles prédéfinies permet d'avoir ainsi des scripts de build minimaux ne dépassant pas 15 lignes. Et c'est ainsi que naturellement le projet Ant Script Library a été présenté. Il s'agit d'une collection de scripts Ant réutilisables pour builder une librairie Java, une application Web ou mettre en œuvre un ensemble de métriques comme Cobertura, PMD ou JDepend. C'est peu connu mais cela semble néanmoins une solution de premier choix pour de nombreux projets.

Au cours de la session, quelques alternatives existantes à Ant ont été abordées comme Buildr, Maven, Gant, EasyAnt et même Gradle. Pour le builder Gant, on y a appris par exemple qu'un grand nombre de projets JetBrains ont migré vers Gant et le retour est très satisfaisant. On comprend ainsi pourquoi IntelliJ a été le premier IDE a proposer une intégration de Gant.

Concernant EasyAnt, le projet semble très intéressant en terme de services mais malheureusement personne dans la salle ne l'avait utilisé ou essayé, ce qui n'a pas permis d'argumenter dessus. Pour les autres builders comme Maven et même Gradle, finalement, la conclusion est qu'il y a toujours un compromis entre les conventions apportées par ces outils et la flexibilité de Ant.

Ensuite, la problématique de test du script a été abordée. En réalité, on écrit un script de build pour un projet. Tester son script, c'est simplement l'exécuter sur ce projet et observer si on obtient les résultats attendus.

En conclusion, une très bonne conférence sur l'intégration continue. Il y avait d'ailleurs un sondage sur les outils de build. Au moment ou j'ai quitté la conférence, voici le résultat :

Image non disponible

Pour ma part, j'ai voté pour Ant, Maven, Gant et Gradle. J'ai oublié de voter pour Ivy (tout en bas de la liste), mais Ivy est avant tout un gestionnaire de dépendance qu'on utilise couplé à un builder comme Ant, Gant ou Gradle. L'un des constats est que je suis le seul à utiliser aujourd'hui Gradle mais de nombreuses personnes pensent qu'il s'agit d'une solution d'avenir.

V. Remerciements

Un grand merci à toute l'équipe des organisateurs pour cette conférence, et en particulier à Eric Lefevre-Ardant qui a rendu possible cette édition française de CitConf. Merci également à Jeffrey Frederick et Paul Julius, les co-fondateurs de l'Open Information Foundation.

Image non disponible
CitConf, c'est aussi de superbes discussions bien accompagnées !

Merci également à Grégory Boissinot pour m'avoir fait part de son bilan sur la conférence.

Enfin, merci à mlny84 pour sa relecture attentive de l'article !

VI. Références

Le Wiki de la Conférence regroupe un bon nombre d'informations, en particulier le récapitulatif des sessions, visible ici.

De nombreux bloggeurs ont réalisés des retours sur l'événement. En voici une liste presque exhaustive, tout d'abord en français :

Mais également en anglais :

On retrouve également quelques photos de l'événement :

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.