Je suis allé Vendredi dernier à cette rencontre des utilisateurs de Jenkins (ex-Hudson). C’était l’occasion de rencontrer son créateur Kohsuke Kawaguchi et d’échanger autour de cette technologie. Je vais essayer de résumer les différentes présentations (la liste ici).
A ma gauche : Hudson ; à ma droite : Jenkins
Si mes comptes sont exacts nous avons 4 offres tirées de Hudson :
- Le Hudson d’origine, proposé à la fondation Eclipse
- Sonatype Pro for Hudson, branche commerciale basée sur Hudson
- Jenkins, le fork open-source des contributeurs initiaux
- Nectar de CloudBees, offre commerciale basée sur Jenkins
KK nous a présenté des chiffres démontrant que presque tous les contributeurs ont sauté dans le train Jenkins, alors que Hudson fait du sur-place. Alors, fini, Hudson ? J’espère que non. Certes, c’est gênant de devoir choisir entre deux produits aussi similaires. Mais Hudson@Oracle avait marqué des points dans mon cœur en mettant tout de suite la priorité sur le test et l’assurance qualité. En proposant de ralentir le rythme (hebdomadaire !) de releases. Car c’était mon principal (en fait, le seul) reproche à Hudson : son instabilité. A côté des nouvelles fonctions chaque livraison corrige les régressions du mois dernier et introduit son nouveau lot de régressions. Et si ce n’est pas le noyau, c’est dans les plugins (d’ou des initiatives comme le Plugin Compatibility Tester). Hudson peut donc aiguillonner Jenkins pour améliorer ses tests de non-régression. Mais il est prévu que Nectar (payant) soit justement cette version stable de Jenkins et de ces plugins principaux, avec -ohsurprise- une « QA Suite » complète. Jenkins donc pour sa partie open-source ne compte pas changer sa façon d’évoluer. J’attends donc un peu avant de tout miser sur Hudson ou sur Jenkins.
De l’importance d’un serveur build incassable
Dans une approche d’intégration continue, on se donne pour objectif lors du développement que le build soit toujours réussi. Tout changement provoquant une erreur va alerter les développeurs qui devront au plus tôt corriger leur code de façon à réussir le build. Le serveur de construction devient donc critique : s’il y a une régression dans le processus de construction, c’est potentiellement tous les builds qui vont passer au rouge ! Tous les utilisateurs présents Vendredi avaient soit des environnements séparés de qualification de Jenkins avec des projets de tests, soit un mécanisme pour pouvoir à tout moment revenir sur une mise-à-jour.
Henri l’intégrateur
La meilleure présentation du jour était sans conteste celle de Nicolas De Loof sur la gestion des branches GIT dans Jenkins. On découvrait Henri, chargé de réaliser manuellement l’intégration des branches de développement tous les Vendredi soir. A comparer avec l’anti-pattern Bob the Builder. En passant, et ça va faire marrer mes collègues d’Oxiane qui me taxent de GITosceptique, j’y ai découvert le rerere (« reuse recorded resolution ») qui pour le coup ressemble bien à une killer-feature.
Le support de la présentation est visible en ligne sur slideshare.
Et puis tout le reste
Des pistes d’amélioration des performances, des retours d’expérience sur petits et gros déploiements, l’intégration de Sonar, une présentation détaillée de l’offre CloudBees… Si vous avez déployé Hudson ou Jenkins dans votre entreprise, je vous recommande de venir faire un saut au prochain meeting.
server:anonymous@dev.eclipse.org/cvsroot/tools
