Les entreprises sont de plus en plus nombreuses à adopter les pratiques DevOps pour leurs projets informatiques. L’intégration continue (CI), le déploiement et la livraison en continu (CD) sont devenus partie intégrante du processus de développement de logiciels. Nous allons voir quels sont les outils disponibles à l’heure actuelle.
Légende illustration ci-dessus : Codeship (https://codeship.com) offre aux développeurs des options de Cloud simples afin d’accélérer le développement.
Outils de suivi et de gestion de versions
Les outils tels que Jira, payant, ou Bugzilla, gratuit et open source, apportent une meilleure visibilité sur l’état d’avancement de vos projets et facilitent la collaboration des équipes distribuées. Les logiciels de gestion de versions sont eux totalement incontournables, par exemple Git. Le fait d’établir un référentiel unique – une « single source of truth» – pour votre équipe permet d’établir un suivi précis des changements effectués dans le code source, ce qui sera essentiel lorsqu’il s’agira de faire un petit saut dans le passé à la faveur d’un rollback. En facilitant la collaboration des équipes et en intégrant les changements dans le dépôt de code partagé, la mise en place du concept GitOps (lire l’encadré et https://www. objectif-libre.com/fr/blog/2019/12/17/ gitops-tour-horizon-pratiques-outils/) peut grandement améliorer le fameux MTTR (Mean Time to Recover).Processus et tests à automatiser
Il est indispensable d’automatiser le processus de compilation du code. Les développeurs doivent faire une code commits au moins quotidienne, voire plusieurs fois par jour. Les tests de vérification doivent eux aussi être automatisés. Les tests unitaires seront généralement les premiers à être automatisés afin de réduire au plus vite la charge de travail des développeurs. Suivront les tests fonctionnels, puis les tests d’interface utilisateur. Les tests fonctionnels ne requièrent généralement pas de mises à jour fréquentes du script d’automatisation, contrairement aux tests UI qui induiront certainement des changements plus fréquents. En résumé, il faut essayer de prendre en considération l’ensemble des dépendances possibles et évaluer leur impact afin de définir avec précision les tâches d’automatisation prioritaires. 
Une étude IDC (https://www.idc.comgetdoc.jsp?containerId=US42656218) rapporte que le marché mondial des logiciels DevOps représentait 5,2 milliards de dollars en 2018 et devrait atteindre les 15 milliards de dollars en 2023.
Déploiement
Il existe différentes méthodes de déploiement : canary release, BlueGreen, tests A/B. En mode canary release, la mise à jour est poussée vers un petit groupe d’utilisateurs qui vont la tester. Si tout va bien, elle sera déployée. Sinon, le processus reprend à l’étape précédente. Concernant les bonnes pratiques en la matière et le fonctionnement du CI/CD as a service, nous vous renvoyons à l’article de Guillaume Perissat à l’adresse https://www.linformaticien.com/dossiers/cicd-as-aservice.aspxGitLab CI
GitLab CI est un outil d’intégration continue intégré à GitLab. Il sert à la fois à héberger du code et à développer des référentiels git. Initialement publié en tant que projet autonome, GitLab CI a été intégré dans le logiciel principal GitLab avec la sortie de GitLab 8.0 en 2015. Gitlab CI est donc une composante de GitLab programmée en Ruby et en Go. Il supporte la livraison et le déploiement en continu. Il est open core et peut être auto-hébergé ou hébergé sur le Cloud. La version gratuite ne propose que quelques fonctionnalités. Pour un pack plus complet, le tarif varie de 4 à 99$ par mois et par utilisateur. Dans GitLab CI, le processus CI/CD est défini dans un fichier du référentiel de code grâce à des instructions de configuration en YAML. Le travail à effectuer est ensuite envoyé aux machines appelées «coureurs», faciles à configurer et pouvant de plus être provisionnées sur de nombreux systèmes d’exploitation. Lors de la configuration des coureurs, vous pouvez choisir votre outil et votre mode d’exécution des tâches (Docker, Kubernetes, VirtualBox…).
Le couplage étroit de GitLab CI avec la plate-forme de référentiel GitLab a des implications fortes sur la manière dont il peut être utilisé. La fonctionnalité intégrée permet aux utilisateurs de GitLab de configurer un environnement CI/CD sans devoir installer – ni apprendre à utiliser – un outil supplémentaire. Les tests automatisés peuvent par exemple commencer par activer quelques options dans l’interface web, enregistrer une machine d’exécution et/ou ajouter un fichier de définition de pipeline dans le référentiel. La dite «relation de proximité» vous permet également de partager les coureurs entre plusieurs projets, de voir automatiquement l’état de la construction dans le référentiel et de conserver les artefacts de construction avec le code qui les a produits. GitLab possède, entre autres, une fonctionnalité appelée Auto DevOps qui permet, pour les projets les plus simples, de construire automatiquement un pipeline avec plusieurs tests intégrés. Ce système utilise également des packs de création Herokuish permettant de déterminer le langage employé et la manière de créer l’application. Il offre des intégrations natives dans Kubernetes ce qui lui permet de déployer automatiquement des applications dans un cluster Kubernetes avec une méthodologie de déploiement, comme celles basées sur les pourcentages et la méthode Blue-Green. GitLab offre aussi de nombreuses fonctionnalités complémentaires, telles que les opérations et la surveillance avec Prometheus qui est déployé automatiquement avec votre application. Gitlab CI permet la gestion de portefeuilles et de projets avec GitLab Issues, Epics et Milestones et de modifier le code directement dans GitLab avec WebIDE. Vous pouvez ainsi obtenir un aperçu ou exécuter une partie d’un pipeline pour une analyse plus rapide.
Jenkins
Jenkins (https://jenkins.io/) est un outil open source adapté au DevOps avec une dimension collaborative. Il est écrit en Java et publié sous licence MIT. C’est l’un des tout premiers serveurs d’intégration continue en Open Source qui soit apparu et il reste encore l’un des plus utilisés à l’heure actuelle. Jenkins faisait à l’origine partie du projet Hudson, mais la communauté et la base de code open source se sont scindées à la suite de conflits de droits sur les marques avec … Oracle – eh oui, encore… – après le rachat de Sun Microsystems, grand bienfaiteur de l’Humanité numérique – Sun, pas Oracle. Hudson a été publié en 2005 alors que la première sortie sous le nom de Jenkins n’a été faite qu’en 2011. Au fil des années, Jenkins a évolué pour devenir un système puissant et flexible d’automatisation des tâches liées aux logiciels. Jenkins sert principalement de cadre d’automatisation avec une grande partie de la logique implémentée via une bibliothèque de plugins. Tout est géré par des plugins, de l’écoute de points d’ancrage web ou l’observation de référentiels jusqu’à la création d’environnements de build et de prise en charge linguistique. Même si cela offre une grande flexibilité, votre processus de CI risque de s’appuyer sur de nombreux plugins tiers, ce qui rend l’ensemble assez fragile. Son workflow de pipeline, lui aussi fourni via un plugin, est disponible depuis 2016. Ce processus de CI peut être défini de manière déclarative ou impérative à l’aide du langage Groovy dans des fichiers du référentiel ou via des zones de texte dans l’interface utilisateur web de Jenkins. La distribution JCasC (Jenkins Configuration as Code) permet de définir une configuration «sans contact» via un fichier YAML. Jenkins Evergreen simplifie encore ce processus en fournissant des configurations Jenkins prédéfinies basées sur différents cas d’utilisation (use case). Ces distributions sont plus faciles à maintenir et à mettre à niveau que la distribution Jenkins classique. Jenkins 2 a introduit la fonctionnalité de pipeline natif avec deux types de pipelines. Jenkins X représente une transformation importante de Jenkins. Il prend en charge JCasC et Evergreen et permet de les utiliser de façon optimale sur Kubernetes. L’outil IC Jenkins ressemble assez à Butler, mais en plus orienté développeur.CloudBees
CloudBees était au départ un fournisseur de plate-forme cloud (PaaS) avant de proposer ses propres outils d’intégration continue, dont Jenkins. Parmi les produits de l’entreprise californienne, on retrouve un service cloud (DEV@Cloud), ainsi que des distributions commerciales et plutôt haut de gamme de Jenkins, comme Jenkins Enterprise et Jenkins Operations Center.
Flux est l’outil de déploiement et livraison en continu de Weave, lui-même sous la gouvernance de la CNCF (Cloud Native Computing Foundation) en tant que Sandbox Project.
Flux
Flux est l’outil de CD de Weave qui, rappelons-le, est sous la gouvernance de la CNCF (Cloud Native Computing Foundation) en tant que Sandbox Project. C’est un opérateur Kubernetes permettant de synchroniser les manifests Kubernetes contenus dans un dépôt Git et de les déployer. Il s’inscrit donc dans une stratégie pull. Flux est extensible et peut facilement être complété par de nombreux outils de templating de manifests tels que kustomize ou jsonnet. Il intègre les modes pull et watch des registries docker. En cas de modifications sur un registry, il peut commiter sur le dépôt git afin de mettre à jour le tag de l’image docker utilisée dans un manifest. Il peut aussi envoyer une alerte via Slack, par exemple lors d’une divergence constatée entre les manifests stockés sur Git et des ressources déployées sur le cluster Kubernetes. Flux ne supporte qu’un dépôt Git par instance. La communauté a développé un outil, Fluxcloud, offrant la possibilité d’envoyer les événements Flux sur Slack. Comme il est fortement conseillé de séparer les manifests Kubernetes du code applicatif, vos manifests devront être rassemblés sur un unique dépôt Git. Si cela ne convenait pas à votre cas d’utilisation, vous pouvez opter pour une solution comme Argo CD.Argo CD
Argo CD est dans la même lignée que Flux, soit un opérateur Kubernetes synchronisant des manifests stockés sur un dépôt Git. Il s’inscrit lui aussi dans la stratégie pull. Argo CD propose à la fois un client web et un client lourd sur lesquels vous pouvez créer et suivre les ressources. Il supporte plusieurs applications qui sont en fait un regroupement de manifests stockés dans un dépôt git. Il n’est donc pas soumis aux mêmes limitations que Flux. Il supporte lui aussi les alertes via des jobs créés lors de certains événements. Il existe notamment un événement en cas d’échec de synchronisation (SyncFail) et en cas de réussite (PostSync). Comme Argo CD stocke les déploiements d’applications via des CRD, il est possible d’intégrer ses manifests dans un processus GitOps.Argo Flux
Argo Flux est un projet assez récent annoncé juste avant la KubeCon US 2019 de novembre dernier. Son ambition est de fusionner les projets Argo CD et Flux. Le développement et les releases régulières sur les projets Flux et Argo CD restent, au moins pour l’instant, d’actualité. AWS, Intuit et Weave ont annoncé conjointement ce projet et leur participation à son développement. Il n’en est encore qu’à un stade précoce. Vous pouvez retrouver les avancements du projet sur le dépôt du Gitops Engine à l’adresse https://github.com/argoproj/ gitops-engine/Buildbot
Buildbot (https://buildbot.net/) est une infrastructure d’intégration continue offrant une assez grande flexibilité. Initialement publié en 2003 comme alternative au projet Tinderbox de Mozilla, Buildbot a été conçu principalement comme un moyen d’automatiser les tests de build sur un large éventail de plates-formes. Buildbot est publié sous licence GPL et écrit en Python à l’aide de la bibliothèque Twisted. La configuration de Buildbot se fait directement en Python. La configuration est, du coup, un peu plus complexe à mettre en place qu’avec d’autres systèmes, mais elle peut ainsi être plus détaillée et puissante. Les étapes du build sont clairement différenciées et programmables. Buildbot est un framework qui offre des outils de création afin de définir vos propres processus personnalisés. Buildbot prend en charge de nombreux systèmes d’exploitation et systèmes de contrôle de version. Son architecture ouverte permet de se «coller» à d’autres plates-formes et d’élargir la base de tests disponible. Il suffit pour cela d’installer quelques packages Python sur le système et de renseigner les informations d’identification au projet.
Le CNCF (Cloud Native Computing Foundation) construit des cosystèmes durables et favorise les communautés afin de favoriser la croissance et la bonne santé des logiciels open source «cloud native»
Drone
Drone est une plate-forme CI/CD avec une architecture basée sur les containers. Même si les outils décrits précédemment incluent tous la possibilité d’utiliser Docker, Drone a été spécialement conçu pour être utilisé avec des containers. Écrit en Go, il a été initialement publié en 2014 sous licence Apache et se comporte un peu comme une couche intermédiaire de coordination entre Docker et un fournisseur de référentiel. Au lieu de devoir démarrer le serveur CI/CD et de se connecter ensuite à un service d’hébergement de système de contrôle de version, Drone utilise les informations du compte de référentiel afin d’initialiser ses propres modèles d’authentification, d’utilisateur et de permissions. Il est lui-même exécuté en tant que conteneur, comme ses processus CI. Drone est compatible avec plusieurs serveurs de bases de données et fournisseurs de référentiels et offre un support intégré pour la configuration de certificats TLS/SSL avec Let’s Encrypt pour le cryptage de transport. Drone recherche des fichiers YAML particuliers dans les référentiels pour définir le pipeline. Sa syntaxe est plutôt facile à lire et assez explicite pour que toute personne utilisant le référentiel puisse comprendre le processus d’intégration continue. Son système de plug-in est très différent de celui de Jenkins. Les plug-ins de Drone sont des containers Docker spécifiques employés pour déposer des tâches préconfigurées dans le flux de travail standard. Cela simplifie la réalisation des tâches les plus courantes en appelant le plug-in avec quelques paramètres, plutôt que de scripter manuellement tout le processus. Les plugins Drone ressemblent un peu aux commandes d’utilitaires Unix/Linux (tels Ansible, Chef ou Puppet) qui sont conçues pour réaliser correctement une tâche très ciblée.Travis CI
Travis CI est un système de type SaaS (Software as a Service). Ses pipelines sont stockés sous forme de fichier YAML avec le code source. Travis s’intègre parfaitement à d’autres outils comme GitHub ou Gitlab. Son temps de disponibilité est très élevé. Vous pouvez l’utiliser aussi bien en tant que SaaS qu’en version hébergée. Travis comporte de nombreux composants, il est difficile de tous les installer. Il est plus facile de les déployer sur Kubernetes avec les charts Helm fournis par Travis CI (https://github. com/travis-ci/kubernetes-config). Cependant, si vous développez du code open source, vous pouvez aussi utiliser gratuitement la version SaaS de Travis CI qui offre un excellent service. Utilisé de pair avec GitHub, ce dernier va informer Travis CI de toute modification apportée dans le dépôt, ce qui permet de maintenir le projet à jour en permanence. En résumé, Travis CI est open source sous licence MIT, programmé en Ruby, fonctionne sur toutes les plates-formes système, se marie très bien avec GitHub et Jenkins, se configure – un de plus – à l’aide d’un fichier YAML, est gratuit pour les projets open source et coûte, pour les projets commerciaux, de 69 à 489 $ par mois.Concourse
La plate-forme d’intégration continue Concourse (https://concourse-ci. org/) a été initialement publiée en 2014. L’approche de Concourse vis-àvis de l’espace CI/CD est un peu particulière par rapport aux autres outils du genre. Sa technique consiste à rendre le serveur d’intégration entièrement disponible, de sorte que les mêmes processus puissent facilement être exécutés sur n’importe quel serveur Concourse. Chaque partie du processus d’intégration continue est composée de primitives de base qui modélisent différents éléments du système, en définissant ses dépendances de manière explicite. Par exemple, la première tâche peut nécessiter la dernière validation dans un référentiel VCS, tandis que les parties suivantes du processus pourront nécessiter la dernière validation ayant passé les précédentes étapes. Cette méthode de construction de pipelines en mappant les dépendances exactes de chaque étape conduit à un comportement strictement défini. Pour éviter au maximum les incidents pendant l’exécution du processus, Concourse ne transmet rien implicitement entre les travaux et ne fournit aucun moyen interne de stockage des artefacts de construction. Toutes les informations nécessaires à la prochaine étape doivent être explicitement définies et éventuellement transférées vers un magasin externe pour pouvoir être extraites à l’étape suivante. En exigeant des définitions explicites, Concourse minimise le nombre d’hypothèses et de variables inconnues que le système doit prendre en compte. Pour arriver à ce résultat, le système est constitué de microservices et chaque tâche s’exécute dans un conteneur. Concourse dispose également d’un système d’extension simple qui repose sur le concept fondamental des ressources. Chaque nouvelle fonctionnalité que vous souhaitez fournir à votre pipeline peut être implémentée dans une image Docker et incluse en tant que nouveau type de ressource dans votre configuration. Concourse est écrit en Go et publié sous licence Apache.Spinnaker
Spinnaker est l’outil créé et utilisé par Netflix. Il est plutôt axé sur le CD que sur le CI mais peut aisément s’intégrer à d’autres outils tels que Travis et Jenkins pour lancer les pipelines de test et de déploiement. Spinnaker intègre également des outils de surveillance tels que Prometheus et Datadog facilitant les décisions sur les déploiements en fonction des métriques fournies par ces systèmes. Le déploiement canari, par exemple, utilise un concept de « poids». Les métriques collectées vont permettre de déterminer si le dernier déploiement canari a provoqué une dégradation des métriques telle qu’elle doit être annulée ou si le déploiement peut se poursuivre. Spinnaker possède quelques fonctionnalités particulières en matière de déploiement qui couvrent des aspects parfois négligés par les autres outils. Il aide par exemple à empêcher une étape de s’exécuter à certains moments afin qu’un déploiement ne puisse se produire pendant une période critique du cycle de vie de l’application. Spinnaker permet aussi d’appliquer des approbations manuelles en vue de s’assurer que la version sera produite au moment le plus opportun.Bamboo
Bamboo, de Atlassian, fonctionne avec de nombreuses autres applications et technologies. Il est distribué depuis 2007 par la société Atlassian, qui propose également aujourd’hui le service d’hébergement de fichiers Bitbucket. À l’instar de Jenkins, Bamboo assiste les développeurs dans l’intégration mais offre également des fonctionnalités pour le déploiement et la gestion des versions. Il s’utilise via une interface en ligne assez simple et intuitive. Bamboo est codé en Java, fonctionne sur toutes les plates-formes, profite comme de bien entendu d’une intégration simple avec les autres produits Atlassian et possède une grande quantité d’extensions. Plusieurs tests peuvent être réalisés et en simultané. La communication se fait via une interface web et une API REST. Il est gratuit pour les projets open source, les organisations à but non lucratif et les classes scolaires. Pour toute autre utilisation, son coût (unique, et non mensuel) varie entre 10 $ et 110000 $, selon le nombre de serveurs utilisés.
TeamCity séduit avant tout par ses gated commits qui permettent de tester les modifications apportées au code avant même leur intégration au projet global.
TeamCity
Le logiciel TeamCity (https://www.jetbrains.com/teamcity/) séduit avant tout par ses gated commits qui permettent de tester les modifications apportées au code avant même qu’elles ne soient insérées dans la mainline. Le code source est intégré au code de base pour toute l’équipe uniquement lorsqu’il est jugé totalement exempt d’erreur. TeamCity effectue les tests de façon autonome en arrière-plan de telle sorte que les développeurs peuvent poursuivre leur travail dans l’intervalle. Programmé en Java, il fonctionne sur toutes les plates-formes. Il est gratuit pour 100 builds avec (3 agents de build), sinon son coût direct évolue entre 299 et 21999 €. Il est également gratuit pour les projets open source.
Introduction au GitOps
Le principe du GitOps rejoint celui de l’infrastructure as code mais avec des contraintes clairement définies permettant de garantir les «bonnes pratiques». L’infrastructure as code et de ce fait le GitOps reposent en grande partie sur la formalisation sous forme déclarative de l’infrastructure. Cela se traduit concrètement par l’usage d’outils tels qu’Ansible, Chef/Puppet, Terraform, PowerShell DSC, Salt et, bien sûr, Kubernetes. Tout changement doit être décrit de manière déclarative via un outil de provisionnement ou de déploiement. Ce point est décrit dans le 10e point des 12 factor (https://12factor.net/ dev-prod-parity). Comme son nom peut le laisser penser, GitOps se base sur Git. Néanmoins, d’autres outils de versionning peuvent être employés à la place de Git. L’aspect central du GitOps repose sur le fait de considérer que notre dépôt Git est notre unique source de vérité. La notion de convergence est également un point important du GitOps. Comme le dépôt git contient le code de la dernière release, il faut faire converger les déploiements en fonction de ce qui est décrit dans git. Cela passe notamment par de la supervision active de l’infrastructure et le reporting détaillé des différences constatées.
Environnements de test à la demande
Le fait d’exécuter des tests dans des containers permet de réduire le nombre de variables dans l’environnement et de changements entre les environnements de développement et de production. Les environnements de test éphémères rendent votre cycle CI/CD plus agile. Au lieu de sans arrêt extraire un build d’un serveur CI pour l’installer dans un environnement de test séparé, l’équipe d’assurance qualité peut exécuter les tests sur une image de container. Il est beaucoup plus simple de monter des containers, sans contraintes d’installation ou de configuration séparées, et de les détruire une fois qu’ils ne sont plus utiles. Les pratiques CI/CD peuvent également et même doivent s’appliquer à l’infrastructure et aux applications tierces.Les bonnes pratiques Git
Les bonnes pratiques conseillent de décrire tous les environnements dans la branche principale. Ainsi, vous devrez modifier tous vos environnements en même temps et n’aurez plus à maintenir un environnement spécifique. Cela n’interdit pas pour autant de créer d’autres branches pour vos nouvelles fonctionnalités. Vous pouvez bien entendu appliquer des workflows tels que le Git Flow, le Github Flow, le GitLab Flow ou autre. Il est possible d’utiliser l’outil Kustomize pour faire cela sur Kubernetes. Natif à kubectl, il propose un système d’overlay. Vous décrivez avec votre base les patchs à appliquer. Un overlay listant différents patchs pour passer de la base commune aux spécificités d’un environnement sera généralement décrit.GoCD
GoCD est distribué sous licence Apache 2.0. Il a été créé par les experts de Thoughtworks. Son principal avantage par rapport à ses concurrents tient dans sa fonction VSM (Value Stream Map) grâce à laquelle les pipelines peuvent être enchaînés avec un pipeline qui fournit le matériel nécessaire pour le pipeline suivant. Cela conduit à une indépendance plus importante pour des équipes distinctes ayant des responsabilités variées dans le processus de déploiement. Le fait que tout le monde utilise le même outil facilitera la recherche des goulots d’étranglement dans le VSM et la réorganisation des équipes pour en accroître l’efficacité. Dans une entreprise, il est très important d’avoir un VSM pour chaque produit. GoCD permet de le décrire en langage JSON ou YAML dans le contrôle de version.Screwdriver
Screwdriver, open source et distribué sous licence BSD, est un outil simple mais très efficace. Il utilise une approche de type microservices en s’appuyant sur des outils tels que Nomad, Kubernetes ou Docker pour servir de moteur d’exécution. Screwdriver propose lui aussi le langage YAML pour ses descriptions de pipeline. Sa configuration décrit un flux de travail avancé avec des dépendances complexes entre les travaux. À titre d’exemple, un travail peut souvent s’exécuter après ou avant un autre travail. Les travaux peuvent s’exécuter en parallèle et être reliés par la suite. Il est aussi possible d’utiliser des opérateurs logiques pour déclencher un travail.Circle CI
L’outil d’intégration continue CircleCI fonctionne parfaitement avec GitHub et Bitbucket. Un conteneur ou une machine virtuelle peuvent être utilisés pour la phase de test. CircleCI accorde une grande importance à des processus de développement fluides, sans heurts, ce qui permet de mettre automatiquement à disposition des builds exempts d’erreur pour d’autres environnements. Circle se configure via un fichier YAML. Il supporte également le déploiement continu. Auto-hébergement et hébergement sur le Cloud sont disponibles. Il fonctionne dans des conteneurs Docker, sous Linux VMs et MacOS VM. Son utilisation est gratuite avec des containers, et son coût est compris entre 50 et 3150 $ par mois.Codeship
L’outil IC C odeship appartient aujourd’hui à CloudBee (encore…). Ce programme est disponible en deux versions. La version de base offre une interface web facile d’utilisation, alors que la version pro est configurée à l’aide de fichiers dans le dépôt. Les développeurs souhaitant travailler avec un conteneur Docker devront opter pour la version pro. Dans la version de base, il s’utilise via une interface web. Il est gratuit pour 100 builds par mois s’il est employé uniquement comme pipeline de testing. Autrement, son coût est compris entre 75 et 1500 $ par mois.CruiseControl
Le logiciel open source CruiseControl (http://cruisecontrol.sourceforge.net) fait partie des plus anciennes applications proposant une intégration continue. Cet outil a été introduit sur le marché dès 2001 et a été constamment amélioré depuis, notamment par Martin Fowler qui est l’un des pionniers dans le domaine de l’intégration continue. Outre un tableau de bord clair, les développeurs disposent également de nombreux plugins facilitant leur travail. Il est gratuit et open source (sous licence BSD), programmé en Java, fonctionne sur toutes les plates-formes, offre un tableau de bord basé sur le Web ainsi que des versions pour Ruby (CruiseControl.rb) et .NET (CruiseControl.NET).
Cet article est paru dans le magazine L'Informaticien n°189 (septembre 2020).