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:
Tu as testé
https://wiki.jenkins-ci.org/display/JENKINS/Jenkow+Plugin
Design de workflow avec BPM dans Eclipse et lien avec Jenkins.
Il y a une video qui explique tout ça. Pas testé mais ça a de la gueule.
oui je le connais bien. Approche complètement différente. Faut aimer le BPM, c'est pas exactement la même cible - le nombre d'installation le montre d'ailleurs. Le côté 'boi-boites, flêches" est loin de faire l'unanimité.
Keep it simple qu'ils disaient...
Les devs veulent des DSL, les modeler mange du BPM au petit Dej' the right tool for the right person?
Jenkins devient plus orchestrateur que serveur CI...
Plus sérieusement et parce que c'est jamais assez compliqué on rajoute du DeployIt pour piloté un job Jenkins qui lance 12 sous-jobs...
Je sais pas ou ça va nous amener tout ça
Enregistrer un commentaire