Qu’est-ce que le CI/CD ? Les pipelines et outils CI/CD expliqués

En une génération, le CI/CD est passé d’un sujet de niche à une approche courante du développement et de la livraison de logiciels, désormais considérée comme allant de soi dans le secteur. Bien que beaucoup emploient le terme avec assurance, les notions de CI et de CD sont souvent mal utilisées et mal comprises.

Le CI/CD expliqué

Quels sont les principaux composants d’un pipeline CI/CD ?

Qu’est-ce que l’intégration continue (CI) ?

L’intégration continue (CI) est généralement considérée comme une pratique de développement consistant à intégrer régulièrement le code en cours de développement dans une branche unique, appelée généralement « trunk ». Les équipes peuvent créer des branches pour des raisons précises (par exemple, pour appliquer un correctif urgent à un système en production), mais ces cas sont considérés comme des exceptions à la règle.

Pour gérer le travail en cours, on utilise des « feature flags » afin de s’assurer que le code n’est pas activé tant qu’il n’est pas prêt. Cette approche à branche unique diffère d’autres méthodes de développement, comme GitFlow, qui reposent sur plusieurs branches de longue durée permettant de mener plusieurs développements en parallèle.

L’importance du CI dans le framework CI/CD

Grâce au CI, vous pouvez éviter le problème traditionnel du « jour de fusion », où ces différents flux de développement doivent être soigneusement réconciliés. Cette réconciliation peut être complexe et source d’erreurs, et diminuer la confiance dans la mise en production des modifications de code. La pratique du CI favorise également d’autres bonnes pratiques, comme l’exécution régulière de tests unitaires ou d’intégration si vous disposez d’un pipeline CI automatisé. D’un point de vue technique, le CI exige que les développeurs intègrent fréquemment leur travail en cours dans une branche unique (autrement dit, ils ne créent aucune branche pour leurs fonctionnalités). Dans la pratique courante, cette règle n’est toutefois pas toujours respectée.

Qu’est-ce que la livraison continue (CD) ?

L’intégration continue garantit que les modifications apportées au code sont régulièrement intégrées à la branche principale. La livraison continue prépare le code sous la forme d’un livrable qui peut ensuite être déployé par les développeurs eux-mêmes (dans un modèle DevOps pur) ou, si nécessaire, par une équipe d’exploitation distincte. Cette notion est souvent confondue avec le « déploiement continu », qui désigne un processus déployant automatiquement les modifications en production. Là encore, dans la pratique, cette seconde définition est plus courante que la définition technique.

Qu’est-ce que le déploiement continu ?

Le déploiement continu permet aux entreprises de publier automatiquement leurs applications, sans intervention manuelle. Avec cette approche, les équipes DevOps définissent à l’avance les critères de mise en production. Une fois ces critères remplis et validés, le code est directement déployé en production. Les entreprises peuvent ainsi réagir plus rapidement aux changements et proposer plus vite de nouvelles fonctionnalités aux utilisateurs.

Il est possible de pratiquer l’intégration continue (CI) sans livraison continue (CD) ni déploiement continu, mais la CD suppose que le CI soit déjà en place. Déployer en production à la demande serait presque impossible sans les fondamentaux du CI : intégrer le code dans un dépôt partagé, automatiser les tests et les builds, et travailler par petits lots fréquents chaque jour.

Qu’est-ce qu’un pipeline CI/CD ?

L’automatisation est idéale pour les pratiques CI et CD, puisqu’elles nécessitent de répéter régulièrement les mêmes actions. L’automatisation des processus CI et CD est généralement appelée « pipeline », par analogie avec les chaînes de production automatisées des usines. L’automatisation étant l’un des principes clés du DevOps (le « A » du modèle CALMS de DevOps), les pipelines CI/CD sont souvent considérés comme essentiels aux pratiques DevOps. Une seule équipe peut créer et maintenir le pipeline jusqu’à la production (dans un modèle DevOps plus pur), ou le pipeline CI/CD peut fournir un ensemble stable et davantage testé d’artefacts de build à une équipe d’exploitation distincte, qui se chargera du déploiement.

Les avantages de l’intégration CI/CD

Un pipeline CI/CD facilite également l’introduction d’autres changements susceptibles d’améliorer la fiabilité. Par exemple, il est relativement simple d’ajouter des tests unitaires ou d’intégration plus tôt dans le cycle de build et de déploiement. Cette pratique, appelée « shift left », peut réduire considérablement les coûts, car les problèmes sont détectés plus tôt dans le processus de livraison.

De même, les pipelines favorisent les mises en production « en petites étapes et à intervalles fréquents », ce qui réduit également les risques : chacune de ces petites modifications présente moins de risques pour l’ensemble du système. À l’inverse, l’approche traditionnelle du « big bang » regroupe de nombreuses modifications dans une seule mise en production majeure et ponctuelle.

Enfin, la réduction des interventions manuelles diminue encore les risques, car les machines sont plus fiables que les personnes. Un pipeline automatisé risque peu d’exécuter la mauvaise commande lors d’un build ou d’oublier un test d’assurance qualité au cours d’un cycle de mise en production.

La popularité récente de GitOps s’appuie sur ce code de pipeline et exige que celui-ci soit entièrement représenté dans le contrôle de version. De plus, des agents de contrôle automatisés gèrent l’état du déploiement afin qu’il corresponde au code source.

Pipelines CI/CD et sécurité

En matière de gestion de la sécurité logicielle, la popularité croissante des pipelines CI/CD offre de nouvelles possibilités, mais entraîne aussi de nouvelles menaces. Côté positif, les pipelines CI/CD limitent l’accès libre au processus de build et de déploiement. Il est également plus facile d’accorder aux utilisateurs concernés, qu’il s’agisse de personnes ou de services, un accès précis aux seules ressources dont ils ont besoin, plutôt qu’un accès administrateur complet. Les pipelines améliorent aussi considérablement l’auditabilité du build et de la livraison : à chaque étape, il est relativement simple de consigner l’action effectuée, son résultat et son déclencheur (ou son auteur).

Comme indiqué, l’augmentation des menaces constitue bien sûr un inconvénient du CI/CD. Depuis 2000, plusieurs facteurs ont entraîné une prolifération du code, de ses sources et des plateformes logicielles. Le développement et le déploiement s’étant accélérés, et les pipelines étant devenus de plus en plus fiables, les logiciels sont aujourd’hui déployés plus rapidement que jamais.

La multiplication des bibliothèques open source, des plateformes et des outils offre également aux développeurs un choix beaucoup plus vaste de logiciels. Enfin, l’essor de la conteneurisation comme technologie flexible de packaging et de déploiement, ainsi que l’interopérabilité des composants logiciels via les interfaces REST et gRPC, permettent de créer et de déployer ces composants ensemble plus facilement et plus rapidement que jamais.

La combinaison de ces facteurs a provoqué un raz-de-marée de nouveaux logiciels que les services centralisés doivent tenter de gérer. Les équipes de sécurité, d’exploitation et d’architecture ont dû s’adapter à cet environnement nouveau et en constante évolution.

Cette pression a donné naissance au DevSecOps, une évolution du modèle DevOps fondée sur une responsabilité partagée en matière de développement, de déploiement et de maintenance, dans laquelle les enjeux de sécurité sont étroitement intégrés.

Play Video: CI/CD workflows

Outils de pipeline CI/CD

À leurs débuts, les pipelines CI/CD combinaient de simples scripts shell et des outils dérivés des fichiers Make, comme Ant et Maven. Au fil du temps, des applications plus complètes remplissant cette fonction se sont largement répandues. Certaines étaient à l’origine de simples applications côté serveur, avant de devenir des produits commerciaux à part entière. Les principaux acteurs de ce secteur sont Jenkins et TeamCity. À l’origine, ces outils stockaient la configuration des pipelines côté serveur, dans un état persistant géré par l’interface graphique de l’application. Plus récemment, les pipelines déclaratifs sous forme de code, récupérés depuis des dépôts distants, sont devenus la norme.

Snyk peut vous aider, par exemple, à éviter en continu les vulnérabilités connues dans vos dépendances grâce à l’analyse statique de la sécurité des applications. Découvrez les intégrations de sécurité de Snyk avec TeamCity, Jenkins et de nombreux autres outils et systèmes CI/CD. Consultez les exemples de configuration des intégrations de Snyk dans notre dépôt GitHub.

Play Video: Why and when use Snyk in CI/CD?

Les principaux services de contrôle de version s’y sont également mis. GitLab a été le premier à proposer son offre GitLab CI/CD, suivi par GitHub avec GitHub Actions. Snyk s’intègre à GitLab et à GitHub.

Bien sûr, les principaux fournisseurs de services cloud proposent également ces services. Azure propose son produit Pipelines et AWS offre CodePipeline. Les produits Azure et AWS peuvent tous deux être intégrés à Snyk.

Le CI/CD, nouvelle norme du secteur

Depuis l’apparition du CI en 1991, le CI/CD est passé d’une pratique relativement marginale à une norme du secteur. Parallèlement, les effets combinés et mutuellement renforcés de l’essor de l’open source, de la conteneurisation et des applications distribuées ont entraîné une explosion des artefacts logiciels, qui couvrent un éventail apparemment infini d’outils et de technologies.

Cette évolution pose toutefois un problème de sécurité aux responsables des pipelines de livraison logicielle, qui doivent garder sous contrôle tous ces nouveaux vecteurs d’attaque. La vérification manuelle n’est cependant ni viable à long terme, ni efficace, ni fiable. Découvrez ici les différents types d’audits de sécurité que vous pouvez ajouter à votre pipeline.

Renforcez la sécurité des développeurs tout au long du processus de développement. Intégrez l’analyse des vulnérabilités de Snyk à l’automatisation de votre pipeline. Découvrez toutes les intégrations de Snyk ici.