Interview : Arnaud Heritier (CloudBees) nous parle de Jenkins


SFEIR a profité de la JUG Summer Camp, la conférence Java de cette rentrée 2016 qui s’est tenue à La Rochelle, pour interviewer plusieurs personnalités. Parmi elles, Arnaud Heritier de chez CloudBees, qui aborde en détail les avancées de la version 2.0 de Jenkins.

SFEIR : Bonjour Arnaud, pourrais-tu te présenter ?

Arnaud : Bonjour, je travaille actuellement chez CloudBees, où je suis responsable de l’équipe support. CloudBees est un éditeur de logiciel, qui travaille sur Jenkins, le soft open source d’automatisation. Nous offrons à nos clients différentes versions du produit, pour les aider à accélérer leur mise en oeuvre de déploiement et d’automatisation.

Jenkins 2 est sorti cette année, quelles sont ses nouveautés principales ?

L’idée est de donner un nouvel élan à la communauté, et après 600 releases de la v1, Kohsuke a décidé de reprendre une logique de versioning plus classique. Avec des versions majeures régulières, des roadmaps, etc.

Cette v2 arrivée en avril avait été décidée en septembre 2015 et a bénéficié d’un énorme focus sur tout ce qui est Pipeline (Pipeline as Code). C’est ce qui permet de décrire sa configuration Jenkins mais qui aujourd’hui couvre la configuration de process complets sous forme de code, avec tous les avantages que ça implique : réutilisation de son code entre les projets, génération automatique, etc.

L’autre gros chantier de cette v2 concerne la partie démarrage de Jenkins, qui était assez compliquée, surtout côté sécurité, avec beaucoup de paramètres à régler. Cette v2 dispose d’un Wizard et d’une sécurisation par défaut de l’instance. On a aussi simplifié la gestion des plugins, où il devenait compliqué de s’y retrouver, de comprendre qui faisait quoi dans le millier disponible. Maintenant, nous proposons directement les plus intéressants dès l’installation de Jenkins.

La gestion de tous les jours est aussi simplifiée, avec un nouveau site web qui permettra par exemple de trouver plus facilement les plugins recherchés et bientôt de pouvoir faire la même chose directement depuis Jenkins, via le gestionnaire dédié.

Les plugins doivent maintenant ajouter ce support Pipeline pour fonctionner correctement, comment ça se déroule, face au nombre vertigineux de plugins dans Jenkins ?

Ça a été décidé ainsi pour forcer les gens à maintenir la compatibilité avec Pipeline, mais c’est aussi lié à la nature de ce dernier en 2.0, puisque qu’il offre un nouveau type de job, qui apporte des fonctionnalités nouvelles et spécifiques, comme la capacité d’être exécuté sur un agent pendant que le master redémarre, etc. Pour faire ça, il fallait repartir d’une base plus abstraite que les projets classiques. Ça nous aide aussi à faire le ménage, puisque les plugins qui ne se mettent pas jour vont indiquer un problème de maintenance et sont potentiellement à éviter.

Outre Jenkins Pipeline qui permet d’écrire le “build as code”, on a aussi une initiative plus ancienne qui est le Jenkins job DSL, qui permet d’écrire ses “Jobs as code” et donc de ne plus utiliser l’interface et de versionner au même titre que Pipeline. Où se trouve la frontière entre les deux ?

Les deux sont complémentaires. Ils ne bénéficient pas de la même granularité. Le but de job DSL était effectivement de simplifier ce qu’était un job dans Jenkins et d’en gérer plus sans trop de difficultés. Mais ça ne permettait pas de passer à l’étape supérieure, qui est de considérer qu’on s’arrête rarement à un job dans Jenkins. On a souvent des tas de jobs chargés de différentes tâches, et un job devient juste une tâche unitaire, qu’on a besoin d’assembler. C’est là qu’entrent en jeu les différents triggers et plugins qui gèrent ces derniers dans Jenkins. Et ça, c’est ce que sait et veut faire Pipeline : être capable de modéliser toute la structure des différents jobs et triggering, et pas juste une étape simple.

Les deux méthodes ne sont pas incompatibles, et il est même possible de créer un job DSL qui va être appelé par du Pipeline ou l’inverse. Mais le but c’est d’utiliser le pipeline à la place d’un maillage super compliqué de jobs, trop difficile à maintenir sur la longueur.

Avec toutes ces avancées “As code”, on aurait tendance à dire qu’il ne manque plus que la partie administration, settings… Est-ce que c’est prévu dans la roadmap ?

*rires* C’est vrai que le besoin a déjà été évoqué de très nombreuses fois. On sait très bien que le “As Code” ne concerne pas que Jenkins, c’est une mouvance globale, qu’on voit du côté des Ops, qui déploient toute leur infrastructure avec du code. Et c’est vrai qu’aujourd’hui déployer Jenkins, ça reste compliqué parce qu’il faut que l’instance soit up, il faut configurer ses plugins, etc. depuis l’update center. C’est donc difficilement compatible avec les usages actuels. Ça force à écrire des scripts groovy pour faire ça au démarrage, c’est pénible.

Pour régler ça, Kohsuke, qui devait s’ennuyer entre Noël et le jour de l’an, a commencé à écrire une sorte de “As Code” pour la partie déploiement de Jenkins, où l’on peut décrire ce qu’on veut dans son installation, les différents plugins, etc. et ça va automatiquement bootstrapper l’instance comme on le désire. Il a encore travaillé cette partie récemment, mais elle n’est pas sur la roadmap.

En revanche, ce n’est pas un jouet, on peut déjà faire des choses intéressantes avec et il est évident que c’est quelque chose qui va aboutir dans les mois à venir, pour répondre à ce besoin récurrent.

Avec l’arrivée de la 2.0, Jenkins a aussi communiqué sur le plugin Blue Ocean. Est-ce que ça a pour vocation de remplacer l’interface actuelle ?

L’idée serait effectivement de pouvoir refondre l’intégralité de l’UI et avoir l’ensemble des fonctionnalités réécrites façon Blue Ocean. Ce projet a été lancé environ en même temps que la v2.0, et est sponsorisé par CloudBees.

Faire une refonte d’UI c’est très compliqué, surtout dans le cas de Jenkins. De l’UI, il y en a partout. Pas juste dans Jenkins Core, car chaque plugins peut rajouter son petit bout d’UI. Donc si on veut moderniser l’interface, il faut mettre à jour les tonnes de plugins qui existent, et ça ne simplifie pas vraiment la tâche. Nous avons donc mis sur pied une équipe qui travaille sur cette problématique, avec des designers, des graphistes, bref, des pros du secteur, qui savent faire des choses modernes avec du JavaScript, etc.

Les premiers résultats sont impressionnants : ils ont réussi à utiliser l’extensibilité de Jenkins pour reprendre les données et les services qui sont exposés par le backend et complètement réécrire l’UI avec ces datas. D’ici la fin d’année, je pense qu’on arrivera à traiter facilement la partie visualisation. Nous avons déjà des choses bien plus modernes et mieux pensées côté ergonomie. Mais il reste beaucoup de boulot sur la partie admin, qui peut justement être modifiés par plein de plugins, sans parler des plugins uniquement cosmétiques, qui permettaient par exemple de se constituer un dashboard, qui deviendront obsolètes ou qui devront être entièrement réécrits.

Merci de nous avoir parlé de Jenkins et de nous avoir accordé du temps.

Avec plaisir, merci beaucoup !

Vous aimerez aussi...