Tout d’abord, les différentes annonces qui ont eu lieu durant la soirée hier :
- Alexandre Bertails nous présente rapidement son nouveau job au W3C ainsi que le fonctionnement de l’organisme avec un rapide retour sur ce qu’est le web et l’importance du consortium.
- Developpez.com est un JUG … qui n’envoie pas de représentant, ils font donc profiter de leur place à Jazoon’10 à un volontaire qui a été tiré au sort.
- Une boutade dans la semaine, deux offres d’emplois supplémentaires sur son site d’ « Offres d’emplois pour passionnés », et Nicolas Martignole se voit en « obligation » d’offrir le buffet. Merci à lui !
- L’ISEP prête la salle de 200 personnes gratuitement, Antonio les remercie et demande des volontaires afin de pouvoir leur rendre service en retour en proposant des cours à leurs étudiants.
Entrons dans le vif du sujet ! La première partie de soirée est orientée « Share » avec un retour d’expérience sur le passage d’un CVCS (Gestionnaire de sources centralisé) à un DVCS (Gestionnaire de sources distribué) suivi d’une présentation du DVCS qui monte : Git. La seconde partie de soirée nous fourni une présentation de Maven 3 et de Deploy It.
DVCS
La présentation du sujet a été faite par Sébastien Douche qui nous fait donc ici un retour d’expérience sur un ton décalé et des slides épurées … très agréable.
Arrivé il y a 2 ans dans son entreprise actuelle, il fait le constat de la (classique) sous utilisation de SVN et après analyse du problème, migre vers un DVCS. Son crédo : les tests automatisés et l’outil de versionning sont les 2 filets de sécurité indispensables à un développement logiciel.
Le problème :
Après avoir tenté une évangélisation des bonnes pratiques SVN, il constate tout de même une dégradation régulière de la qualité, impliquant une démotivation (il parle de souffrance) des développeurs allant se poser la question ultime : a-t-on fait le boulot qui nous a été demandé ?
Le problème ne se situe pas au niveau du travail effectué… mais vient plutôt du fait qu’il n’est pas bien partagé ! Notamment avec un phénomène de « micro-merge » : pour exagérer, les développeurs font des commit de chaque ligne de code modifiée pour éviter d’avoir un trop gros merge à faire par la suite ! Ce qui implique une version constamment instable sur le serveur d’intégration et des difficultés à savoir où l’on en est dans le projet.
Une première solution pointe le bout de son nez : si on faisait des branches SVN ? Hum … Attendez, je crois qu’on tente de nous expliquer comment éviter ça :-)
L’impact du DVCS :
En règle générale, les outils de versionning centralisés sont utilisés principalement pour faire du suivi d’historique … et non leur boulot. On souhaite donc : un environnement constamment stable afin de connaitre l’état du projet tout le temps !
Pour cela, on va isoler le travail des développeurs en repensant notre façon de travailler, via une analyse des besoins réels, 3 workflows sont identifiés :
- La méthode de l’organisation (donc la gestion du repository central), avec une façon de faire par organisation. En général, le workflow le plus connu puisque c’est celui qui est visé par SVN et consorts. L’idée ici, c’est que la méthode de l’organisation ne soit pas impactée par les deux workflows suivants. Le but à atteindre serait, par exemple, d’avoir un seul commit par fonctionnalité.
- Puis le workflow inter-personnel, nouveau donc, qui doit être mis en place justement pour éviter d’impacter le repository central : nouveau dépôt de développement, dépôt temporaire, échange de patchs (très utilisé dans le monde de l’open source), branche spécifique, … Il permet aux développeurs de travailler entre eux.
- Et finalement le workflow personnel, ici aussi à bien séparer des deux autres et chacun pourra travailler à sa façon.
L’important, donc, est que ces workflows soient déconnectés les uns des autres.
Une fois la mise en place effectuée, le constat est le suivant : le développeur est concentré sur SON travail et non sur celui du voisin par peur des impacts qu’il pourrait-y avoir sur le sien. Avec cette fois un commit par fonctionnalité sur le repository central, plus de souplesse avec notamment la possibilité de faire de la revue de code et/ou une démonstration pour une et une seule fonctionnalité !
Il est à noter que ces nouveaux outils sont orientés contenu et non changement. Je pense que tout le monde s’accorde pour dire que SVN ne sais pas gérer le renommage de fichiers par exemple ! On voit donc disparaitre les dossiers ‘.svn’ et l’on gagne énormément en place et en vitesse.
En bonus, des repository sont accessibles en ligne. Un outil de binding permet une transition douce en intercalant le DVCS entre le développeur et son SVN.
Conclusion
Je crois que sa conclusion était plutôt claire :
Libérez-vous : utilisez un DVCS
Git, la gestion de configuration qui vous veut du bien
Présentée par David Gageot, très proche et complémentaire de la session précédente. On part sur le même ton puisque qu’il commence par reprendre la conclusion de Sébastien 
Il insiste notamment sur le fait qu’un outil est fait pour ouvrir des possibilités … et non en fermer !
Git est donc un DVCS, le plus connu avec Mercurial. Pour faire court :
- Pas besoin de serveur !
- Chaque utilisateur a tout l’historique en détail
- Fonctionne en déconnecté
Mais pour l’utiliser à pleine puissance, il faut oublier comment SVN fonctionne !!!
En général, on ne fait pas de merge avec ce type d’outils.
Démo
Il nous fait ensuite une démo rapide d’une fonctionnalité majeure : bisect.
L’idée est de retrouver quel commit a cassé le build. Avez-vous déjà tenté le coup avec SVN ?
L’idée ici est de donner à cette commande un commit qui ne cassait pas le build ou les tests, celui qui ne fonctionne plus et le test à effectuer (manuel ou automatique). Et par dichotomie, elle va retrouver la version qui a cassé le build.
On peut pousser plus loin :de ce fait, il est possible de jouer un nouveau cas de test (qui devrait passer mais ne passe finalement pas), sur des anciens commit !
Et si on jetait les serveurs d’intégration continue ?
En effet, il est tout a fait envisageable (d’autant plus que c’est ce que David a mis en place dans son entreprise) d’écrire un script qui fait un « private build » avant de faire le commit réel seulement si ce build réussi. Cela est rendu possible par les performances de Git et il est tout à fait possible de travailler en même temps que ce script fonctionne.
Conclusion
Il y a énormément de nouveauté dans Git qu’il n’est pas possible de présenter dans le cadre du Paris JUG. Il nous conseille donc le livre Pro Git.
Il répète Sébastien en confirmant qu’il est possible de passer à Git en une commande : Git va importer le contenu du SVN et agir comme passerelle bidirectionnelle.
Maven 3
2 commiters Maven, Nicolas De Loof et Arnaud Héritier nous présentent Maven 3. La présentation est dynamique mais je reste sur ma faim quand aux nouveautés du produit : elles sont quasiment inexistantes … pour l’instant.
Le contenu :
En effet, le gros sujet, de cette version était une remise à plat des bases avec une refonte du produit (Passage à Java 5) et l’écriture d’une batterie de tests à priori impressionnante. L’écriture de plugins en revanche devrait être simplifiée grâce aux nouvelles API.
Un build plan est mis en place : les plugins pourront savoir ce qu’il s’est passé auparavant dans le buid et donc travailler en conséquence. Notamment le plugin Eclipse pourra laisser Eclipse faire sont boulot (compilation incrémentale) et en tirer bénéfice.
Les pom pourront être écrits dans d’autres langages (groovy, python, …) et les profils ont été revus.
Le résultat :
Une version 100% compatible avec les pom existants via un simple changement de MAVEN_HOME. Les impacts possibles se situent au niveau du plugin site qui n’est pas ou pas bien supporté et éventuellement dans les descripteurs de projet qui sont plus contrôlés.
Le gain que l’on peut avoir aujourd’hui en migrant se situe principalement sur les performances et de meilleurs logs.
Le futur :
- Ajout de la possibilité d’injecter de la configuration dans le pom (mix-in) afin de dépasser les limitations de l’héritage simple.
- Exclusions globales rendues possibles.
- Build parallèle sur multi-coeur
- Ajout d’une console (Maven Shell)
Conclusion :
Il y a peu de risques de régressions, et le passage de Maven 2 à Maven 3 devrait faire gagner du temps. Pour les développeurs Maven et/ou de plugins, le coût d’entrée est maintenant beaucoup plus bas étant donné la refonte. De ce fait la communauté revit et le produit se professionnalise.
Deploy It
La soirée se finit avec la présentation d’un outil d’automatisation des déploiements Java, réalisé par la société XebiaLabs. La présentation de l’outil est faite par Guillaume Bodet et Benoit Maussaud.
Le produit ne se contente pas d’une simple copie de WAR/EAR mais gère aussi :
- Binaire
- Ressources (datasource, securité, …)
- Fichiers de conf
- Base de données
- Réécriture apache
- Fichiers statiques (HTML, images, …)
- Batchs
- …
Je dois avouer que je me suis arrêté là dans la présentation, l’outil n’étant pas open source et ayant l’air plutôt complexe pour une problématique ne me concernant pas …
http://mercurial.selenic.com/
) attaque Google pour violation de brevet sur cette JVM.
Derniers commentaires