L’intégration continue (CI) est issue d’une méthode de développement logiciel créée par Grady Booch en 1991. L’automatisation des tests a ensuite fait évoluer le CI. Puis, la livraison continue (CD) a commencé à faire parler d’elle en 2009. En juillet 2010, paraît le premier livre, « Continuous delivery » de Jez Humble et David Farley, traitant du CI/CD et posant ses pratiques avec une orientation DevOps. Dès lors, CI/CD est présenté comme étant une solution à mettre en œuvre pour régler les problèmes induits par l’intégration d’un nouveau code. Ces nouvelles pratiques révolutionnent complètement la livraison et le déploiement des applications tant et si bien que de plus en plus d’entreprises s’y adonnent.
Découvrez ici l’essentiel à savoir sur le CI/CD :
CI/CD est l’acronyme de Continuous Integration, Continuous Delivery/Deployment signifiant Intégration continue, Livraison et Déploiement continus. C’est un ensemble de pratiques agiles et organisationnelles permettant un processus métier simplifié et automatisé de développement et déploiement efficace de logiciels. Une grande partie de l’intervention humaine habituelle dans les anciennes pratiques, notamment celle en cascade, est donc automatisée. En d’autres termes, les environnements de production CI/CD sont spécialement conçus pour optimiser le temps de développement, de livraison et de déploiement des logiciels et applications informatiques (applications web ou applications mobiles).
Avant le CI/CD, les développeurs produisaient une version annuelle de leurs logiciels. Avec l’intégration et la livraison continues, on peut automatiser et déployer un logiciel bien plus rapidement sur le marché, puis les améliorer sans cesse au long de leur cycle de vie en fonction des tests des opérateurs et des retours des utilisateurs.
Pour cela, ces pratiques nécessitent de reconsidérer les mentalités et les méthodes de travail traditionnelles. Une approche beaucoup plus collaborative du travail doit briser les anciens silos de développement informatique. C’est pourquoi CI/CD est un élément essentiel de la pratique DevOps et des autres pratiques modernes de développement logiciel comme le SRE.
Consultez : Pourquoi la culture DevOps est-elle bénéfique pour votre entreprise ?
Si « CI » désigne sans équivoque l’intégration continue, « CD » peut signifier livraison continue ou déploiement continu. Ces deux derniers concepts, très proches, concernent l’automatisation de la dernière étape du pipeline CI/CD.
CI/CD peut donc se rapporter à :
Découvrez nos définitions de chacune de ces pratiques pour comprendre leurs différences.
L’intégration continue est la pratique utilisée par les développeurs pour intégrer tôt et souvent tout changement de code dans la branche principale partagée d’un référentiel. Un système de contrôle de version (tel que le projet open-source Git) est alors employé. Chaque modification fusionnée avec le code source génère un build qui est automatiquement testé (tests unitaires et d’intégration) pour détecter des dysfonctionnements dans le code avant validation.
L’intégration continue apporte concrètement deux grandes nouveautés :
Suite logique de l’intégration continue, la livraison continue s’assure automatiquement que le code contient le nécessaire au déploiement en production. Le processus de livraison est donc automatisé. En revanche, le logiciel, ou sa nouvelle version s’il s’agit d’une modification, n’est pas mis en production (déploiement), c’est-à-dire qu’il n’est pas disponible pour les clients.
Dans ce contexte de livraison continue, le déploiement est à réaliser manuellement ; chaque jour, chaque semaine, chaque mois, selon les besoins de votre projet et de votre entreprise. L’automatisation de la livraison a pour avantage principal de gagner du temps et des ressources.
Le déploiement continu est un processus de déploiement automatique qui consiste à pousser (commit) en production de manière automatique toutes les nouvelles versions de l’application selon une règle qui décide quand a lieu la production finale. Cette règle est définie par les équipes de développement (une fois par jour, par semaine, etc.) pour planifier le déploiement. Avec ce type de déploiement informatique, il en résulte que chaque changement validé par les pipelines de production est automatiquement mis à la disposition du client dans une périodicité déterminée.
On peut présenter ce deuxième CD de deux manières différentes :
Évidemment, ce n’est qu’une question de point de vue. Dans la pratique, le résultat est exactement le même.
Consultez : 12 indicateurs afin de mesurer vos processus DevOps
Le but de créer un pipeline CI/CD est de fournir plus tôt un produit aux clients et de l’améliorer sans cesse en fonction des retours des utilisateurs plutôt que d’attendre le produit parfait. De plus, une livraison de petits lots de code facilite le dépannage en cas de problème ; c’est un vrai gain en aglité. La réactivité est bien plus rapide. C’est aussi un excellent moyen de réduire la pression sur l’équipe de développement grâce à la disparition du célèbre et redouté jour de livraison.
L’ère de l’Internet et du cloud computing a véritablement bousculé le cycle de vie du développement logiciel. En effet, le marché et les utilisateurs sont devenus bien plus exigeants et réclament des nouveautés et une amélioration continue. Or, les méthodes classiques de conception et développement en cascade et par silos sont faites pour des déploiements annuels (souvenez-vous des CD d’installation). Elles ne permettent pas de fusionner différents morceaux de code le même jour (merge day), à moins de procéder à de nombreuses tâches manuelles prenant un temps considérable. De plus, les anciennes méthodes de déploiement et d’intégration permettent encore moins de travailler à plusieurs développeurs en simultanée. Le CI/CD est, quant à lui, un concept de développement agile autorisant la simultanéité, le travail à plusieurs et mettant à profit l’automatisation des tâches.
L’implémentation de l’intégration continue et de la livraison continue nécessite des architectures spécifiques permettant de travailler sur serveur d’intégration continue ou sur un service cloud. Pour comprendre le fonctionnement, il est important de connaître certains fondamentaux, comme le référentiel et le contrôle des versions :
Dans une stratégie d’intégration continue, les développeurs commitent (de la commande git commit) leurs lots de code chaque fois qu’ils sont terminés, et ce jusqu’à plusieurs fois par jour. Ainsi, chaque lot de code est poussé vers une branche de développement du référentiel pour les premières phases de tests fonctionnels. Ces portions de code validées sont ensuite fusionnées avec la branche principale pour lancer le build et d’autres tests d’intégration.
Les tests peuvent être effectués sur plusieurs systèmes d’exploitation ou plusieurs navigateurs selon la nature du projet. Pendant ce temps, le développeur logiciel peut continuer de travailler sur ses lots de code. Puis, en cas de détection d’anomalies, des alertes les préviennent afin de procéder aux modifications nécessaires.
La partie intégration continue est certainement la plus importante au niveau du temps et des ressources employés. La livraison s’effectue de manière automatique grâce aux outils CI/CD et le déploiement d’une application peut être manuel ou automatisé.
Consultez : GitOps, une nouvelle tendance pour vos infrastructures
Le CI/CD est une industrialisation de la production logicielle qui nécessite la mise en œuvre d’une structure coûteuse, c’est pourquoi les entreprises privilégient largement les outils de déploiement mis à leur disposition. Et, les meilleurs outils de développement permettent d’améliorer les processus de développement d’applications.
Il serait tentant de croire que toutes les solutions de déploiement automatisé CI/CD servent les mêmes objectifs. Or, les outils d’intégration continue peuvent être employés à des fins différentes :
Consultez notre guide des outils CI/CD pour améliorer vos processus afin de vous aider à choisir votre solution de déploiement en fonction de vos attentes.
