outils ci cd

7 outils CI/CD pour les administrateurs système

Mis à jours 1 février 2020

Un guide simple sur les meilleurs outils d’intégration continue, de livraison continue et de déploiement continu open source.

L’intégration continue, la livraison continue et le déploiement continu (CI/CD) existent tous dans la communauté des développeurs depuis de nombreuses années.

Certaines entreprises ont impliqué leurs homologues des opérations, mais beaucoup ne l’ont pas fait. Pour la plupart des entreprises, il est impératif que leurs équipes opérationnelles se familiarisent avec les outils et les pratiques CI/CD autant que leurs développeurs.

Les pratiques CI/CD peuvent également s’appliquer à l’infrastructure et aux applications tierces, et aux applications développées en interne.

Puis, il existe de nombreux outils différents, mais tous utilisent des modèles similaires. Et peut-être plus important encore, conduire votre entreprise dans cette nouvelle pratique vous mettra en position de force au sein de votre secteur, et vous deviendrez un modèle à suivre pour les autres.

Les anciens outils utilisés

Certaines entreprises utilisent des pratiques CI/CD sur l’infrastructure, avec des outils comme Ansible, Chef ou Puppet, depuis plusieurs années.

D’autres outils, comme Test Kitchen, permettent d’effectuer des tests sur une infrastructure qui hébergera éventuellement des applications. En fait, ces tests peuvent même déployer l’application dans un environnement de production. De plus, il permet d’exécuter des tests au niveau de l’application avec des charges de production dans des configurations plus avancées.

Cependant, le simple fait de pouvoir tester l’infrastructure individuellement est un énorme exploit. Terraform peut également utiliser Test Kitchen pour des configurations d’infrastructure encore plus éphémères et idempotentes que certains des outils de gestion de configuration d’origine.

Ajoutez des conteneurs Linux et Kubernetes, et vous pouvez désormais tester l’infrastructure complète et les déploiements d’applications avec des spécifications et des ressources de production qui vont se succéder en heures qu’en mois ou années. En effet, tout est supprimé avant d’être déployé et testé à nouveau.

L’introduction des pipelines CI/CD

outils CI/CD

Vous pouvez aussi vous concentrer sur l’obtention de vos configurations réseau ou fichiers DDL (Database Data Definition Language) dans le contrôle de version.

Il est aussi possible de commencer à exécuter de petits pipelines CI/CD. Peut-être que cela vérifie simplement la syntaxe ou la sémantique ou certaines des meilleures pratiques. En fait, c’est ainsi que la plupart des pipelines de développement ont commencé. Une fois que tout sera prêt, il sera plus facile de construire. Puis, vous commencerez à trouver toutes sortes de cas d’utilisation pour les pipelines une fois que vous aurez commencé.

Exemple d’utilisation des pipelines CI/CD

A titre d’exemple, j’écris régulièrement une newsletter au sein de mon entreprise. Je la maintiens le contrôle de version en utilisant MJML.

J’avais besoin d’héberger une version Web, et certaines personnes souhaiteraient obtenir un PDF. Alors, j’ai construit un pipeline.

Maintenant, lorsque je crée une nouvelle newsletter, je la soumets pour une demande de fusion sur GitLab. Cela crée automatiquement un index.html avec des liens vers les versions HTML et PDF de la newsletter.

Les fichiers HTML et PDF sont également créés dans le pipeline. Rien de tout cela n’est publié jusqu’à ce que quelqu’un vienne et examine ces artefacts.

Ensuite, GitLab Pages publie le site Web et je peux dérouler le HTML pour l’envoyer en tant que newsletter. À l’avenir, j’enverrai automatiquement la newsletter lorsque la demande de fusion est fusionnée ou après une étape d’approbation spéciale. Cela paraît simple, mais m’a fait gagner beaucoup de temps.

C’est exactement ce que ces outils peuvent faire pour vous. Ils vous feront gagner du temps.

Peu de ligne code à écrire

Quoi qu’il en soit, l’essentiel est de créer des outils pour travailler dans l’abstrait afin qu’ils puissent s’appliquer à plusieurs problèmes avec peu de modifications.

Je dois également noter que ce que j’ai créé ne nécessite presque pas de code, à l’exception de quelques modèles HTML légers, d’un nœud pour parcourir les fichiers HTML et d’un nœud supplémentaire pour remplir la page d’index avec toutes les pages HTML et PDF.

Implication d’autres développeurs

Certains de ces outils peuvent être un peu complexes. Cela dit, la plupart proviennent des tutoriels des différents outils que j’utilise.

Puis, de nombreux développeurs sont heureux de travailler avec vous sur ce type d’outils, car cela peut les rendre utiles.

Les liens que j’ai fournis sont vers une newsletter que nous prévoyons de créer pour DevOps KC, et tout le code pour créer le site provient du travail que j’ai fait sur notre newsletter interne.

outils d'intégration, déploiement et livraison continus

De nombreux outils mentionnés ci-dessous peuvent offrir ce type d’interaction. Cependant, quelques-uns proposent un modèle légèrement différent.

Le nouveau modèle est celui d’une description déclarative d’un pipeline dans quelque chose comme YAML, dont chaque étape est éphémère et idempotente.

Beaucoup de ces systèmes assurent également un séquençage correct. Ils créent un graphe acyclique dirigé (DAG) sur les différentes étapes du pipeline.

Conteneurs Linux

Ces étapes sont souvent exécutées dans des conteneurs Linux. Elles peuvent faire tout ce que vous pouvez faire dans un conteneur.

Certains outils, comme Spinnaker, se concentrent uniquement sur le composant de déploiement. Ils offrent également des fonctionnalités opérationnelles que d’autres ne possèdent pas normalement.

En général, Jenkins a conservé les pipelines au format XML et la plupart des interactions se produisent au sein de l’interface graphique. Cependant, les implémentations plus récentes ont utilisé un langage spécifique au domaine (DSL) à partir de Groovy.

De plus, les travaux Jenkins s’exécutent normalement sur des nœuds avec un agent Java spécial installé et consistent en un mélange de plugins et de composants préinstallés.

Jenkins a introduit des pipelines dans son outil. Ils étaient un peu difficiles à utiliser et contenaient plusieurs mises en garde. Récemment, le créateur de Jenkins a décidé de déplacer la communauté vers deux initiatives différentes.

Ces dernières donneront une nouvelle vie au projet, celle qui a apporté le CI/CD au public. Je pense que son initiative la plus intéressante est la création d’un Cloud Native Jenkins. Celui-ci peut transformer un cluster Kubernetes en une plate-forme Jenkins CI/CD.

Un bon moyen pour améliorer la productivité

Au fur et à mesure que vous apprendrez davantage sur ces outils et que vous commencerez à intégrer ces pratiques dans votre entreprise ou le département des opérations, vous gagnerez rapidement des followers. Vous augmenterez votre propre productivité ainsi que celle des autres départements.

Nous avons tous en effet des années de retard à rattraper. A quel point vos collègues souhaiteraient-ils que vous leur donniez suffisamment de temps pour commencer à rattraper ce retard ?

Puis, vos clients vont commencer à voir une fiabilité accrue des applications. Votre direction vous considérera comme un multiplicateur de force. Cela vous aidera sans doute à négocier votre prochaine augmentation salariale ou vous servira lors d’un entretien avec toutes vos nouvelles compétences.

Nous allons maintenant découvrir 7 outils CI/CD.

1. GitLab CI

  • Page du projet
  • Code source
  • Licence : MIT
GitLab CI

GitLab est nouveau dans le domaine CI/CD. Pourtant, il occupe déjà la première place du Forrester Wave pour les outils d’intégration continue. C’est une énorme réussite dans un domaine aussi bondé et hautement qualifié.

Pourquoi GitLab est le meilleur ?

Il utilise un fichier YAML pour décrire l’ensemble du pipeline. Il a également une fonctionnalité appelée Auto DevOps qui permet aux projets plus simples d’avoir un pipeline construit automatiquement avec plusieurs tests intégrés.

Ce système utilise des packs de création Herokuish pour déterminer le langage et la manière de créer l’application. Certains langages peuvent également gérer des bases de données.

Cela va vraiment changer la manière de créer de nouvelles applications dès le début du processus de développement et de les déployer en production. Le système a des intégrations natives dans Kubernetes et déploiera automatiquement votre application dans un cluster Kubernetes.

Cela se fait en utilisant l’une des différentes méthodologies de déploiement, comme les déploiements basés sur des pourcentages et les déploiements bleu-vert.

En plus de sa fonctionnalité CI, GitLab offre de nombreuses fonctionnalités complémentaires comme les opérations et la surveillance avec Prometheus déployé automatiquement avec votre application.

Il offre également la gestion de portefeuille et de projet avec GitLab Issues, Epics et Milestones. Puis, cet outil permet de faire les contrôles de sécurité intégrés au pipeline avec les résultats fournis sous forme d’agrégat sur plusieurs projets. Il permet également de modifier le code directement dans GitLab avec WebIDE, qui peut même fournir un aperçu ou exécuter une partie d’un pipeline pour un retour d’informations plus rapide.

2. GoCD

  • Page du projet
  • Code source
  • Licence : Apache 2.0
GoCD

GoCD vient des experts de Thoughtworks. Celui-ci témoigne suffisamment de ses capacités et de son efficacité.

Pour moi, la principale différence de GoCD du reste du pack est sa fonction Value Stream Map (VSM). En fait, les pipelines peuvent être enchaînés avec un pipeline fournissant le « matériel » pour le pipeline suivant.

Cela permet d’avoir une indépendance accrue pour différentes équipes ayant différentes responsabilités dans le processus de déploiement. Cette fonctionnalité peut être utile lors de l’introduction de ce type de système dans des entreprises plus anciennes qui ont l’intention de garder ces équipes séparées.

Cependant, si tout le monde utilise le même outil, cela va plus tard faciliter la recherche des goulots d’étranglement dans le VSM et la réorganisation des équipes ou le travail pour accroître l’efficacité.

Il est extrêmement important d’avoir un VSM pour chaque produit dans une entreprise. GoCD permet de le décrire en JSON ou YAML dans le contrôle de version. Il permet aussi de présenter visuellement toutes les données sur les temps d’attente.

Ce qui rend cet outil encore très important pour une entreprise qui se soucie de sa croissance. Commencez par installer GoCD et cartographiez votre processus avec uniquement des portes d’approbation manuelles. Demandez ensuite à chaque équipe d’utiliser les approbations manuelles pour que vous puissiez commencer à collecter des données sur les endroits où des goulots d’étranglement peuvent exister.

3. Travis CI

  • Page du projet
  • Code source
  • Licence : MIT
Travis CI

Travis CI a été ma première expérience avec un système CI Software as a Service (SaaS), et c’est pas mal. Les pipelines sont stockés sous forme de YAML avec votre code source.

Il s’intègre parfaitement avec des outils comme GitHub. Je ne me souviens pas de la dernière fois où un pipeline a échoué à cause de Travis CI ou de l’intégration.

Travis CI a un temps de disponibilité très élevé. Vous pouvez non seulement l’utiliser en tant que SaaS, mais il a également une version qui peut être hébergée. Je n’ai pas exécuté cette version.

Il y avait beaucoup de composants, et il semblait un peu intimidant de les installer tous. Je suppose qu’il serait beaucoup plus facile de tout déployer sur Kubernetes avec les charts Helm fournis par Travis CI.

Ces charts ne déploient pas encore tout, mais je suis sûr qu’ils vont beaucoup s’élargir dans le futur. Quoi qu’il en soit, la version entreprise peut vous faciliter la tâche.

Cependant, si vous développez du code open source, vous pouvez utiliser gratuitement la version SaaS de Travis CI. Elle offre un excellent service fourni par une équipe géniale ! Cela va beaucoup alléger les frais généraux et vous permet d’utiliser une plateforme assez courante pour développer du code open source sans avoir à exécuter quoi que ce soit.

4. Jenkins

  • Page du projet
  • Code source
  • Licence : MIT
Jenkins

Jenkins est l’original, le vénérable standard de facto en CI/CD. Si vous n’avez pas encore lu « Jenkins: Shifting Gears » de Kohsuke, le créateur de Jenkins et CTO de CloudBees, vous devez le faire.

Cela résume tous mes points de vue sur Jenkins et la communauté de la dernière décennie. Ce livre décrit ce qui était nécessaire depuis plusieurs années.

Je suis heureux que CloudBees prenne la tête de cette transformation. Jenkins sera un peu écrasant pour la plupart des non-développeurs. Il a longtemps été un fardeau pour ses administrateurs. Quoi qu’il en soit, ils doivent fixer certains éléments.

Jenkins Configuration as Code (JCasC) devrait aider à résoudre les problèmes de configuration complexes qui affligent les administrateurs depuis des années.

Cela permettra une configuration sans contact des maîtres Jenkins via un fichier YAML, similaire à d’autres systèmes CI/CD. Jenkins Evergreen permet de rendre ce processus encore plus facile en fournissant des configurations Jenkins prédéfinies basées sur différents cas d’utilisation. Ces distributions devraient être plus faciles à maintenir et à mettre à niveau que la distribution Jenkins normale.

Jenkins 2 a introduit la fonctionnalité de pipeline natif avec deux types de pipelines, dont je parlerai dans une présentation LISA17. Ni l’un ni l’autre n’est aussi facile à naviguer que YAML lorsque vous faites quelque chose de simple. Quoi qu’il en soit, ils sont très agréables pour effectuer des tâches plus complexes.

Jenkins X est la transformation complète de Jenkins. Il sera probablement l’implémentation de Cloud Native Jenkins (ou du moins la chose que la plupart des utilisateurs voient lors de l’utilisation de Cloud Native Jenkins).

Il prend en charge JCasC et Evergreen, et les utilise de manière optimale sur Kubernetes. Ce sont des moments importants pour Jenkins, et je me réjouis de son innovation et de son leadership continu dans ce domaine.

5. Concourse CI

  • Page du projet
  • Code source
  • Licence : Apache 2.0
Concourse CI

J’ai été initié à Concourse par des gens de Pivotal Labs. C’était encore une première version bêta. Il n’y avait pas beaucoup d’outils comme ça à l’époque.

Le système est constitué de microservices et chaque travail s’exécute dans un conteneur. L’une des fonctionnalités les plus utiles que les autres outils ne possèdent pas est la possibilité d’exécuter un travail à partir de votre système local avec vos modifications locales.

Cela signifie que vous pouvez développer localement (si vous avez une connexion au serveur Concourse). Vous pouvez aussi exécuter vos builds comme ils s’exécuteront dans le pipeline de build réel. Puis, vous pouvez réexécuter les builds ayant échoué à partir de votre système local et ajouter des modifications spécifiques pour tester vos correctifs.

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.

Cela maintient toutes les fonctionnalités encapsulées dans un seul artefact immuable qui peut être mis à niveau et modifié indépendamment. Puis, les modifications de rupture ne doivent pas nécessairement modifier toutes vos versions en même temps.

6. Spinnaker

  • Page du projet
  • Code source
  • Licence : Apache 2.0
Spinnaker

Spinnaker vient de Netflix. Il est plutôt axé sur le déploiement continu que sur l’intégration continue. Il peut s’intégrer à d’autres outils, notamment Travis et Jenkins, pour lancer les pipelines de test et de déploiement.

Il intègre également des outils de surveillance tels que Prometheus et Datadog pour prendre des décisions sur les déploiements en fonction des métriques fournies par ces systèmes.

A titre d’exemple, le déploiement canari utilise un concept de juge. Les métriques collectées permettent de déterminer si le dernier déploiement canari a provoqué une dégradation des métriques pertinentes et doit être annulé ou si le déploiement peut se poursuivre.

Quelques fonctionnalités supplémentaires et uniques liées aux déploiements couvrent un domaine qui est souvent négligé lorsqu’on parle de déploiement continu.

Cela peut paraître même antithétique, mais est essentiel au succès. Spinnaker aide à rendre le déploiement continu un peu moins continu. Il empêchera 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.

Il peut également appliquer des approbations manuelles pour assurer que la version se produit lorsque l’entreprise profitera le plus du changement. En fait, tout l’intérêt d’une intégration et d’un déploiement continus est d’être prêt à déployer les changements aussi rapidement que l’entreprise a besoin de changer.

7. Screwdriver

  • Page du projet
  • Code source
  • Licence : BSD
Screwdriver pour livraison continue

Screwdriver est un simple outil très impressionnant. Il utilise une approche de microservices. Il s’appuie sur des outils tels que Nomad, Kubernetes et Docker pour servir de moteur d’exécution.

Il y a un excellent tutoriel pour le déploiement sur AWS et Kubernetes. Mais, celui-ci pourrait être amélioré une fois le chart Helm est terminé.

Screwdriver utilise aussi YAML pour ses descriptions de pipeline. Il a de nombreux paramètres sensibles. Il y a donc moins de configuration standard pour chaque pipeline.

La configuration décrit un flux de travail avancé qui peut avoir des dépendances complexes entre les travaux. A titre d’exemple, un travail peut sans doute s’exécuter après ou avant un autre travail. Les travaux peuvent s’exécuter en parallèle et être joints par la suite.

Vous pouvez aussi utiliser des opérateurs logiques pour exécuter un travail, par exemple, si l’une de ses dépendances réussit ou uniquement si toutes réussissent. Encore mieux, vous pouvez spécifier certains travaux à déclencher à partir d’une requête pull.

De plus, les travaux dépendants ne s’exécutent pas lorsque cela se produit, ce qui permet de séparer facilement votre pipeline pour savoir quand un artefact doit être mis en production et quand il doit encore être examiné.

Il ne s’agit que d’une brève description des outils CI/CD. Chacun a des fonctionnalités et des différences encore plus intéressantes que vous pouvez étudier. Ils sont tous open source et gratuits. Alors, découvrez-les et voyez celui qui correspond le mieux à vos besoins.

Aina Strauss

À lire aussi

equilibreur charge gcp

Équilibreur de charge sur Google Cloud Platform

Table de matièreLes anciens outils utilisésL’introduction des pipelines CI/CDExemple d’utilisation des pipelines CI/CDPeu de ligne …