Les utilisateurs du projet open source CI/CD de Jenkins ont fait le point sur la première feuille de route publique du projet, lors de sa conférence annuelle cette semaine, en évaluant les plans visant à résoudre les problèmes d’expérience utilisateur, et à adapter la méthode « as code » favorisée par l’approche GitOps.
Jenkins, dont la première version a été publiée en 2011, est un outil open source d’intégration et de livraison continue (CI/CD), un processus central de l’approche DevOps. La communauté open source Jenkins est l’une des plus importantes, avec 5 400 contributeurs dans 111 pays, et elle contient de multiples – parfois opposées – circonscriptions.
Alors que les responsables du projet élaborent la feuille de route publique, lancée le 15 juillet, ils doivent trouver un équilibre entre ces divers intérêts.
La feuille de route doit conseiller chacun de ces publics sur l’orientation du projet, mais elle a également vocation à montrer aux utilisateurs potentiels que les responsables du projet suivent les tendances technologiques, selon Oleg Nenashev, un contributeur principal à Jenkins et ingénieur chez CloudBees, dans une présentation tenue la semaine dernière, lors de la conférence virtuelle DevOps World.
Serverless, mon amour
« La plupart des gens imaginent Jenkins tel qu’il était en 2012, c’est-à-dire un petit projet avec une interface Web », déclare Oleg Nenashev. « Mais Jenkins a beaucoup changé ».
La feuille de route de Jenkins CI/CD comprend des intégrations mises à jour avec des plates-formes telles que Kubernetes, des produits de type « functions as a service » (FaaS) et les pipelines de Google Tekton pilotés par les événements. À long terme, le Jenkins classique – qui s’intègre avec Kubernetes par l’intermédiaire d’un opérateur – sera incorporé dans Jenkins X, une version plus récente reconstruite pour fonctionner sur des containers et Kubernetes, selon les responsables de la Continuous Delivery Foundation (CDF), qui régit désormais le projet.
Les utilisateurs de Jenkins Enterprise espèrent voir la communauté accélérer le soutien aux infrastructures cloud natives, qu’elle adopte notamment le FaaS.
« Nous avons eu des difficultés récemment à cause du manque de plug-ins officiels pour les déploiements serverless […], nous avons dû en quelque sorte pirater la solution », témoigne Amit Bhandarkar, directeur de l’ingénierie chez American Express Global Business Travel, lors d’une session de questions-réponses avec les médias lors de la conférence. « C’est une opportunité énorme […] lorsque vous passez au cloud, si vous construisez quelque chose de nouveau et que c’est transactionnel, vous voudrez utiliser des solutions serverless ».
UX : refonte ou pas refonte, telle est la question
D’autre part, l’expérience des utilisateurs est un problème de longue date pour Jenkins CI/CD, et la feuille de route publique contient une piste spécifique pour l’amélioration de la facilité d’utilisation d’un côté, et de l’autre, de l’interface utilisateur du projet – notamment une révision de l’UX dirigée par un groupe d’intérêt spécial UX/UI.
Ces efforts ont commencé l’année dernière après que la communauté ait décidé d’adopter une nouvelle approche succédant au projet Blue Ocean UI lancé en 2017. Blue Ocean existe toujours, mais le SIG UX va revoir l’architecture de l’interface utilisateur pour la rendre plus flexible et extensible.
« Blue Ocean a rencontré un succès limité : il a notamment permis de mieux visualiser l’exécution du pipeline, mais il n’a pas réussi à atteindre ses objectifs plus larges de création d’une toute nouvelle interface utilisateur pour Jenkins », écrit Jeremy Hartley, chef de produit Jenkins chez CloudBees, dans un article de blog de la CDF le mois dernier. « La principale leçon de Blue Ocean est que si vous n’avez pas de plan dès le départ pour gérer l’extensibilité que fournissent environ 1 700 plug-ins, vous échouerez ».
Certains utilisateurs de Jenkins CI/CD souhaiteraient également une meilleure stabilité de l’UX, ainsi qu’une esthétique plus attrayante.
« L’interface utilisateur de Jenkins est datée – elle semble sortir du début des années 2000 », considère Mark Kruse, ingénieur principal de DevOps chez Cengage, une société de logiciels d’apprentissage en ligne basée à Boston. « Mais il y a aussi des changements de fonctionnalités que j’aimerais voir… Nous trouvons que même un Build_Log bloque l’interface, et cela a un impact sur d’autres Build ».
De grandes entreprises telles que SAP, Salesforce et Adobe ont commencé à utiliser GitHub comme interface principale pour tous les aspects de la livraison de logiciels et de la gestion de l’infrastructure IT – une pratique connue sous le nom de GitOps – et préféreraient que la communauté concentre ses efforts sur les intégrations avec ces outils.
« La refonte de l'UX serait bienvenue, mais je ne pense pas que ce soit la meilleure manière d'exploiter le temps de la communauté. »
Carlos SanchezIngénieur logiciel, Adobe
« Nous essayons de pousser nos utilisateurs exigeants en matière d’interface utilisateur dans cette direction, en distribuant les retours d’information via Pull Requests, au lieu de passer par une UX rutilante » témoigne Sven Merk, un architecte en sécurité qui a participé à la conception de la plate-forme Jenkins interne de SAP, dans une interview. « Avec le passage à un monde plus DevOps, les équipes se familiarisent de plus en plus avec ce type d’outil ».
Pour ces entreprises, la communauté Jenkins a également publié cet été une intégration avec l’API GitHub Checks, qui permet de créer des rapports détaillés sur les pull requests, y compris des annotations, et d’effectuer des actions automatisées en réponse à ces dernières via GitHub.
« La refonte de l’UX serait bienvenue, mais je ne pense pas que ce soit la meilleure manière d’exploiter le temps de la communauté », avance Carlos Sanchez, ingénieur principal en logiciels de cloud computing chez Adobe et ancien ingénieur principal chez CloudBees. « Je pense à une intégration plus poussée avec des outils comme GitHub, où vous n’avez même pas besoin de regarder l’interface utilisateur ».
Une jungle de plug-ins à gérer
Un autre défaut de Jenkins CI/CD régulièrement pointé du doigt concerne le système de plug-in. Jenkins est fondamentalement conçu pour être un framework relativement léger que les contributeurs et les éditeurs améliorent avec un ensemble de plus de 1 700 plug-ins.
Ce système offre un maximum de flexibilité et de personnalisation pour ceux qui ont les compétences nécessaires pour le développer. Cependant, les utilisateurs traditionnels ont généralement trouvé les plug-ins difficiles à mettre en place et à maintenir – en particulier lors des mises à jour de Jenkins – et sujets à l’abandon par les contributeurs tiers qui les créent.
« Jenkins lui-même, bien qu’il soit standard et fonctionnel, ne fait pas grand-chose en soi », déclare Mark Kruse de Cengage. « Tout ce que vous voulez faire nécessite un plug-in, et la question qui se pose alors est la suivante : “Combien de temps cette tierce partie va-t-elle supporter cela, quand cela va-t-il se casser et quand vais-je devoir le refaire ?” »
Oleg Nenashev de Cloudbees a répondu à de nombreuses plaintes d’utilisateurs concernant la maintenance incohérente des plug-ins lors d’un chat virtuel pendant sa présentation cette semaine, en disant que la communauté avait l’intention de recruter plus de contributeurs par le biais d’un programme « Adopt-A-Plugin ». La feuille de route de Jenkins comprend également des plans pour améliorer la documentation, ce qui aidera les contributeurs tiers à maintenir le code à jour.
Les récentes versions de Jenkins CI/CD ont aidé à la configuration et à la mise à jour des plug-ins grâce à une fonctionnalité appelée Jenkins Configuration as Code (JCasC), qui supprime la nécessité pour les administrateurs d’écrire leur propre code d’intégration de plug-ins.
« Les plugins ont causé l'un des plus gros problèmes de maintenance dans la mise à jour de Jenkins et il a fallu s'assurer que le système est à jour et ne présente aucune vulnérabilité. »
Venkat KothapalliIngénieur logiciel, Salesforce
La feuille de route de Jenkins demande plus de travail pour créer un processus de livraison continu pour les plug-ins et pour améliorer l’extensibilité de JCasC, mais la configuration as code a contribué à faciliter la gestion des plug-ins pour les responsables IT de Salesforce, selon une présentation lors d’une conférence virtuelle.
« Les plug-ins ont causé l’un des plus gros problèmes de maintenance dans la mise à jour de Jenkins et il a fallu s’assurer que le système est à jour et ne présente aucune vulnérabilité », indique Venkat Kothapalli, un ingénieur logiciel chez Salesforce, pendant la conférence. « En utilisant JCasC, nous sommes capables de capturer toute la configuration des plug-ins dans un fichier texte, et nous avons un script de plug-in – supporté par CloudBees – qui peut être exécuté lorsque vous [mettez à jour] votre environnement ».
Les prochaines versions ajouteront également des informations plus détaillées à l’interface de gestion des plug-ins Jenkins, telles que les logs des modifications, les problèmes signalés, les versions prises en charge et les avertissements de sécurité.
