14 mai 2014

workflow plugin

Il y a parfois des coincidences.

Je publiais hier un billet expliquant pourquoi j'abandonne le build-flow plugin au bon soins de la communauté. Quelques heures plus tard Kohsuke annonçait sur la mailing list jenkins son plugin de workflow.

Nous nous serions concertés pour faire un lancement produit nous n'aurions pas fait mieux ! Mais non, c'est juste une coincidence :P

Ce nouveau plugin n'est pas à proprement parler la continuité du build-flow, même s'il en partage certains aspects. On retrouve un DSL qui décrit le workflow, mais ici l'unité de base n'est plus un job, mais un build-step, qu'on va exécuter sur un slave donné.

Le plugin est encore assez jeune mais permet déjà de définir des choses comme :

git.checkout( repo: “git@sm.com:app.git”, branch: “master”)
mvn “install”

je ne doute pas que KK ai prévu tout le nécessaire pour que chaque plugin jenkins puisse ajouter ses propres mot clé au DSL et l'enrichir...

En regardant les slides de présentation, je me demande si ce même DSL (réduit) ne pourrait pas être utilisé pour définir le build via un fichier à la travis, autrement dit un .jenkins stocké dans le SCM dans lequel vous définiriez les étapes de build et tout ce qui va bien pour votre project, ne déclarant dans jenkins que la partie SCM.

A réfléchir ...
4 commentaires

12 mai 2014

build flow future

Depuis trois ans je développe par petites touches le plugin Jenkins Build Flow, dont l'objectif est de fournir une solution d'orchestration de jobs jenkins, pour des process de build non triviaux et non nécessairement linéaires. L'idée est de reposer sur un DSL pour exprimer les relations entre jobs d'un même "pipeline", de manière concise et centralisée - et non dans chaque job via divers plugins spécialisés.

Ce plugin a été largement adopté (3500 installations) malgré tout je l'ai toujours considéré en phase expérimentale (d'où le numéro de version : 0.11). Ce succès a révélé un effet de bord majeur : de nombreux utilisateurs ont exploité la syntaxe Groovy du DSL pour venir "bidouiller" Jenkins à l'aide du build-flow. Initialement je pensais que le DSL devait être un pur langage indépendant des APIs de Jenkins, ce qui permettrait de faire évoluer le moteur interne. La facilité de créer un DSL en Groovy et l'absence totale d'expérience de ma part dans ce domaine a ouvert la boite de pandore. Aujourd'hui il est impensable de conserver la compatibilité et de revoir l'implémentation du moteur.

Or le build-flow a un défaut majeur : ce n'est pas une machine a état qui est modélisée puis exécutée, mais un thread java qui est lancé. Impossible de figer le flow (redémarrage de jenkins), de reprendre à flow à une étape précédente (reprise après erreur), etc. Bref, de prendre en charge des process de développement réellement complexes et de correspondre à ce que fait par exemple le plugin build-pipeline pour les cas "linéaires".

Bloqué par ce problème technique, je n'ai plus travaillé sur le plugin depuis un moment, et je manque de temps et d'idée pour m'y atteler. Accessoirement je n'utilise pas ce plugin moi même, le dogfood étant le meilleur moteur pour faire avancer un projet, celui-ci s'enlise.

J'ai donc décidé d'abandonner ce projet, qui est à la disposition de la communauté -  en termes d'écosystème Jenkins cela signifie que le premier qui prend le temps de le maintenir devient mainteneur officiel. J'ai lancé un appel à volontaire sur jenkins-dev. Si vous êtes tenté, je suis évidemment disposé à vous expliquer en bon Français le pourquoi du comment avant de vous passer la main, contactez-moi.

Ce plugin ayant ses fans, déçus par les tentatives de recentrage que j'ai appliqué après la version 0.10, je ne doute pas que quelqu'un prendra la main dessus, et le fera évoluer selon ses besoins. Il ne correspond plus à ma vision, mais peut tout à faire correspondre aux besoins de nombreux autres utilisateurs.

Kohsuke travaille sur un nouveau plugin de workflow. Je n'ai suivi son initiative que de loin pour le moment et je ne sais pas très bien le recouvrement. Je sais juste qu'il a profité des enseignements du build-flow, même si nous n'en avons pas nécessairement la même perception. Wait'n see.


3 commentaires
Inscription à : Articles (Atom)