Qu’est-ce que l’intégration continue/la livraison continue (CI/CD) ?

L'une des caractéristiques essentielles du pipeline CI/CD est l'utilisation de l'automatisation pour garantir la qualité du code. À mesure que les modifications logicielles progressent dans le pipeline, les tests automatisés identifient les dépendances et autres problèmes plus tôt, envoient les modifications de code à différents environnements et distribuent les applications aux environnements de production.

Ici, le rôle de l’automatisation est d’effectuer le contrôle qualité, en évaluant tout, de la performance à l’utilisation de l’interface de programmation d’applications (API) et à la sécurité. Ce processus permet de garantir que les modifications apportées par tous les membres de l'équipe sont intégrées de manière complète et exécutées comme prévu.

La capacité d’automatiser différentes phases du pipeline CI/CD aide les équipes de développement à améliorer la qualité, à travailler plus rapidement et à améliorer d’autres indicateurs DevOps.

Alors que le pipeline CI/CD désigne des workflows DevOps agiles, CI/CD correspond aux pratiques combinées d’intégration continue et de distribution continue.

La CI/CD permet de combiner le travail de différentes personnes plus rapidement et avec plus de précision en un seul produit cohérent. Dans les environnements DevOps, CI/CD simplifie les processus de codage, de tests et de déploiement des applications. Cette approche fournit aux équipes un référentiel unique pour stocker le travail et des outils d’automatisation pour combiner et tester le code afin de s’assurer qu’il fonctionne de manière cohérente.

Il permet aux équipes DevOps d’écrire du code, de l’intégrer, d’exécuter des tests, de distribuer des versions et de déployer des modifications logicielles de manière collaborative et en temps réel. Si l’automatisation des versions logicielles, des tests initiaux au déploiement final, est un avantage majeur du pipeline CI/CD, celui-ci présente d’autres avantages :

• Temps de déploiement réduit : les tests automatisés améliorent l’efficacité du processus de développement en réduisant la durée du processus de distribution des logiciels. De plus, le déploiement continu et le provisionnement automatique permettent aux modifications apportées par un développeur à une application cloud d’être mises en ligne quelques minutes après leur écriture.

• Diminution des coûts : la rapidité du développement, des tests et de la production (facilitée par l’automatisation) signifie moins de temps consacré au développement. Ce processus permet de réduire les coûts par rapport au développement logiciel classique.

• Boucles de rétroaction continues : le pipeline CI/CD représente un cycle continu : construction, test, déploiement. Les boucles de rétroaction permettent aux développeurs d’agir rapidement et d’améliorer le code à chaque fois qu’il est testé.

• Détection précoce des erreurs : dans le cadre de l’intégration continue, les tests sont automatisés pour chaque version de code créée afin de détecter les problèmes d’intégration. Ces problèmes sont plus faciles à résoudre lorsqu’ils sont détectés tôt dans le pipeline.

• Réduction des temps d’arrêt et fiabilité accrue : en cas d’échec du déploiement, de bogues ou de problèmes de performances, des fonctionnalités telles que les retours arrière automatiques ramènent un système logiciel ou une application à son état stable antérieur. Cette fonctionnalité minimise les temps d’arrêt et améliore la fiabilité du service.

• Collaboration d’équipe et intégration du système améliorées : tous les membres de l’équipe peuvent modifier le code, réagir aux retours et répondre rapidement à tout problème.

Le pipeline CI/CD se compose de 3 méthodologies interconnectées :

• Intégration continue
• Distribution continue
• Déploiement continu

Le processus CI/CD commence par l’intégration continue (CI), au cours de laquelle les développeurs valident leur code dans des référentiels centraux gérés par des systèmes de contrôle de version (VCS). La CI permet aux développeurs de travailler de manière indépendante, créant leur propre « branche » de codage pour implémenter de petits changements.

Au fur et à mesure que le développeur travaille, il peut prendre des instantanés du code source, généralement à l’aide d’un outil de gestion des versions tel que Git. Le développeur est alors libre de travailler sur de nouvelles fonctionnalités ; en cas de problème, Git peut rapidement rétablir l’état antérieur de la base de code.

Le travail des individus est ensuite transmis à un système automatisé qui utilise des scripts pour créer et tester les modifications de code. Après la phase de création automatisée, un serveur CI compile les modifications du code source dans le code de la branche principale, ou « tronc », du référentiel de code source partagé.

Au lieu d’écrire du code de manière indépendante et de l'envoyer à la branche principale une fois par mois, ce qui peut entraîner un travail pénible pour corriger des bugs et un mauvais contrôle des versions, le processus de développement CI/CD permet aux équipes d'envoyer plus fréquemment des modifications de code. Ces tests continus permettent de corriger les bogues plus rapidement, de garantir la fonctionnalité et, en fin de compte, d’améliorer la collaboration et la qualité des logiciels.

L’étape suivante du pipeline est la distribution continue (CD), qui place les modifications de code validées effectuées en intégration continue dans certains environnements ou dépôts de code, tels que GitHub. Ici, l’équipe des opérations peut les déployer dans un environnement de production réel.

Le logiciel et les API sont testés, et les erreurs sont résolues via un processus automatisé. À la dernière étape du processus de CD, l'équipe DevOps reçoit une notification concernant la dernière version, et l'envoie manuellement à la phase de déploiement.

L’objectif de la phase de pipeline de livraison continue est de déployer le nouveau code avec un minimum d’efforts, tout en permettant un certain niveau de supervision humaine.

Dans le processus CI/CD, CD signifie également déploiement continu. Le déploiement continu publie automatiquement les modifications de code pour les utilisateurs finaux après la réussite à une série de tests prédéfinis, tels que les tests d’intégration qui testent le code dans un environnement miroir afin de garantir l’intégrité du code.

La distribution continue et le déploiement continu impliquent tous deux l’automatisation plus en aval du pipeline par rapport à l’intégration continue, et ils sont souvent utilisés de manière interchangeable.

La différence entre la livraison continue et le déploiement continu réside dans le niveau d’automatisation utilisé dans les versions de logiciels ou d’applications. Dans la livraison continue, le code est automatiquement transféré vers des environnements de type production pour des tests supplémentaires et une assurance qualité, tels que l’évaluation des risques et l’identification des vulnérabilités du code source. Une intervention humaine est nécessaire pour passer en production après la réussite des tests.

Dans le déploiement continu, l’automatisation va plus loin. Une fois que le code a passé les tests, le déploiement en production se fait automatiquement ; aucune approbation humaine n’est nécessaire.

La manière dont une entreprise applique le pipeline CI/CD et décide de recourir à la distribution continue ou au déploiement continu dépend de ses besoins métier. Le déploiement continu est idéal pour les équipes DevOps à cycle de vie de développement rapide, comme celles qui développent des sites e-commerce et des plateformes de logiciels en tant que service (SaaS).

Le déploiement continu soutient le processus de publication des logiciels en permettant aux équipes de publier des logiciels nouveaux ou mis à jour souvent et le plus rapidement possible. Comme les changements sont déployés automatiquement au public, ce type de pipeline de déploiement continu est généralement utilisé uniquement par les équipes DevOps disposant d’un processus éprouvé.

Pour les équipes qui n’ont pas besoin de publier des mises à jour aussi fréquemment dans leur workflow, comme celles qui développent des applications de santé, la distribution continue est généralement l’option privilégiée. Elle est plus lente, mais offre un niveau de supervision supplémentaire pour garantir la fonctionnalité pour les utilisateurs finaux.

Pour en savoir plus sur la différence entre la distribution continue et le déploiement continu, consultez cette vidéo.

Un pipeline de machine learning est une série d’étapes interconnectées de traitement et de modélisation des données conçues pour automatiser, normaliser et rationaliser le processus de création, d’entraînement, d’évaluation et de déploiement des modèles de machine learning.

Les pipelines de machine learning sont un composant essentiel dans le développement et la production de systèmes de machine learning (ML). De plus, ils ont pris de plus en plus d’importance en raison de la croissance du big data et de l’intelligence artificielle (IA).

Selon Kings Research, la taille du marché mondial du machine learning était évaluée à 26,06 milliards de dollars en 2023 et devrait passer de 35,44 milliards de dollars en 2024 à 328,89 milliards de dollars d’ici 2031, affichant un TCAC de 37,47 % durant la période de prévision.¹

Les pipelines machine learning s’intègrent aux pratiques DevOps pour permettre la CI/CD des modèles machine learning. C’est ce que l’on appelle les opérations de machine learning (MLOps). Elles permettent aux équipes de science des données de gérer efficacement la complexité de l’orchestration du ML.

Du code source à la production, ces étapes constituent le cycle de vie de développement et le workflow du pipeline CI/CD :

• Construire
• Test
• Livraison
• Déployer

Cette étape fait partie du processus d’intégration continue et implique la création et la compilation du code. Les équipes travaillent en collaboration à partir du code source et intègrent le nouveau code tout en identifiant rapidement les problèmes ou conflits éventuels.

À ce stade, les équipes testent le code. Les tests automatisés ont lieu à la fois dans le cadre de la distribution et du déploiement continus. Ces environnements de test peuvent inclure des tests d’intégration, des tests unitaires et des tests de régression.

Ici, une base de code approuvée est envoyée à un environnement de production. Cette étape est automatisée dans le déploiement continu et n’est automatisée dans la distribution continue qu’après l’approbation du développeur.

Enfin, les modifications sont déployées et le produit final est mis en production. En distribution continue, les produits ou le code sont envoyés à des référentiels et mis en production ou déployés après approbation humaine. En déploiement continu, cette étape est automatisée.

Lors de la sélection des outils CI/CD, l'accent doit être mis sur l'optimisation et l'automatisation du processus de développement logiciel. Un pipeline CI/CD efficace utilise des outils open source pour l’intégration, les tests et le déploiement. Une configuration correcte de votre processus CI/CD a également un impact sur le succès de votre pipeline de développement logiciel.

L'outil CI/CD open source le plus courant est Jenkins. Jenkins est un serveur CI automatisé écrit en Java, utilisé pour automatiser les étapes CI/CD et les rapports. Parmi les autres outils open source d'intégration, citons Travis CI et CircleCI.

En plus des outils open source, tous les principaux fournisseurs de services cloud — Google Cloud, IBM® Cloud, Microsoft Azure et Amazon Web Services (AWS) — proposent des chaînes d’outils CI/CD basées sur le cloud, des pipelines et des intégrations d’outils.

Les environnements de développement intégrés (IDE), tels que GitHub ou AWS CodeCommit, aident les développeurs à créer, maintenir et suivre des paquets logiciels. Dans le même temps, des plateformes telles que GitLab cherchent à intégrer l'IDE au sein d'une plateforme complète incluant d'autres outils.

Lorsqu’elles opèrent dans un environnement cloud, les équipes DevOps cloud natives utilisent des conteneurs comme Docker pour empaqueter et expédier les applications, ainsi que des outils d’orchestration de conteneurs tels que Kubernetes. Bien que Kubernetes ne soit pas strictement destiné au pipeline CI/CD, il est utilisé dans de nombreux workflows CI/CD.

La sécurité CI/CD se concentre sur les pratiques, les processus et les technologies qui mettent en œuvre et gèrent les mesures de sécurité et de conformité dans l’ensemble du pipeline CI/CD.

Par le passé, la sécurité était ajoutée aux logiciels à la fin du cycle de développement. L’évolution des plateformes cloud, des microservices et des conteneurs a créé un goulot d’étranglement pour l’approche de développement traditionnelle.

La sécurité risque de ne pas suivre le rythme des versions rapides, les développeurs ayant adopté des pratiques agiles et DevOps, ce qui a stimulé l’évolution de DevSecOps, qui signifie développement, sécurité et opérations. DevSecOps automatise l’intégration des outils et pratiques de sécurité à mesure qu’ils apparaissent dans les pipelines d’intégration continue (CI) et de distribution continue (CD).

Les pratiques DevSecOps incluaient les tests shift-left et shift-right. Les tests shift-left impliquent l’intégration des tests de sécurité et d’autres pratiques de développement critiques plus tôt dans le cycle de vie du développement logiciel (SDLC). Les tests shift-right consistent à effectuer des tests plus tard dans le processus de développement, généralement dans des environnements de production. Ces méthodes se complètent en répartissant la responsabilité des tests tout au long du cycle de vie du développement logiciel.