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.
Optant dès sa Version 3 pour une approche Container as a Service, OpenShift cherche à rendre les conteneurs plus accessibles aux développeurs, quand bien même ils n’auraient pas une connaissance approfondie de Kubernetes.
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.
