Le premier Jenkins Community Day Paris s’est tenu à la Grande Crypte mardi 10 juillet dernier. Découvrez dans cet article les tendances à suivre lorsque vous utilisez Jenkins pour vos projets.

Retour sur le Jenkins Community Day 2017

Le premier Jenkins Community Day Paris s’est tenu à la Grande Crypte mardi 10 juillet dernier. Nous y étions afin de profiter des retours de la communauté sur les usages de Jenkins et pour en savoir plus sur l’avenir du projet. Pour cette première édition, de nombreux participants sont venus assister aux 7 conférences proposées sur un unique track.

Accueil par JFrog

Arnaud Ladrière
En introduction de la journée, Arnaud Ladrière de JFrog nous a présenté les produits de JFrog et l’utilisation conjointe avec Jenkins. Nous avons notamment vu XRay pour l’analyse de composants, Bintray et Artifactory pour l’hébergement et la distribution des livrables et enfin Mission Control pour monitorer ces différentes briques.
En particulier, il nous a présenté le plugin Artifactory pour Jenkins, et la notion de Buildinfo qui permet de retracer les informations liées au build, du commit git, jusqu’aux dépendances utilisées et de les consulter sur les dépôts compatibles.

The future of Jenkins as part of the devops revolution

Kohsuke Kawaguchi

Software is eating the world

Koshuke a présenté l’évolution du logiciel en insistant sur l’omniprésence dans tous les appareils de notre quotidien.
Aujourd’hui, chez Tesla, les voitures sont mises à jour OTA, c’était encore inimaginable il y a seulement 10 ans.
Les nouvelles fonctionnalités sont ainsi ajoutées aux voitures, telles que la conduite automatique.
Ainsi grâce au software, un bien physique peut conserver, voire augmenter, sa valeur dans le temps au lieu de devenir obsolète.
L’objectif est donc d’amener de nouvelles fonctionnalités le plus rapidement possible pour attirer les usagers.
Le risque d’amener les changements trop tard est qu’ils perdent en pertinence face au contexte et à la concurrence.
Il faut donc adopter un changement culturel pour déployer plus rapidement et intégrer les retours du marché au plus tôt.
C’est avec cette vision que les pipelines Jenkins sont mis en avant.
Présentation des chiffres de Jenkins (Installation, jobs, computers used, plugins)

Présentation des pipelines

Parmi les avantages que l’on peut retirer de la mise en place de pipeline, nous avons tout d’abord la simplicité de mise en place, la reproductibilité d’un build dans le temps puisque les projets et leurs branches portent la logique de construction.
Le support de Docker dans le pipeline va permettre de limiter l’adhérence au système de construction.
Le DSL du pipeline fournit aussi les opérations les plus courantes pour communiquer avec les gestionnaires de sources, pour gérer la construction avec des outils comme Maven.
Ce DSL est parfaitement extensible et peut ainsi s’adapter à vos besoins grâce au concept de Pipeline Libraries.

Présentation de BlueOcean

Kohsuke a poursuivi sa présentation des nouveautés Jenkins en décrivant les avantages de la nouvelle interface Blue Ocean. La lisibilité des étapes du pipeline est améliorée, l’accès aux logs est facilité par étape de construction.

Autres nouveautés

Un des problèmes des utilisateurs de Jenkins est qu’ils sont satisfaits de leur installation actuelle et négligent ou ignorent les nouvelles fonctionnalités. Pour faciliter l’évangélisation, l’équipe de Jenkins a focalisé ses récents efforts sur la documentation du projet par la mise en place :

• Un nouveau site : https://jenkins.io/
• Des visites guidées des pipelines
• Un getting started pour bien débuter avec les pipelines
• Une référence complète sur le Pipeline

Les Meetup JAM (Jenkins Area Meetup) fleurissent un peu partout dans le monde, facilitant aussi l’évangélisation des bonnes pratiques de mise en place de vos Pipeline de construction.
Tout n’est cependant pas rose et du travail reste à accomplir pour tout ce qui concerne la sécurité, la gestion de l’infrastructure (ndr : et aussi la possibilité de tester unitairement le code du pipeline).
Kohsuke a conclu en mettant en avant la renaissance de Jenkins.

(JENKINS, DOCKER) -> { Orchestrons le continuous delivery }

Nicolas de Loof
Jenkins, issu de Hudson, a été créé originellement pour faire de la CI. L’évolution amène à tendre vers le Continuous Delivery (quand on fait confiance à ses tests), ceci toujours avec Jenkins.
Seulement aujourd’hui, il n’existe pas de plugin unique pour le CD. Alors, pouvons-nous utiliser Docker ? Si oui, quel plugin pouvons-nous utiliser ?
Historiquement, différentes populations sont ciblées par les étapes du workflow lié à la mise en production d’applications :  Dev, QA, Ops. En pratique ceci se traduit par :

• Des jobs différents
• Des règles de nommages (pour ordonner les jobs, gérer les droits, …)
• Un système de promotion et la définition des jobs définis en amont ou en aval (très pratiques à maintenir dans le temps…)

Nicolas a donc présenté le plugin Build Flow supprimé de l’update center car il connaît des problèmes de sécurité et qu’il n’est pas maintenu. En revanche, les concepts sont à reprendre.
L’objectif de ce plugin est de décrire l’enchaînement des jobs, mais également de ce que nous souhaitons voir Jenkins faire (acceptation/promotion manuelle via l’instruction ‘’input’’ du DSL, par qui, …).
En aparte, Jenkins peut-être relancé au cours des builds, ceux-ci reprendront.
La présentation s’est ensuite enchaînée sur le Plugin Docker pipeline permettant d’utiliser les instructions relatives à Docker. Il est ainsi possible d’instancier des images maven pour la construction des artefacts ou l’exécution de tests d’intégration. Docker rend l’exécution des étapes de construction étanches entre elles et également décorrèle les versions applicatives de l’hôte par rapport aux pré-requis des jobs.
Le Multibranch Pipeline crée automatiquement les jobs lorsqu’un Jenkinsfile est detecté sur les différentes branches du projet.
Cette détection permet, lors de l’ajout d’une nouvelle branche, de créer automatiquement un nouveau job un build référence. Cela permettra de voir les évolutions de la feature branche (régressions des TUs ou améliorations).
Les prochaines évolutions sur le plugin Docker slave consistent à ajouter le support docker-compose pour prendre en compte plus facilement les liaisons entre conteneurs lors des tests d’intégrations par exemple.
Q&A

1. Est-il possible d’avoir un Jenkins-light sur le poste de dev pour tester les Jenkinsfile ?

Non, pas de Jenkins allégé disponible. Par le biais de l’IHM, il est possible de faire un replay du pipeline, mais le support n’est pas complet par les plugins (rappel: ~1350 plugins).
Préconisations :

• Utiliser pipeline pour préparer les environnements
• Actions réalisées par un script shell pour tester/débugger
• Le Jenkinsfile ne devrait qu’orchestrer les opérations lourdes de traitements car compliqué à tester

2. Pour les déploiements blue / green, comment gérer les rollback de base de données ?

Rollback de versions compliqué à implémenter, à voir en fonction du besoin, “l’automatisation n’est pas automatisée ;)”

Comment Terradue utilise Jenkins et Artifactory pour automatiser le déploiement d’applications en sciences de la terre

Emmanuel Mathot
La société Terradue exploite des données satellites de cartographie pour les mettre à disposition notamment aux communautés de chercheurs. Ces données leur permettent de surveiller l’évolution d’indicateurs (hydrologique, géologique, …).
Les défis à relever dans ce contexte sont les suivants :

• Volume de données important mis à disposition sur le Cloud (430 To de données par an).
• Les chercheurs en SVT ne sont pas des informaticiens (pas d’industrialisation côté outils utilisateurs).

L’objectif est de fournir une plateforme de services et de données permettant aux chercheurs de faire tourner leur code sur cette plateforme.
La plateforme fournit à l’utilisateur un cadre pour industrialiser la livraison et le déploiement de son application.
L’utilisation des pipelines permet aux scientifiques de bénéficier d’un environnement d’intégration continue. Ils se concentrent ainsi sur leur programmes.
Le pipeline se termine par la création d’images Docker déployables sur plusieurs plateformes de Cloud (AWS, Google…).
Cet outillage permet de réduire de 30% les opérations nécessaires aux livraisons et déploiements.

Docker Jenkinsfiles : comment j’ai appris à ne plus m’en faire et à aimer Jenkins

Laurent Grangeau
Laurent Grangeau nous a présenté un retour d’expérience de son équipe Continuous Delivery dans une grande banque française. L’équipe a été composée de 15 personnes fut un temps, maintenant 7 personnes et une équipe en OffShore à Bangalore et s’adresse à 5000 développeurs dans différents pays.
L’objectif de l’équipe était de mettre en place et assurer le MCO sur Jenkins pour éviter que les développeurs n’utilisent une instance déployée et gérée en shadow IT.
L’équipe a mis en place Github en interne pour faciliter les échanges et partager la connaissance entre les collaborateurs sur un mode Inner source.
Dans un premier temps, un unique Jenkins a été mis en place pour réaliser les tâches suivantes : build, packaging, tests, provisionning d’environnements (dev, prod), automatisation de tâches, …
Le commencement était assez archaïque : gestion par ticket des demandes, création de Job freestyle, un unique master pour tout, ajout de slaves manuel…
En définitive, cette façon de faire s’est révélée compliquée à maintenir, peu stable. La création de nouveaux jobs était lourde et les équipes projet ne se sentaient pas investies. Par ailleurs, le suivi des jobs et de la plate-forme étaient compliqués.
Exemple : ils ont créé un script de détection des jobs en erreur depuis plus d’un an et suppressions de ces jobs. Cela a permis de supprimer 400 Jobs obsolètes.
La seconde étape a vu le passage à Jenkins 2. Cela a amené plusieurs modifications sur les processus :

• Utilisation de jenkinsfile et templates de projets (Jenkinsfile + librairies de base) par technos fournis aux équipes pour la gestion des jobs
• Utilisation du plugin Jenkins Swarm pour gérer les slaves jenkins
• Séparation en plusieurs masters par équipe afin de leur confier la responsabilité et l’autonomie sur leurs instances, avec un support de l’équipe CD tout de même

REX : aujourd’hui, Nexus est derrière Artifactory en terme de gestion des packages “exotiques” (ruby, npm docker…).
Les équipes sont autonomes sur les images et l’exécution des conteneurs => gain en flexibilité pour les builds.
L’ensemble de ces étapes a permis un gain de productivité significatif : passage de 15j à 5j pour l’initialisation de nouveaux projets.
Les conclusions sont les suivantes :
Faites des Jenkinsfile
Attention aux instances jenkins trop grosses (splitter les instances)
Stateless over Stateful
Faire du stateless sur vos slaves

Le CI/CD pipeline pour ses clients d’API

Quentin Adam remplacé par Laurent Doguin et Philippe Charrière
Hosting Powers : documentation d’API avec Swagger
Server management : beaucoup d’opérations manuelles
La présentation s’est d’abord concentrée sur la notion d’”immutable infrastructure” en se focalisant sur le fait que les variables d’environnement doivent permettre de configurer la même base de code, cela permet de faciliter le déplacement d’une app sur une autre machine.
Chez CleverCloud, lorsqu’une session ssh est ouverte par un humain sur une vm, la vm est supprimée car cela n’est pas “normal” d’effectuer des opérations hors process.
De même lorsqu’une VM ne fonctionne plus très bien, plutôt que d’investiguer sur la cause, celle-ci est remplacée par une neuve.

Scaler Jenkins sur Google Cloud

Guillaume Laforge
Guillaume Laforge nous a présenté une solution pour déployer jenkins scalable sur Google Cloud.
Le contexte présenté pour la démonstration consiste à passer d’un projet avec un développeur et commits épisodiques à n projets, avec n développeurs et donc beaucoup de commits. Ce qui entraîne des builds beaucoup plus fréquents et donc le besoin de scaler Jenkins, en particulier les slaves.
L’ensemble des éléments nécessaires à la démonstration sont disponibles sur Github.
On notera en particulier, l’utilisation de Jenkinsfile, du Jenkins Kubernetes Plugin afin de provisionner les slaves sur Google Cloud à la demande et de les supprimer en fin de build et enfin l’intégration de l’authentification avec le Google OAuth Plugin.
La présentation est disponible en ligne.

Automatiser sa chaîne devops avec Jenkins et JHipster

Denis Floch / Julien Dubois
Julien Dubois nous a présenté la génération d’une application JHipster et son intégration dans une chaîne de CI/CD. La démonstration est disponible sur github : https://github.com/jdubois/jenkins-community-day
La stack de l’application générée est la suivante :

• Back : Springboot construit avec maven
• Front : Angular 4 construit avec webpack

Le tout permet de produire une image docker basée sur alpine dont la taille finale est d’environ 100 Mo.
Jhipster embarque un sous générateur permettant de mettre en place la CI sur le projet: “jhipster ci-cd”.
Il est possible de générer les descripteurs pour CircleCI, Travis, GitlabCI, Jenkins.
Denis Floch nous a ensuite présenté un retour sur les différentes étapes de la mise en place du déploiement continu sur un projet en conditions “réelles”.
Etape 1 : Début du projet avec des projets freestyles mais multiplication des jobs et maintenance difficile.
Etape 2 :  Uniformisation grâce au Pipeline et les Jenkinsfile pour profiter de la gestion de source Gitlab, avec plusieurs Jobs par projets…
Etape 3 : Diminution du nombre de job et factorisation du code via les librairies Jenkins. En particulier mise en place de shared libs, pour notamment enrichir le DSL avec des fonctions spécifiques au projet. De plus, les shared lib ne sont pas soumises à la sandbox contrairement aux Jenkinsfile ce qui facilite leurs écritures. NDR : La sandbox restreint l’utilisation d’API Groovy et Java à une liste blanche afin de limiter les risques de failles de sécurité.

En résumé

Ce qu’il faut retenir de cette journée :

• Faites des Jenkinsfile
• Les slaves doivent-être sans état pour être provisionnés dynamiquement
• Apprenez les bases du groovy pour en tirer le meilleur parti
• Faites des Jenkinsfile
• Pas d’instance Jenkins unique pour tous les projets, préférer une instance par équipe projet pour favoriser l’autonomie des équipes, leur implication dans l’utilisation et la maintenance de l’outil
• Faites des Jenkinsfile (je l’ai déjà dit ? 😉 )

Co-auteurs : Pierre-Yves Aillet et Grégory Bévan