CI/CD as a Service

L’intégration et la livraison continues sont des composantes fondamentales de la démarche DevOps. Toutefois, alors que les pipelines doivent prendre en compte les nouvelles architectures – conteneurs notamment –, il devient nécessaire d’abstraire un peu plus ces étapes du cycle de vie d’une application : c’est le sens d’une approche as a Service du CI/CD.

CI, CD, CD : de quoi parle-t-on ?
Par intégration continue, on entend l’intégration de changements apportés au code par les différents membres d’une équipe de manière continuelle. Ces intégrations, qui fusionnent dans un répertoire commun les copies de chaque développeur, vont être automatiquement testées (tests unitaires et d’intégration) par un build de sorte à vérifier que des erreurs ne se soient pas glissées dans les modifications.

La livraison continue, ou Continuous Delivery, reprend cette brique en l’élargissant au dépôt du code vérifié dans un référentiel (GitHub, GitBucket, GitLab) afin qu’il puisse être déployé par l’équipe d’exploitation. Enfin, le déploiement continu (Continuous Deployment), là encore CD désigne le transfert automatique des modifications effectuées par le développeur du référentiel vers l’environnement de production. Il se différencie donc de la livraison continue en ce que celle-ci simplifie le passage en production, réalisé par l’équipe d’exploitation, quand le déploiement continu automatise ce même processus.

Mais attention, d’un éditeur à l’autre, les définitions varient, les deux CD étant bien souvent interchangeables et confondues. Ainsi, déploiement et livraison sont parfois opposés comme deux méthodes distinctes, quand d’autres en font deux étapes consécutives d’un même processus. Toujours est-il que tout le monde s’entend sur le fait le CI/CD repose sur l’automatisation de différentes phases du cycle de vie d’une application. Pour l’ensemble de la chaîne, on parle de “ pipeline CI/CD ”.

Début décembre, CloudBees annonçait “ CloudBees CI/CD powered by Jenkins X ”, décrite comme une solution de CI/CD (Continuous Integration / Continuous Delivery ou Deployment) as a Service. Petit retour en arrière : Jenkins a été, au début de la décennie 2010, une des premières briques du DevOps. Cet outil open source d’intégration continue, développé en Java, vient automatiser les étapes de build et de tests. Surtout, par le biais de ses 1 500 plugins, Jenkins étend ses fonctionnalités en s’intégrant à moult autres outils de tests et de déploiement. Bref, Jenkins fait tout sauf le café. Mais voilà qu’arrivent les conteneurs et Kubernetes. C’est à partir de ce moment-là que Jenkins commence à caler.

Pour livrer une application sous forme de conteneurs en passant par Jenkins, il est nécessaire de configurer les pipelines, d’ajouter les bons plugins… Bilan, les développeurs se voient contraints d’étudier comment empaqueter des logiciels sous forme d’images Docker, de créer des fichiers YAML adaptés pour exécuter leur application dans Kubernetes, de créer des environnements de prévisualisation, d’apprendre à écrire leurs propres pipelines Jenkinsfile… Ce qui s’avère chronophage et, pendant ce temps, les développeurs ne développent pas.

En 2018 a donc été conçu Jenkins X, qui vient supprimer certains des problèmes causés par la complexité globale de Kubernetes et son écosystème, en évitant de devoir passer des mois à essayer de trouver la bonne façon de faire les choses.

S’adapter aux conteneurs et à Kubernetes
Jenkins X est un outil de CI/CD qui, une fois installé, configure automatiquement tous les différents outils (Helm, Docker, Nexus, Skaffold, etc.) et crée, à partir d’un nouveau projet ou d’un projet existant et importé, un pipeline CI/CD et des aperçus entièrement automatisés. « Cela permet à vos développeurs de se concentrer sur la création d’applications pendant que vous déléguez à Jenkins X pour gérer votre CD CI », explique l’équipe derrière le projet. Par défaut, un pack contient le nécessaire pour transformer le code en une image de Docker (DockerFile), pour composer le pipeline (Jenkinsfile), pour générer les ressources Kubernetes permettant l’exécution dans Kubernetes (helm chart) et pour définir les dépendances (preview chart). L’outil est donc taillé pour les applications cloud-native et automatise leur intégration et leur déploiement. La distribution stable de Jenkins X est fournie par l’un des principaux contributeurs au projet, CloudBees. Qui a donc, en décembre dernier, annoncé une préversion de sa propre itération de Jenkins X en mode as a Service.