Compte rendu du Paris JUG du 11 Mai

Mardi dernier, Meriem, Sébastien, Christian et moi nous sommes rendu à la soirée "Share, Build & Deploy" au Paris JUG. Voici un rapide compte rendu des différentes sessions:

Retour d'expérience de Sébastien Douche sur sa mise en place des DVCS.

Sébastien est directeur technique chez un éditeur et nous a fait part des problèmes rencontrés lors des développements, en mode agile, de leur dernier produit. Au bout de quelques itérations, le  logiciel était devenu instable et n'était plus montrable en démo. Une des causes remontée par notre speaker semblait être la sur-utilisation du commit par les développeurs sur leur repository SVN. En effet, ceux-ci effectuaient un commit à chaque modification d'un fichier, aussi bien lors de l'ajout d'un élément dans une feuille de style que pour la création du nouvelle classe. La solution proposée par Sébastien a été de remplacer SVN par un DVCS. Celui-ci, en plus de laisser aux développeurs leur propres rythmes de commit, a permis de mettre en place un nouveau workflow de développement "Kanbanisé". La conclusion de sa présentation a donc été "Stop SVN, start DVCS".

J'ai trouvé cette présentation intéressante même si, avec les éléments fournis, je suis en désaccord avec les conclusions de Sébastien. En effet, ce qui transparaissait de son discours, c'est que le problème venait d'une mauvaise utilisation de SVN (trop de commit). Or, suite à la résolution de ses problèmes, il semble en avoir conclu que c'est ce changement d'outil qui a réglé ses problèmes. Personnellement, je pense plutôt que c'est la mise en place de nouvelles pratiques, facilitées certainement par le DVCS, qui ont permis d'améliorer la qualité des itérations et d'avoir un produit stable. J'émettrai donc personnellement quelques réserves quant à la conclusion de sa présetnation, même si je ne pense que du bien des DVCS.

Présentation de GIT, par David Gageot

Dans la continuité de la présentation précédente, David nous a présenté GIT, un des 3 DVCS les plus répandus avec Bazaar et Mercurial. Il a vraiment mis l'accent sur les différences de fonctionnement avec SVN et ce qui en faisait un outil plus puissant. Nous avons notamment pu assister à la démonstration de "GIT Bisect", un des outils fourni avec GIT, qui permet, par exemple, de rechercher dans quelle version d'un projet le build est devenue KO.

Cette présentation m'a conforté dans le fait que les DVCS sont de réels outils de puissance. On regrettera cependant de ne pas avoir eu d'exemple d'intégration de GIT dans nos outils de tous les jours (explorateur, IDE, maven, hudson...)

Les nouveautés de Maven 3, par Arnaud Héritier et Nicolas De Loof

Changement de thème, Arnaud et Nicolas nous ont présenté ce à quoi il faudra s'attendre lorsque Maven 3.0 sera disponible. Tout d'abord, ils nous ont rassurés en annonçant que tous les projets configurés avec Maven 2 seront compatible avec Maven 3. A l'heure actuel, le seul problème persistant concerne le plugin "Site". Ensuite, ils ont rapidement brisé le suspense. Maven 3.0 ne contiendra pas quasiment pas d'ajout par rapport à  la dernière version de Maven 2. En effet, la première release ne sera que le prélude à des nouveautés auxquelles nous aurons accès au fur et à mesure des sorties suivantes. Toutefois, on peut noter que la 3.0 est maintenant implémenté en Java 5 et qu'un effort particulier a été fait sur les performances. En ce qui concerne ce qui suivra, on pourra s'attendre à ça, soit dans une release, soit sous forme de plug in :

• Le build plan : une description des actions effectués pendant un build, permettant aux différentes actions de savoir ce qui a été fait avant, et avec quel résultat, et ce qui sera fait après. C'est la seule nouveauté présente dans la version 3.0
• Le parallel build : il sera possible de lancer le build des différents modules d'un projet en parallèle sur les différents coeurs d'un processeur. Ce n'est pas pour l'instant un fonctionnement par Agent, comme peut le proposer Team City
• L'adéquation avec les normes OSGi.
• Le shell Maven

On notera l'effort fait pour assurer la compatibilité entre Maven 2 et Maven 3, qui est, on nous l'assure, supérieur à 99%. Personnellement, dès l'accès à la première release, je saute sur cette version 3 !

DeployIt, par Guillaume Bodet et  Benoit Moussaud

DeployIt est un outil développé par XebiaLabs permettant d'automatiser le déploiement d'application JEE. La présentation à laquelle nous avons assisté était centrée sur l'architecture du produit et ses possibilités. Celui-ci permet de s'interfacer avec la grande majorité des serveurs d'application existant, ainsi qu'à plusieurs EAI/ETL/ESB et base de données. De plus, il peut être piloté via sa propre interface Web, via Maven ou encore Hudson, entre autres. Il est important de noter que DeployIt possède nativement plusieurs mécanismes de rollback, en fonction du type d'application attaquée (serveur, BDD,...). Il est par exemple possible de lui demander de sauvegarder l'état de la BDD avant une installation, pour pouvoir faire un retour arrière s'il y a un problème. Nous avons eu aussi le droit à une démonstration mettant en avant le déploiement d'une application et de datasources sur un serveur Tomcat puis weblogic, dans le cadre de tests fonctionnels automatisés puis de performances.

Même si les démonstrations ne mettaient pas forcément les capacités de l'outil en valeur, je lui trouve du potentiel. En plus de permettre d'avoir une solution unique de déploiement au sein d'une DSI, les fonctionnalités offertes dans le cadre d'une intégration continue me paraissent très intéressante. En effet, là où un des goulots d'étranglement de nos projets agiles est la difficulté à livrer nos applications régulièrement sur un environnement "de production", la possibilité d'automatiser cette phase devrait permettre de faire plus régulièrement des tests en conditions de production, voir même, de les faire en continue !

Deux choses à noter toutefois :

• DeployIt communique avec les applications "attaquées" via les protocoles SSH, SCP et SFTP. Pour un serveur dont l'OS est Windows, il sera donc nécessaire d'installer un serveur SSH au préalable.
• DeployIt est disponible en deux versions : une  gratuite et une payante. Cette dernière propose en plus des mécanismes de sécurisation des accès.