Comparaison des outils CI / CD: Jenkins, GitLab CI, Buildbot, Drone et Concourse – Avis Drones, test et guide d’achat

Dans un précédent
article
, nous avons introduit l'intégration, la livraison et le
déploiement continu comme des stratégies appliquées pour accélérer la
vitesse de développement et de publication des produits utilisables et
éprouvés. L'intégration continue d'encourager les équipes de développement à
tester et intégrer leurs modifications à une base de code partagée 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 publication. Le déploiement continu va encore plus loin en déployant
automatiquement chaque build qui passe la suite de tests.

Alors 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 atteintes ces objectifs. Le logiciel CI
/ CD peut aider les équipes à faire avancer de nouveaux changements à
traverser une série d'étapes automatiquement afin de réduire le temps de
réaction et d'éliminer les frictions du processus.

Dans ce nouvel article, nous allons comparer certains serveurs
d'intégration, de livraison et de déploiement continus gratuits et
pen-source conçu pour faciliter le développement de logiciels
collaboratifs. Nous allons jeter un oeil à Jenkins, GitLab CI, Buildbot,
Drone et Concourse.

Jenkins est l'un des
premiers serveurs d'intégration continuent open-source et reste l'option la
plus utilisées aujourd'hui. À l'origine partie du projet Hudson,
la communauté et la base de code se sont scindées suite aux conflits entre
Oracle et les développeurs d'origine après avoir obtenu de la marque par
Sun Microsystems. Hudson a été récemment publié en 2005, tandis que la
première version de Jenkins a été faite en 2011.

Au fil des années, Jenkins est devenu 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 mise en œuvre à travers une bibliothèque de plugins.
Tout, de l'écoute de hooks web à la visualisation de référentiels en
passant par le développement d'environnements et de langues, est géré par
des plugins. Bien que cela offre une grande flexibilité, votre processus
CI peut s'appuyer sur de nombreux plugins tiers, qui peuvent être
fragiles.

Le flux de production de Jenkins – également fourni via un plugin –
est un ajout relativement nouveau, disponible depuis 2016. Le processus CI
peut être défini de manière déclarative ou impérative en utilisant le
langage Groovy dans les fichiers du référentiel lui-même ou via les zones
de texte du site Jenkins. UI. Une critique courante de Jenkins est que le
modèle de configuration centré sur le plugin et la capacité à définir des
processus de pipeline ou de construction 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 licence MIT.

GitLab
CI
est un outil d'intégration continue intégré à GitLab, une plateforme d'outils
hébergement et de développement de référentiel git. Initialement publié
en tant que projet autonome, GitLab CI a été intégré dans le logiciel
GitLab principal 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 en utilisant une syntaxe de configuration
YAML. Le travail est ensuite envoyé à des machines appelées coureurs,
faciles à configurer et pouvant être mises en service sur de nombreux
systèmes d'exploitation différents. Lorsque vous configurez des coureurs,
vous pouvez choisir entre différents exécuteurs comme Docker, shell,
VirtualBox ou Kubernetes pour déterminer comment les tâches sont
exécutées.

Le couplage étroit de GitLab CI avec la plaque-forme de stockage
GitLab a des implications précises sur la façon dont le logiciel peut être
utiliser. GitLab CI n'est pas une option pour les développeurs qui
utilisent d'autres plateformes d'hébergement de référentiel. Du côté
positif, la fonctionnalité intégrée permet aux utilisateurs de GitLab de
configurer un environnement CI / CD sans installer et apprendre un outil
supplémentaire. Les tests automatisés peuvent commencer en activant
quelques options dans l'interface Web, en enregistrant une machine de
coureur et en ayant un fichier de définition de pipeline dans le
référentiel. La relation étroite vous permet également de partager des
coureurs entre des projets, de voir automatiquement l'état actuel de la
construction 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 et Go et publiés sous
licence MIT.

Buildbot est un framework d'intégration
continuer qui offre énormément de flexibilité. Publié en 2003 comme une
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é avec des licences GPL et écrit en Python à
l'aide de la bibliothèque Twisted. Plutôt que d'abstraire 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 beaucoup plus complexe que les autres systèmes, mais les
administrateurs ont plus de latitude pour envisager leur flux de travail
et processus 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, comparables à
la façon dont les frameworks Web vous permet de créer des sites
personnalisés.

L'historique de Buildbot en tant que plate-forme de test de build
signifie qu'il prend en charge de nombreux systèmes d'exploitation et
systèmes de contrôle de version différents. De même, parce qu'il a été
conçu en tenant compte des tests open source, son architecture permet aux
utilisateurs de soumettre facilement des travailleurs avec leurs
plates-formes préférées à des projets pour étendre la base de test
disponible. L'utilisateur n'a besoin que de quelques paquets
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 sur la façon d'installer Buildbot sur
Ubuntu 16.04.

Drone est une plate-forme
moderne CI / CD construit avec une architecture de conteneurs d'abord.
Bien que les outils décrits ci-dessus publiés tous la possibilité
d'exécuter des builds avec Docker, un workflow basé sur conteneur est au
cœur de la conception de Drone. Drone est écrit en Go et a été publié en
2014 sous une licence Apache.

Drone agit comme une couche de coordination intermédiaire 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 du système
de contrôle de version, Drone requiert les informations de compte du
référentiel pour amorcer ses propres modèles d'authentification,
d'utilisateur et d'autorisations. Comme avec tous ses processus 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érentiel et prend en
charger la configuration de certificats TLS / SSL avec Let's Encrypt pour
le chiffrement de transport.

Drone recherche des fichiers YAML spécial dans des référentiels
pour la définition du pipeline. La syntaxe est conçue pour être facile à
lire et à exprimer afin que quiconque utilise le référentiel pourrait
comprendre le processus d'intégration continuer. Drone fournit un système
de plugin, mais il est utilisé différemment de celui de Jenkins. Dans
Drone, les plugins sont des conteneurs Docker spéciaux utilisés pour
déposer des tâches préconfigurées dans le flux de travail normal. Cela
facilite l'accomplissement des tâches courantes en appelant le plugin avec
quelques paramètres plutôt que scriptant l'ensemble du processus
manuellement. En ce sens, les plugins Drone sont quelque peu similaires
aux commandes d'utilitaires Unix visé pour exécuter une tâche
ciblée.

Concourse est une
plate-forme d'intégration continuez relativement nouvelle récemment
lancée en 2014. L'approche de Concourse à l'espace CI / CD est
significativement différent des autres outils que nous avons examinés en
essayant de se sortir de l'équation autant que possible, en minimisant
énoncer et abstraire chaque facteur externe en quelque chose qu'il a appelé
«Ressources». Le but de cette philosophie est de rendre le serveur
d'intégration entièrement disponible pour que les mêmes processus
être facilement 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 explicitement ses dépendances.
Par exemple, la première tâche peut nécessiter la dernière validation dans
un référentiel VCS, tandis que des parties ultérieures du processus
peuvent nécessiter le dernier commit ayant passé les étapes précédentes.
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
transfère implicitement rien entre les travaux et ne fournit aucun moyen
interne de stockage des artefacts de construction. Toutes les informations
nécessaires à l'étape suivante doivent être explicitement définis et
potentiellement envoyés à un magasin externe pour être intégrés à
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.

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, mettant l'accent sur différentes parties de l'équation.
Aucun outil ne répondra aux besoins de chaque projet, mais avec autant de
solutions open source de haute qualité disponibles, il y a de fortes
chances que vous soyez trouver un système qui réponde aux besoins de
votre équipe.

Nous serions ravis de connaître votre avis

      Laisser un commentaire