JUG Summer Camp 2010 : La forge logicielle (4/5)

En cette veille de week-end, voici l’avant-dernier épisode de mes aventures au JUG Summer Camp 2010.

La forge logicielle

Le titre original de cette conférence était “Maven 3, au coeur de la forge logicielle”. J’avoue que ce titre me semble être finalement mal choisit étant donné qu’à peine 5 % du temps a été consacré à Maven :). Pas bien grave, la conférence était quand même sympa et m’a permis de conforter pas mal de mes choix !

Cette conférence était animée par Nicolas de Loof qui est Architecte Agile chez Orange IT&Labs, impliqué sur le projet Maven depuis fin 2007 et a publié un livre sur Apache Maven.

Travailler à plusieurs

Nicolas recommande d’utiliser des outils intégrés : une navigation facile entre les spécifications, le code source, et les bugs permet de gagner un temps considérable ! L’équipe a autre chose à faire que de naviguer dans l’historique du VCS (Version Control System) pour retrouver qui a corrigé un bug et dans quelle version.

Nicolas recommande la suite d’outil de Altassian : Atlassian Jira Studio. Je ne peux que confirmer : pour avoir toucher aux outils JIRA+Fisheye+Confluence+Crucible, c’est très bien intégré et c’est diablement efficace. Pour la gestion du planning, toujours chez Altassian, Greenhoper semble bien adapté aux équipes agiles.

Nicolas rappelle que les solutions les plus simples sont parfois les plus efficaces : un tableau blanc avec des post-it (plusieurs couleurs !) permet parfois d’être aussi efficace. Les post-it ont l’énorme avantage d’être toujours visibles : pas de navigateur à lancer, pas d’URL à se souvenir…

Pour la gestion des sources, Subversion est devenu un grand classique mais il reste plusieurs problèmes avec cet outil. Nicolas en cite deux :

1. problématique de switch : comment passer d’une branche à une autre en gardant ses modifications locales (même quand on a fait un refactoring…)
2. problématique de merge : quiconque à déjà essayer de maintenir plusieurs (> 2) branches dans SVN, voit que quoi Nicolas parle 🙂

La solution viendra peut-être des outils de type DCVS (Distributed Control Version System) : Git, Mercurial ou Bazaar. De part leur conception, ils permettent de régler les problèmes cités plus haut. Plusieurs personnes de l’assistance sont convaincues (notamment Emmanuel Bernard de JBoss). Ces outils ne bouleversent pas obligatoirement les méthodes de travail d’une équipe (i.e.. on peut conserver un référentiel centralisé). L’intégration avec les IDE est encore un peu “jeune” mais permet déjà de travailler en consultation…

Build

Nicolas, indique que les objectifs principaux des outils de build doivent être d’obtenir :

• un build reproductible entre les différents environnement (poste de dev, intégration, etc…)
• obtenir une standardisation sur l’ensemble des projets
• permettre de lancer le build sans lire 50 pages de manuel

Comme Nicolas, j’ai croisé beaucoup de projet avec des binaires directement dans leur gestionnaire de version : à chaque fois, c’est une véritable bataille pour en extraire des informations utiles… d’où vient ce JAR ? par quel module de l’application est-il utilisé ? a-t-il un numéro de version ? a-t-il subi des modifications par rapport à la version “officielle” ? Ca ressemble parfois à ce que peuvent subir les développeurs MS Windows avec le DLL Hell. C’est à cause de ces nombreux problèmes que Maven oblige à déclarer explicitement la version de chaque dépendance des projets.

Que ce soit pour gérer ses propres livrables ou bien pour faire de la traçabilité sur les dépendances utilisées, il faut utiliser un gestionnaire d’artefacts. Nicolas recommande Nexus (développé par l’équipe de Sonatype). Pour ma part, j’ai de bonnes expériences avec Artifactory (réalisé par JFrog). Il faudrait peut-être que je teste la version Nexus Pro pour me faire une idée des deux fonctions mises en avant par Nicolas :

• Staging Suite : permet de faire l’assemblage d’une application dans un espace temporaire (et privé) avant de la publier dans le repository principal ou de faire un rollback
• Proxy P2 : permet d’obtenir un repository Maven à partir d’un repository Eclipse P2 (je ne suis pas certain de bien comprendre l’intérêt cependant)

Autre question essentielle : comment tester mon livrable et que dois-je tester en priorité ?

Catchwords : “Quelque chose qui n’est pas testé ne devrait pas être livré”… théoriquement.

Deux approches existent :

• Le développement piloté par les tests (TDD) : je développe mes tests, et ensuite de façon itérative je développe le code qui va permettre à l’ensemble de mes tests de fonctionner
• Le développement dirigé par le comportement (BDD) : à partir d’un langage dédié dans lequel sont écrites les “Users Stories” on peut créer/générer des test automatisés

Pour les tests d’acceptation (tests fonctionnels), Nicolas recommande prise en main de Fitness par l’équipe MOA. L’objectif est d’obtenir des tests plutôt que des quantités astronomiques de spécifications détaillées. Je ne connaissais pas cet outil, je vais de ce pas en parler avec ma MOA 🙂

Intégration et déploiement continus

Pour cette problématique, le premier élément à dénicher est un outil capable de construire automatiquement votre application à partir des instructions fournis par Maven. A ce petit jeu, Hudson est l’outil favori de Nicolas (et le mien aussi). Il est ultra simple à utiliser, supporte nativement Maven2 (Maven3 très bientôt). Il permet de monter simplement plusieurs clusters (en mode master/slave) lorsque le build (et surtout les tests) sont trop lourds pour un seul serveur. Quelques plugins utiles à noter :

• radiator : permet un feedback visuel sur l’ensemble des projets. On peut imaginer laisser un 22″ avec cette vue à l’entrée de la salle de pause…
• chuck noris : affiche une image de Chuck Noris en fonction de l’état du build

Il est essentiel d’intégrer la mécanique de tests de l’application dans l’outillage de compilation : il faut tester le plus souvent possible sans que cela demande d’intervention humaine. Le test doit être fait à plusieurs niveaux :

• Tests d’IHM via Selenium Grid : attention car très consommateur en CPU
• Tests de performance : c’est beaucoup plus drôle de les faire 5 jours avant la livraison… mais il faut aimer les risques

Pour le déploiement de l’application vers un serveur JEE, le classique Cargo fonctionne assez bien (même si le projet n’est plus vraiment actif). Nicolas propose d’utiliser le projet Arquillian (de JBoss) : à suivre.

Pour l’assurance qualité, l’idéal est de mettre en place un outil qui permet d’obtenir une vision claire de l’état du projet à un instant T mais aussi le le comparer avec le passé. Nicolas présente évidemment Sonar pour remplir ce rôle : c’est évident qu’il n’y a pas mieux pour le moment. Nicolas explique qu’il n’est pas toujours évident de bien faire comprendre chacune de règles utilisée par Sonar (+600). Pour cela, il conseille de prendre le TOP10 des violations et d’échanger avec les développeurs : cela permet une montée en compétence.

Un autre sujet évoqué par Nicolas – qui m’intéresse tout particulièrement – c’est le déploiement automatisé en production. Le principe est simple : pourquoi ne pas appliquer les méthodes d’intégration continue pour livrer sur la production ? Pour cela Nicolas, propose deux outils :

• dbmaintain : pour gérer l’évolution du schéma de la base de données
• anthillpro : pour effectuer les déploiement automatisés à distance

Nicolas n’a pas oublié la documentation ! Il faut absolument qu’elle soit versionnée avec le code source dans le SCM. MS Office dispose d’outils pour effectuer des comparaisons de documents ou des merges. Sinon XWiki, accompagné des plugins XEclipse (pour le développeur) et/ou XOffice (pour le chef de projet) permet d’obtenir un bon résultat.

Enfin, pour l’outillage du poste de développement, Nicolas a testé plusieurs approches :

• un fichier ZIP avec un script permettant son installation automatique : attention, à la charge de MCO et de mise à jour des postes existants
• une machine virtuelle : pour la mise à jour, rien de plus simple. Permet à l’ensemble de l’équipe d’être au même niveau
• déploiement one-click : une solution semble proposée par Sonatype avec son outil OnBoard

Maven 3, la petite histoire

C’est finalement durant la séance de questions/réponses que Nicolas a commencé à parler de Maven 3 🙂

Il a essayé d’expliquer pourquoi le projet “Maven3” était en retard et pourquoi la tension est assez forte entre la communauté Apache Maven d’un côté et Sonatype de l’autre.

L’objectif pour Maven 3 a toujours été d’externaliser son API d’accès au repositories et de résolution des dépendances, afin de permettre de se connecter à d’autres repositories (P2, OBR, etc…). Le premier essai d’externalisation de cette API, “Mercury”, a été développé par l’équipe de SAT4J (aka “ils savent ce qu’ils font”). Malheureusement cette implémentation n’a jamais vraiment fonctionné et a été mise à la poubelle par l’équipe de Sonatype. Sonatype a donc développé sa propre API “Aether” sur leur propre forge et surtout sans demander l’avis du reste de la communauté Apache Maven. Finalement, un message de Sonatype sur la liste de discussion maven-dev a annoncé que “Maven 3 utiliserait Aether”… après pas mal de débats, c’est plutôt les avantages techniques de cette API qui ont permis de calmer le jeu.

La version finale de Maven 3 devrait donc finalement voir le jour. Un cycle de RC se poursuivra jusqu’à la fin Octobre.

Resources

• [Support de la présentation Forge Logicielle](http://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxqdWdzdW1tZXJjYW1wfGd4OjJmNzYwMzNhNzkyNWRmNjU "http://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxqdWdzdW1tZXJjYW1wfGd4OjJmNzYwMzNhNzkyNWRmNjU")

Mon dernier billet arrive bientôt : Le MDA en 2010 : une vision pragmatique. Bon week-end à tous !