Accueil > J'y étais ! > Compte-rendu du Paris JUG : soirée Build, Share & Deploy

Compte-rendu du Paris JUG : soirée Build, Share & Deploy

Aujourd’hui, nous tentons une expérience : écrire un article à plusieurs. Mais plutôt que de s’abriter derrière un “nous” anonyme et sécurisant, nous (sic !) avons décidé de continuer à employer la première personne, en précisant qui est le locuteur lorsque c’était nécessaire. A vous de nous dire si vous appréciez le format ;-) !

Une fois n’est pas coutume, ce deuxième mardi du mois a été l’occasion pour les Javaïstes parisiens d’assister au Paris JUG, consacré cette fois aux processus de build, share et deployment. Pas de chance, la salle était déjà bien pleine quand je (Bastien) suis arrivé… vite, une chaise tout devant !

De mon côté (Pierre-Yves), ayant posé ma tente devant la salle la veille au soir, j’ai eu accès aux premiers rangs. Allez, je vous livre un petit secret : pour avoir un placement correct au Paris Jug, il faut arriver à 19h ;-) (ou être une JDuchess :-P). Je (Pierre-Yves) vais donc vous parler des trois premières présentations, et je (Bastien) continuerai avec les deux dernières.

Les secrets de fabrication du W3C

Par Alexandre Bertails

Qui connaît réellement le W3C ? En dehors des outils de validation et des spécifications HTML 5, peu d’entre nous en savent plus sur cet acteur historique du Web. Alexandre Bertails nous en dit plus, dans un temps imparti relativement court.

Saviez-vous que le site web du W3C vient d’être refait à neuf, après un an et demi de travail ? Ce n’est pas juste une CSS, le contenu et l’arborescence ont été revus, sans cependant casser aucun lien. Allez-y, visitez-le (bien plus joli qu’en 2008, 2002 et même 1996).

J’ai aussi découvert que le W3C est composé à 40% de français. Que les outils avec lesquels travaillaient les salariés n’étaient pas forcément orientés Web, mais que les choses ont bien évolué récemment.

On regrettera le flux permanent des retardataires (ça va, je (Bastien) le saurai pour la prochaine fois !), qui ont quelque peu perturbé notre attention à tous, sans toutefois départir Alexandre de ses moyens (et c’est tout à son honneur !).

DVCS

Par Sébastien Douche

Speaker hors pair, Sébastien Douche nous a donné envie de nous jeter à l’eau (pardon… facile celle-là) et de nous mettre immédiatement aux DVCS (Distributed Version Control System, système de gestion de versions distribué).

Auparavant, lorsqu’il intégrait un nouveau groupe de travail, Sébastien avait l’habitude d’y déployer sa boîte à outil habituelle : SVN, et Trac. Jusqu’au jour où il s’est retrouvé chef de projet sur un projet from scratch.

J’aime beaucoup la métaphore qu’il nous a donné : la maintenance d’une application, c’est du ski sur pistes, il y a des dizaines de développeurs qui sont passés avant toi et qui ont tracé la piste. Le développement à partir de zéro, c’est du ski hors piste, tu sais la direction que tu veux prendre, mais tu es en haut de la montagne, ya du brouillard, il faut se lancer, et tu n’as pas de repères immédiats.

Avec le temps, le projet, pourtant “agile”, a eu de plus en plus de mal à livrer dans les temps, et la qualité de travail s’est progressivement dégradée. Pourquoi ? Parce que les développeurs passaient leur temps à faire des micro-commit/micro-merge et à intégrer le travail des autres, au lieu de pouvoir se consacrer au développement des fonctionnalités.

C’est une sale habitude que nous donne SVN : merger le code est vécu comme une expérience difficile. On préfère donc commiter le plus vite possible pour que ce soient les autres développeurs qui aient à merger. Les micro-commit sont aussi bien moins difficiles à merger. Quand aux branches SVN, elles sont aussi faciles à créer que complexes à merger…

SVN ne sert plus au final qu’à faire de l’historisation, c’est un super “Annuler / Répéter”.

Les DVCS récents permettent à chaque développeur de travailler en local (fonctions d’historisation) et en isolation, et de pousser le code sur un repository central uniquement lorsque la fonctionnalité est terminée. Leur grande force est la flexibilité qu’ils introduisent, permettant à chacun de bosser comme il l’entend tout en respectant les règles d’organisation du groupe.

Il est aujourd’hui possible de passer à un DVCS en douceur, sur son poste de travail, en important un repository SVN qui peut rester le repository principal, mais en disposant des avantages d’un Git ou d’un Mercurial en local.

Sébastien en a aussi profité pour nous présenter la manière dont travaille son équipe : le repository central comporte uniquement du code “livrable” (au sens livraison de fin de Sprint). Chaque fois qu’une fonctionnalité a été codée par un développeur, une revue de code est réalisée par un autre développeur, une démo est réalisée, et si tout va bien alors seulement les modifications sont poussées sur le repository central.

Sa conclusion : si vous ne devez apprendre qu’une techno en 2010, ce n’est pas Scala, JEE 6, Maven 3apprenez à utiliser un DVCS !

Git

Par David Gageot

Plutôt que de faire de sa présentation un énième tutoriel sur Git et tous les concepts associés, David Gageot a préféré nous montrer la puissance de Git en quelques exemple pratiques.

Tout d’abord, git bisect. Cette fonctionnalité permet d’automatiser la recherche du commit qui a créé une régression. Le fonctionnement est simple : on fournit à Git un script permettant de déterminer, pour une version donnée, si le bug est présent ou non. git bisect va ensuite réaliser une recherche dichotomique entre deux numéros de versions, et identifier très rapidement le commit coupable.

Cette fonctionnalité n’a pas grand chose à voir avec le fait que Git soit un DVCS (distribué), mais reste un argument de poids pour adopter cet outil. C’est aussi possible grâce à la rapidité avec laquelle un Git ou un Mercurial peuvent réaliser un checkout ou changer de version sur une copie locale.

David nous a ensuite montré un script qu’il a réalisé, qui permet de conditionner automatiquement le push vers le repository au fait que le build et les tests passent. Il peut donc tranquillement bosser et commiter pendant qu’en tâche de fond le build et les tests sont exécutés, et ainsi se passer d’un Hudson.

La présentation s’est terminée par des démonstration sur l’évolution de dépôts Git à l’aide de Gource, qui permet de représenter dans le temps les modifications effectuées sur un dépôt de sources, et le travail de chacun.

Le Gource du projet Linux

En conclusion, quelques conseils :

  • testez Git le plus vite possible,
  • n’essayez pas de faire du SVN avec Git, il faut oublier comment SVN fonctionne, désapprendre les mauvais réflexes,
  • un bon moyen pour démarrer, c’est de jouer avec github,
  • n’hésitez pas à utiliser Git dans le cadre de vos projets, au moins en local, il vous apportera une forte plus value même si votre équipe continue d’utiliser SVN.

Pause Buffet

Le buffet était gracieusement offert par Nicolas Martignole, suite à un défi lancé sur Twitter. Il en a profité pour faire de la pub pour l’eXpress Board, un job board pour les passionés. J’ai (Pierre-Yves) aussi pu croiser Emmanuel Bernard, apprenant ainsi que si l’équipe Hibernate n’utilise pas de DVCS pour le moment, ils songent à y passer, notamment pour faciliter l’intégration de contributions externes.

Build it with Maven 3!

Par Nicolas de Loof & Arnaud Héritier

Invités surprise, Fred et Jamy nous ont montré que Maven, c’est pas sorcier ! Certains se souviennent encore des migrations longues et périlleuses des Makefile vers Ant, puis vers Maven 1 et Maven 2. Cette fois, les développeurs du célèbre gestionnaire de build ont voulu éviter cela : la compatibilité de Maven 3 avec des projets en version 2 est en théorie de 99.99% (hormis maven site qui n’est pas encore au point).

Première rencontre avec Maven 3

Les mots-clé de la première release stable seront donc les suivants :

  • compatibilité : en prenant n’importe quel projet Maven 2, sans aucune modification on pourra le builder avec Maven 3,
  • modularité/extensibilité : le socle de l’application a été entièrement repensé (en évitant les problèmes de rigidité et de complexité de la version 2). Au menu, utilisation de Java 5, apparition d’APIs simples et intuitives, de la doc… Bref, de quoi faire des plugins sans se prendre la tête,
  • Mercury : ce système voué à remplacer le mécanisme d’artifacts… a finalement été abandonné :D.

Maven 3 introduit la notion de build plan, qui permet de savoir à l’avance toutes les actions qui vont être effectuées dans un build (une sorte de contexte d’exécution). Ainsi, un plugin sera au courant de ce que feront les autres, donnant la possibilité d’avoir des builds intelligents (où les tests ne seront pas lancés deux fois par deux plugins différents par exemple).

Au niveau des descripteurs de build, la structure des pom.xml a été améliorée et Maven 3 devient polyglotte. On peut à présent écrire des descripteurs en groovy ou en python par exemple. Les exclusions globales de dépendances sont maintenant possibles (on va enfin pouvoir se débarrasser de cette *$#~ de dépendance sur un logger qui plante toujours… :-P).

Toujours dans les descripteurs, la notion de mixins est apparue :

Essentially it will be a POM consisting of plugins and configurations that can be externally parameterized. These mixins will be deployed to a repository and be referenced with a standard coordinate. Basically it will be an intelligent import with validation which will allow composition in your POMs.

On va pouvoir décomposer notre POM en différents morceaux, un peu à la manière des web-fragments.

Les builds parallèles vont bientôt faire leur apparition, pour ne pas que vos 7 autres cores s’ennuient (edit: Mathieu nous signale en commentaire que les builds parallèles sont déjà disponibles depuis la version 3.0-beta-1). Cette fonctionnalité sera très intéressante sur les serveurs d’intégration continue utilisant un modèle maitre/esclave (Hudson, pour ne citer que lui). Techniquement, le processus de build sera découpé en différentes phases qui se rejoindront en des points de synchronisation.

Mais au final, qu’apporte Maven 3 par rapport à Maven 2 à l’heure actuelle ? Rien, enfin presque :

  • un shell (avec des jolies couleurs !) permet de faciliter les builds (notamment sous Windows),
  • un gain de rapidité lors des builds.

Comme la migration de M2 vers M3 est très simple et rapide, nos deux speakers encouragent vivement les développeurs à tester Maven 3 chez eux, ne serait-ce que pour les gains en terme de rapidité de build. A vos pom, donc !

Deploy it with… DeployIt!

Par Guillaume Bodet & Benoit Moussaud

Guillaume et Benoit nous ont présenté les fondamentaux du bébé développé par XebiaLabs, DeployIt. Cet outil part du constat qu’un déploiement ne consiste pas en une simple copie d’EAR/WAR. Il y a généralement d’autres éléments à configurer (DataSources, JMS), des scripts SQL à lancer, des batches à mettre en place, etc.

DeployIt permet de gérer toutes ces étapes de manière intelligente et de faciliter l’installation d’une application. Il est repose sur trois briques principales :

  • le cœur,
  • des interfaces (Flex, console, Maven, Eclipse, dashboards…),
  • des plugins permettant le support de JBoss, Apache, .NET etc.

La préparation d’une installation se fait en deux étapes. Dans un premier temps, on configure le Configuration Item Repository (CIR), qui est un référentiel d’informations sur les différents environnements de déploiement (test, performances, etc.). Ensuite, l’ensemble des opérations à effectuer est décrite dans des runbooks : déploiement d’un EAR, configuration d’une DataSource, installation d’un script SQL…

A partir de ces deux sources d’information, l’Intelligent Runbook Resolution Engine va se charger d’interroger les différents runbooks pour constituer un scénario de déploiement, en se basant sur les caractéristiques de l’environnement décrites dans le CIR.

Un des aspects intéressants dans DeployIt est sa faible intrusion :

  • Il est agent-less, et va utiliser les moyens existants tels que ssh, sftp, scp.
  • Il utilise les interfaces natives lorsqu’elles sont disponibles (wsadmin, JDBC…).
  • Un plugin Maven permet de lancer les déploiements au sein d’un processus de build (au sens Maven) déjà existant dans le projet.

Seul bémol : DeployIt est un outil commercial, il existe une version gratuite mais qui n’intègre aucune notion de sécurité… XebiaLabs a ainsi la volonté de permettre aux gens de tester ce produit chez eux, tout en empêchant la possibilité de l’utiliser pour faire de vrais déploiements en production (sauf si vous êtes kamikaze).

Cependant, XebiaLabs songe à relâcher son outil en Open-Source. La majorité absolue des personnes présentes dans la salle a d’ailleurs voté positivement pour une telle action, en réponse à un sondage improvisé d’Antonio :D.

Conclusion

Ce Paris JUG fût riche en enseignements et en conférences de qualité. D’autres compte rendus ont été publiés sur le web : sur le blog du Touilleur Express, et sur le blog des JDuchess.

Le prochain Paris JUG aura lieu le 8 juin, avec une invitée à l’honneur : Holly Cummins.

Share
  1. 16/05/2010 à 12:29 | #1

    Bonjour,

    Bon résumé mais je reviens sur les places réservées au JDuchess. On ne le réserve uniquement à celles qui ont participé à l’AvantJUG. L’AvantJUG débutant à 18h30 et finissant juste avant le début du ParisJUG, on nous a permis de réserver des places car nous débutons la soirée bien avant. Sinon elles se retrouvent derrière arrivées à 19h30. Ce n’est pas un privilège réservé au JDuchess mais qu’une réservation pour celles qui démarrent la soirée bien avant ;).

    Ellène

  2. 18/05/2010 à 08:45 | #2

    Bonjour Ellène,

    Tu as tout à fait raison de le souligner :-) . Il s’agissait plus d’une boutade que d’un reproche, je suis tout à fait favorable à cette initiative. Et j’ai bien l’impression que les JDuchess ont eu un impact sur la population assistant au ParisJUG, il semble y avoir plus de femmes ces derniers temps.

  3. Mathieu Boniface
    18/05/2010 à 16:28 | #3

    Salut,

    Très bon article, qui à mon avis résume bien la soirée :-)

    Juste une chose : tu dis que la parallélisation des builds maven sera bientôt disponible, mais il semble que cette fonctionnalité soit déjà intégré à la beta1 et donc testable.
    Les notes de versions :
    http://maven.apache.org/docs/3.0-beta-1/release-notes.html
    Le ticket en question :
    http://jira.codehaus.org/browse/MNG-3004

    La commande pour tester :
    mvn -T nbThread clean package

    Bonne soirée,
    Mathieu Boniface

  4. 18/05/2010 à 17:17 | #4

    @Mathieu Boniface
    C’est exact… Hum, au temps pour moi…

    J’ai dû m’endormir un peu au moment où les speakers ont mentionné cette fonctionnalité.

    Edit: J’ai fait quelques tests rapides sur le projet multimodule sur lequel je travaille actuellement (mvn clean install -Dmaven.test.skip -o):

    • en Maven 2 : build en 6:17
    • en Maven 3 : build en 4:49
    • en Maven 3, 1 thread par core (-T 1C) : 4:04
    • en Maven 3, 1,5 thread par core (-T 1.5C) : 3:54

    On constate bien un gain de performance rien qu’en passant à Maven 3 sans aucune option particulière. J’ai seulement dû spécifier une version à certains artifacts qui n’en avaient pas (comportement légèrement différent par rapport à Maven 2).

  5. Mathieu Boniface
    19/05/2010 à 13:36 | #5

    @Bastien

    Tu pourrais aussi tenter d’activer le build en weave mode , sur un projet multi module, perso j’ai encore grappillé quelques secondes :

    mvn -T 1.5CW

  6. 19/05/2010 à 14:41 | #6

    @Mathieu Boniface
    Malheureusement ça ne fonctionne pas sur mon projet à cause du maven-ear-plugin (problème connu et mentionné sur la page du wiki). En revanche je viens de retenter un -T 1.5C et je suis passé à 3:02. Je ne sais pas trop si ça vient de l’enchainement des builds ou de la charge système qui est plus faible, mais les résultats varient pas mal (j’ai quand même gagné plus de 50% en rapidité !).

  7. 03/09/2015 à 05:51 | #7

    ヘッドフォン ヘッドホン 音楽 マイク おすすめ

  8. 03/09/2015 à 05:52 | #8

    ENVY 15.6 Laptop 6G

  9. 03/09/2015 à 05:52 | #9

    he Dance In The Ci

  1. 15/05/2010 à 14:28 | #1
  2. 08/08/2010 à 15:46 | #2
  3. 21/04/2016 à 19:18 | #3