Interview de Grégory Boissinot, committer Jenkins

J'ai un master en Génie Informatique, Option Ingénierie du logiciel à l'IUGF de Grenoble.

Après un premier CDD au sein d'une entreprise où j'avais fait mon stage, j'ai ensuite rejoint différentes sociétés de service pour finalement être aujourd'hui chez Zenika en tant que consultant et formateur.

J'interviens plus particulièrement chez de nombreux clients pour des missions courtes ou longues en tant qu'Architecte JEE ou Expert technique. Mon implication dans les problématiques de l'usine logicielle a commencé en 2005 lors d'une mission pour un grand groupe bancaire puis s'est poursuivie dernièrement au sein de deux grands acteurs industriels.

Mes contributions ont commencé quand j'ai démarré une mission pour un grand groupe industriel il y a maintenant presque cinq ans.

Je devais mettre en place des processus d'intégration pour l'ensemble des entités de ce groupe. Je me suis très vite confronté à une très grande diversité en termes d'équipes et de technologies. Certaines équipes étaient très petites et d'autres très importantes. Un petit nombre d'entre elles utilisaient déjà des éléments d'intégration et d'autres rien du tout. Et pour finir, en termes de technologie, cela était très varié avec tantôt du C/C++, du ADA mais aussi du .NET et un peu de Java.

Devant cette hétérogénéité, il m'a fallu un serveur d'intégration capable de répondre à ces problématiques pour instancier différents processus d'intégration, en particulier pour s'interfacer avec les différents outils (principalement de gestion de dépendances, de build et de métriques) pour l'ensemble de ces technologies.

À l'époque, aucun outil n'adressait l'ensemble de ces technologies. Ayant choisi Hudson/Jenkins pour son extensibilité, j'ai commencé à créer au fur et à mesure différents plugins pour s'interfacer avec toutes les plateformes et les technologies nécessaires, tout en gardant une approche générique. Par exemple, au lieu de faire un plugin par outil de tests, j'ai fait un plugin xUnit pour agréger la remontée des résultats de tests dans Jenkins, de l'ensemble des outils de tests que cela soit du Java, du C/C++, du Ada, du .NET, du PHP, du JavaScript…

Puis au fil de cette mission et des différentes autres missions de consulting et d'expertise que j'ai pu accomplir chez Zenika, j'ai été confronté à de nouveaux besoins. En particulier tout ce qui concerne la traçabilité et la reproductibilité du build, celui-ci étant dans certaines industries où on doit savoir reproduire un build pendant une dizaine d'années.

Toutes ces problématiques sont très particulières et ne sont adressées complètement par aucun outil. J'ai donc, par exemple, conçu et développé le plugin BuildContextCapture et son complément, le plugin EnvInject. Le premier plugin permet de capturer le contexte intégral du build. Le second permet de contrôler avec finesse les variables d'environnement de sa chaîne de build et de les exporter à la fin de la chaîne.

Aujourd'hui, je continue à titre personnel à maintenir tous mes plugins et à en créer de nouveaux pour les différents besoins qui se présentent.

Pour le moment, je ne participe pas au développement du noyau de Jenkins. Aujourd'hui, le noyau est devenu plutôt stable et les évolutions de la part de la communauté sont parcellaires. Jenkins expose de très nombreux points d'extensions permettant aux plugins de contribuer à l'ajout du comportement voulu. voulu. Ainsi à chaque fois que j'avais un besoin, je m'en suis sorti à travers des plugins via la combinaison de différents points d'extensions. Et même quand Jenkins avait quelques limitations dues à des problèmes de conception (limitations normales comme dans de nombreux logiciel), j'ai pu utiliser des plugins et la manipulation du cycle de vie des objets Java en mémoire. Je pense plus particulièrement à l'utilisation de la réflexion Java sur mon plugin DryRun, pour rajouter l'option de simulation (dry-run) à chaque étape d'un job Jenkins (builders, publishers, etc.).

Dans le choix d'un serveur d'intégration continue, il faut d'abord restreindre l'utilisation de Jenkins uniquement à un outil pour la mise en œuvre de son processus d'intégration. Même si Jenkins permet de faire beaucoup de choses, voire vraiment beaucoup de choses, il est important de concevoir son processus d'intégration, complètement agnostique à tout outil. Cette indépendance des outils est, par exemple, très importante dans des contextes de reproductibilité où un des critères pour y parvenir est de limiter les dépendances vers les outils afin d'éviter la complexité d'interactions et de mise en place dans un état cohérent. Avoir un processus d'intégration indépendant des outils permet de limiter les dépendances à un outil en particulier (demain, nous pourrions changer d'outil de build ou même de serveur d'intégration continue; les outils bougent très vite dans ce domaine technologique).

Plus précisément, dans un processus d'intégration continue, Jenkins doit se limiter aux rôles suivants :

• surveiller un environnement d'infrastructure à intervalles réguliers. Parmi les éléments à surveiller, on a en premier lieu l'outil de gestion de configuration logicielle, mais cela peut être également un filesystem ;
• préparer l'environnement de build. Il s'agit par exemple de l'exécution d'un ensemble de scripts pour créer des répertoires, mettre en place des droits utilisateurs pour des exécutions particulières ;
• lancer le build ;
• remonter les informations de métriques pour influencer le résultat du build ou son statut ;
• notifier l'équipe de développement.

Par rapport aux rôles ci-dessus, nous devons choisir un outil qui répond à l'ensemble de ces problématiques. Par exemple, choisir un outil possédant une bonne intégration avec son outil de gestion de configuration logicielle est indispensable.

Et en fonction de ces problématiques, seul Jenkins offre une diversité de plugins pour satisfaire la quasi-totalité de ces besoins d'intégrations.

J'ai commencé il y a sept ans au sein d'un projet pour un grand client dans le domaine bancaire. À l'époque, les technologies étaient Ant pour le build puis Maven 1. Et concernant le serveur d'intégration continue, j'utilisais CruiseControl.

Puis quand j'ai rejoint la cellule architecture de ce même client, j'ai mis en place une usine logicielle à destination de l'ensemble de ces projets. Au programme, mise en place de Maven 2, de Continuum, Archiva et des outils de qualité de code Java associés pour l'ensemble des projets.

Ensuite, concernant ce sujet d'intégration, j'ai rejoint un grand groupe industriel afin de mettre en place l'intégration continue de l'ensemble des entités où chaque projet utilisait des méthodologies et des technologies très différentes.

Comme je l'ai indiqué précédemment, j'ai utilisé CruiseControl et Continuum. Et bien sûr, j'ai utilisé Hudson avant le fork. J'ai aussi fait de nombreux essais avec TeamCity et Atlassian Bamboo.

Initialement, Hudson a été créé par Kohsuke Kawaguchi de Sun Microsystems, il y a plus de sept ans. Avec le rachat de Sun par Oracle, la majorité des employés sont partis. Kohsuke n'a pas eu le droit de réutiliser commercialement le nom de Hudson. Il a donc créé Jenkins. En ce qui concerne le choix, le premier point de décision est la prise en compte des plugins.

Aujourd'hui, 99 % des plugins qui sont maintenus ont migré vers Jenkins. Cela veut dire que la communauté qui a conçu les différents plugins et qui les maintient, a suivi le projet Jenkins. Lorsqu'on va choisir de mettre en place Hudson ou Jenkins en entreprise, ce qu'on veut c'est une communauté réactive qui puisse maintenir les différents plugins et avoir des réponses aux questions posées sur la mailing-list.

Oracle a donné Hudson à la fondation Eclipse et force est de constater que la version OSS de Hudson n'évolue plus aujourd'hui. Tout ce qui évolue en termes de noyau est fait sur Jenkins et tous les plugins sont sur Jenkins. Concernant le support commercial, Cloudbees apporte une version entreprise. La société propose une solution RUN@cloud qui consiste en une instance Jenkins en mode SaaS et dans laquelle on va déployer les artefacts. Cette instance Jenkins contient des plugins préconfigurés. Cloudbees propose aussi du support commercial sur Jenkins Enterprise. C'est une version stable du noyau qui fournit aussi des plugins orientés entreprise ainsi que la gestion VMware.

Aujourd'hui, en France, d'après mon expérience, peu de personnes paient pour obtenir du consulting sur des outils de build ou d'intégration continue. La tendance est plutôt de prendre un prestataire afin qu'il maintienne l'instance Jenkins locale. Cependant, j'ai pu constater que de nombreuses banques utilisent Atlassian Bamboo. En effet, ces banques utilisent Atlassian Jira. Au moment de l'achat, ils choisissent la suite complète qui fournit Jira mais aussi Bamboo. Et comme Bamboo est stable et remplit les fonctionnalités voulues pour du Java dans l'informatique de gestion, ces banques ne se posent pas la question d'utiliser Hudson/Jenkins. En revanche, Jenkins est fortement déployé dans des plus petites équipes où on a besoin de flexibilité et d'intégration avec la diversité d'outils et de langages qu'utilise l'équipe.