Comparaison des outils CI / CD: Jenkins, CI GitLab, Buildbot, Drone et Concourse

LesContinuous integration, delivery, and deployment sont des stratégies conçues pour aider à augmenter la vitesse de développement et la sortie de produits bien testés et utilisables. L'intégration continue encourage les équipes de développement à tester et à intégrer leurs modifications à une base de code partagée à un stade précoce afin de minimiser les conflits d'intégration. La livraison continue s'appuie sur cette base en supprimant les obstacles sur le chemin du déploiement ou de la libération. Le déploiement continu va encore plus loin en déployant chaque version qui passe automatiquement la suite de tests.

Bien que la terminologie ci-dessus concerne principalement les stratégies et les pratiques, l’outillage logiciel joue un rôle important en permettant aux organisations d’atteindre ces objectifs. CI/CD software can help teams advance new changes through a series of stages automatically to reduce the time to feedback and remove friction from the process.

Dans ce guide, nous allons comparer des serveurs d’intégration, de distribution et de déploiement continus populaires, gratuits et à code source ouvert, conçus pour faciliter le développement de logiciels en collaboration. Nous allons examiner Jenkins, GitLab CI, Buildbot, Drone et Concourse.

Jenkins est l'un des premiers serveurs d'intégration continue open source et reste l'option la plus couramment utilisée aujourd'hui. Faisant initialement partie du projetHudson, la communauté et la base de code se sont séparées suite à des conflits de marques avec Oracle après l'acquisition de Sun Microsystems, les développeurs d'origine. Hudson a été initialement publié en 2005, tandis que la première sortie sous le nom de Jenkins a été réalisée 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 lui-même sert principalement de cadre d'automatisation avec une grande partie de la logique importante implémentée via une bibliothèque de plugins. Tout, depuis l'écoute de points d'ancrage Web ou l'observation de référentiels jusqu'à la création d'environnements de construction et de prise en charge linguistique est géré par des plugins. Bien que cela offre une grande flexibilité, votre processus de CI peut s’appuyer sur de nombreux plugins tiers, ce qui peut être fragile.

Le workflow du pipeline de Jenkins - également fourni via un plugin - est un ajout relativement nouveau, disponible à partir de 2016. Le processus CI peut être défini de manière déclarative ou impérative à l'aide desGroovy language dans les fichiers du référentiel lui-même ou via des zones de texte dans l'interface utilisateur Web de Jenkins. Une critique courante de Jenkins est que le modèle de configuration centré sur le plugin et la possibilité de définir des processus de construction ou de pipeline en dehors des référentiels peuvent parfois rendre difficile la réplication facile d'une configuration sur une instance Jenkins différente.

Jenkins est écrit en Java et publié sous une licence MIT. Suivez notre guide surhow to install Jenkins on Ubuntu 16.04 pour configurer un serveur Jenkins pour votre projet.

GitLab CI est un outil d'intégration continue intégré àGitLab, une plateforme d'outils d'hébergement et de développement de référentiels git. Initialement publié en tant que projet autonome, GitLab CI a été intégré au logiciel principal GitLab avec la sortie de GitLab 8.0 en septembre 2015.

Le processus CI / CD dans GitLab CI est défini dans un fichier du référentiel de code lui-même à l'aide d'une syntaxe de configuration YAML. Le travail est ensuite envoyé aux machines appelées coureurs, qui sont faciles à configurer et peuvent être provisionnées sur de nombreux systèmes d'exploitation. Lors de la configuration des coureurs, vous pouvez choisir entre différents exécutants tels que Docker, shell, VirtualBox ou Kubernetes pour déterminer le mode d'exécution des tâches.

Le couplage étroit de GitLab CI avec la plate-forme de référentiel GitLab a des implications précises sur la manière dont le logiciel peut être utilisé. GitLab CI n'est pas une option pour les développeurs qui utilisent d'autres plateformes d'hébergement de référentiels. Du côté positif, la fonctionnalité intégrée permet aux utilisateurs de GitLab de configurer un environnement CI / CD sans installer ni apprendre un outil supplémentaire. Les tests automatisés peuvent commencer par activer quelques options dans l'interface Web, en enregistrant une machine d'exécution et en ajoutant un fichier de définition de pipeline dans le référentiel. La relation de proximité vous permet également de partager les coureurs entre les projets, de voir automatiquement l'état de la construction actuelle dans le référentiel et de conserver les artefacts de construction avec le code qui les a produits.

GitLab et GitLab CI sont écrits en Ruby and Go et publiés sous une licence MIT. Vous pouvez suivre notre guide surhow to set up continuous integration pipelines with GitLab CI pour savoir comment configurer cette fonctionnalité sur votre serveur GitLab.

Buildbot est un cadre d'intégration continue qui offre une énorme 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 construction sur un large éventail de plates-formes.

Buildbot est publié sous licence GPL et écrit en Python à l'aide de la bibliothèque Twisted. Plutôt que d’abréger le langage sous-jacent pour simplifier la configuration, la configuration de Buildbot est entièrement écrite en Python. Cela signifie que la configuration a tendance à être nettement plus complexe que les autres systèmes, mais les administrateurs ont davantage de marge de manœuvre pour concevoir leur processus et leur flux de travail idéaux. Chaque étape de la construction est clairement séparée et programmable. Buildbot se positionne comme un framework avec des outils pour créer vos propres processus personnalisés, comparable à la manière dont les frameworks Web vous permettent de créer des sites personnalisés.

L’historique de Buildbot en tant que plate-forme de test de construction signifie qu’elle prend en charge de nombreux systèmes d’exploitation et systèmes de contrôle de version. De même, comme elle a été conçue pour les tests en source ouverte, son architecture permet aux utilisateurs de facilement soumettre des travailleurs dotés de leurs plates-formes préférées à des projets afin d'élargir la base de tests disponible. L'utilisateur doit uniquement installer quelques packages Python sur le système, puis fournir les informations d'identification au projet.

Pour commencer à utiliser Buildbot pour automatiser vos processus de construction, suivez notre guide surhow to install Buildbot on Ubuntu 16.04.

Drone est une plate-forme CI / CD moderne construite avec une architecture axée sur les conteneurs. Bien que les outils décrits ci-dessus incluent tous la possibilité d’exécuter des versions avec Docker, un flux de travail basé sur des conteneurs est au cœur de la conception de Drone. Drone est écrit en Go et a été publié pour la première fois en 2014 sous une licence Apache.

Drone agit en tant que couche intermédiaire de coordination entre Docker et un fournisseur de référentiel. Plutôt que de 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 a besoin des informations de compte du référentiel pour initialiser ses propres modèles d'authentification, d'utilisateur et de permissions. Comme pour tous ses processus de CI, Drone lui-même est exécuté en tant que conteneur. Il prend en charge plusieurs backends de base de données et fournisseurs de référentiels et prend en charge la configuration de certificats TLS / SSL avecLet’s Encrypt pour le chiffrement du transport.

Drone recherche des fichiers YAML spéciaux dans les référentiels pour la définition du pipeline. La syntaxe est conçue pour être facile à lire et expressive afin que toute personne utilisant le référentiel puisse comprendre le processus d'intégration continue. Drone fournit un système de plug-in, mais il est utilisé différemment de celui de Jenkins. Dans Drone, les plug-ins sont des conteneurs Docker spéciaux utilisés pour déposer des tâches préconfigurées dans le flux de travail standard. Cela facilite l'accomplissement des tâches courantes en appelant le plug-in avec quelques paramètres plutôt que de scripter manuellement le processus entier. En ce sens, les plugins Drone ressemblent un peu aux commandes d’utilitaire Unix qui sont conçues pour effectuer correctement une tâche très ciblée.

Pour savoir comment configurer un serveur Drone pour tester automatiquement vos commits, suivez notre guidehow to install and configure Drone on Ubuntu 16.04.

Concourse est une plate-forme d'intégration continue relativement nouvelle lancée initialement en 2014. L'approche de Concourse vis-à-vis de l'espace CI / CD est très différente des autres outils que nous avons examinés dans la mesure où elle tente de se sortir autant que possible de l'équation, en minimisant l'état et en faisant la synthèse de chaque facteur externe en une ressource appelée "ressources". . Le but de cette philosophie est de 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 modélisant différents éléments du système. Chaque partie du processus définit ses dépendances explicitement. Par exemple, la première tâche peut nécessiter la dernière validation dans un référentiel VCS tandis que les parties ultérieures du processus peuvent nécessiter la dernière validationthat passed previous stages. Cette méthode de construction de pipelines en mappant les dépendances exactes de chaque étape conduit à un comportement strictement défini.

Pour supprimer davantage l'état incident du processus, Concourse ne transmet implicitement rien 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 espère minimiser le nombre d'hypothèses et de variables inconnues que le système doit prendre en compte.

Concourse est écrit en Go et publié sous licence Apache. Si vous souhaitez apprendre à configurer un serveur Concourse pour automatiser vos processus d'intégration continue, consultez notre guide surhow to install Concourse CI on Ubuntu 16.04.

Les logiciels d'intégration, de livraison et de déploiement continus sont des systèmes d'automatisation complexes conçus pour rendre vos processus fiables et reproductibles. Comme vous pouvez le constater à partir des descriptions ci-dessus, il existe de nombreuses idées différentes sur la meilleure façon de réaliser les tests et les versions automatisés, l'accent étant mis sur différentes parties de l'équation. Aucun outil ne peut satisfaire les besoins de chaque projet, mais avec autant de solutions open source de haute qualité disponibles, vous aurez de bonnes chances de trouver un système répondant aux besoins de votre équipe.