Retour sur le barcamp 2

Voici le retour sur la session concernant l’intégration continue et les outils de build du barcamp deuxième edition organisé par OCTO mardi dernier. Cette session s’est déroulée en présence d’une dizaine de personnes ayant chacune un retour d’expérience a faire partager.

Partie sur les outils de build

Le premier sujet abordé a été « Maven au delà du poste de développement ». Un sujet délicat, qui revient souvent dans les équipes que je rencontre. Selon mon expérience, l'outil Maven doit être limité aux phases de compilation, de tests et de packaging. Il faut laisser le déploiement de ces artifacts aux scripts shell ou ksh souvent existant, et maintenus par une équipe spécifique dans les structures d’entreprises de taille importante. Maven doit donc être utilisé pour réaliser des fonctions de build uniquement. En revanche, il est important d’insister sur le fait que dans le cadre de développement JEE, l’archive Web produite doit être indépendante de l’environnement final. C’est au conteneur Web (ex :Tomcat) de contenir la configuration de l’environnement nécessaire comme par exemple la configuration de l’environnement de dev, de recette, de pre-prod et de prod. Et attention a l’utilisation abusive des profils Maven. Ces profils sont très utiles pour choisir le serveur de déploiement dans le cas d'une gestion de configuration des environnements des tests mais ne doit en aucun cas être utilisés pour réaliser un artifact de developement ou de recette en fonction de l’activation d’un profil de dev ou de recette (ex : -Penv=dev ou –Penv=rec). Utiliser cette technique pour ce cas d'utilisation est un abus de la puissance de Maven. En conclusion, il faut produire des artifacts génériques et classifier vos artifact par nature si besoin (sources, tests, …) et non pas par environnement.

L’autre point abordé a été l’utilisation de Maven dans les IDE. Pour Eclipse, l’utilisation de Maven est facilitée par l’intégration du plugin maven-eclipse-plugin (mvn eclipse:eclipse) ou par les plugins Eclipse Q4E ou m2eclipse. Un retour sur les lenteurs du plugin m2eclipse a été notifié. Cela renforce mon choix d’utiliser maven de manière complètement indépendante de l’utilisation des taches quotidiennes de développement au sein de l’IDE. A noter que rien ne vaut la gestion de Maven dans IDEA IntelliJ, qui depuis la version 7 permet une lecture directe des descripteurs Maven (pom.xml). Il a été également abordé la bonne intégration de Maven dans NetBeans. Mais la question que je me pose après coup : pourquoi utiliser NetBeans aujourd’hui pour les développements non Swing?

Il a été discuté ensuite de l’automatisation des tests d’IHM avec Selenium et de son intégration avec Maven. Selenium est un outil très populaire, qui s’impose aujourd’hui en entreprise. On peut affirmer que le concurrent Watij est en perte de vitesse. A noter que pour ceux qui exposent leur logique métier via REST, il est possible d’utiliser Selenium pour tester les flux http de retour dans le cas de XML. Concernant son intégration avec Maven, j’ai insisté qu’il s’agit de tests d’intégration et que Maven ne supporte pas très bien les tests d’intégration. La technique qu’il faut utiliser est de produire un module dédié aux tests d’intégration sur lequel la phase Maven des tests unitaires est skipée et que l'exécution des tests du projet est lié sur la phase Maven « integration-test ». Ensuite, il suffit simplement d’utiliser le plugin selenium server et le tour est joué.

Au delà de tout cela, j’ai essayé de montrer la lourdeur de Maven lorsqu’on sort des conventions en voulant scripter des produits non JEE comne des plugins RCP. Les conventions de Maven et le total manque de flexibilité me permettent d’affirmer qu’il est nécessaire de ne pas choisir Maven systématiquement comme builder pour vos applications Java. Dans ce cadre, il est plus intéressant de rester sur des scripts ANT ou de passer sur des scripts Gant ou Gradle. Gant est un langage de build au-dessus de Ant avec la syntaxe du langage Groovy. Couplé au gestionnaire de dépendances Ivy, il en fait un choix de premier ordre pour donner de la flexibilité à vos scripts de build. En revanche, si vous travaillez sur des projets plus conventionnés, ne pas hésiter a jeter un coup d’œil à Gradle qui est un outil de build comme Gant pour le langage de script en Groovy, mais avec en plus les conventions de Maven et un cycle de vie. Voici sur ce post, un exemple de gestion multi-projet avec Gradle.

D’autres outils on été cités en fin de session comme Raven, il s’agit d’un maven en Ruby. Le projet est en fin de vie. Desolé pour les fans de Ruby, mais Ruby n’a rien a envier comparé à Groovy ou Python (ou son petit frère pour Java : Jython).

A noter que pour ceux qui construisent des projets C/C++, l’outil très utilisé en entreprise est le builder Scons écrit en Python.

Les outils d’intégration continue

La deuxième partie de cette session a concernée plus spécifiquement les serveurs d’intégration continue. Sujet très ancien, tout le monde connaît le poste de Martin Fowler sur le sujet qui date de 2006, il s’agit néanmoins d’un sujet qui explose chez tous les clients ou j’interviens. En terme de choix d’outil, toutes les personnes dans la salle sont unaniment sur le fait que Hudson est le serveur d’intégration continue incontournable en ce moment. Cette affirmation est confirmée par le sondage fait à Devoxx comme signalé sur le blog du créateur de Hudosn: Kohsuke Kawaguchi.

Nous avons également discuté des livraisons très rapprochées de Hudson. Hudson produit une release très régulièrement de son core.
Comme j’en parle ici, il est important au niveau des ses clients de qualifier une version avant d’updater sa version de Hudson et il est bien sûr impossible d’utiliser systématiquement la dernière release de Hudson en production.

Il a été également abordé la gestion dans Hudson d’un projet multi-branche. L’autre approche des mécanismes multi-branche est l’utilisation d’une seule branche au niveau de son SCM et la pratique des pre-tested commit. Aujourd’hui, il s’agit de la seule fonctionnalité manquante au niveau Hudson, et qui pourrait nous faire basculer vers son principal challenger aujourd’hui TeamCty. Mais que les utilisateurs de Hudson se rassurent, cette fonctionnalité est en cours de développement et sera tout prochainement disponible.

Au-delà de ceci, quelques retours de plugins Hudson comme le CI game hudson plugin qui en conclusion ne sert à rien.

Le format court et la richesse du contenu ne m’a pas permit d’aborder de nombreux points qui me tenaient a cœur comme quelle personne ou équipe doit être en charge de faire évoluer le build continue? Et quelles sont les connaissances requises et nécessaires pour laisser une équipe être autonome avec une intégration continue?
Une prochaine fois sûrement.

En conclusion, une très bonne soirée dans des locaux impeccables, et le tout sur les Champs-Elysées.