Qu’est-ce que le CI/CD/CD?

Dans le monde du DevOps, les termes « intégration continue », « livraison continue » et « déploiement continu » sont omniprésents, et souvent utilisés de manière interchangeable, comme des synonymes.

Et pourtant! S’ils renvoient tous au processus de livraison de logiciel, chacun présente ses propres contraintes, et surtout, ses propres avantages. Pour correctement mettre en place ces concepts, il faut d’abord en comprendre les différences.

Quelles sont-elles? Comment les différentes approches s’articulent dans le processus de développement?

Table des matières

• L’intégration continue (CI) et ses avantages
• La livraison continue (CD) et ses avantages
• Le déploiement continu (CD) et ses avantages
• Intégration continue vs. livraison continue
• Intégration continue vs. déploiement continu
• Livraison continue vs. déploiement continu
• Les pièges de l’intégration continue en isolation

Quelles sont les différences entre l’intégration continue, la livraison continue et le déploiement continu?

Comme mentionné en introduction, ces trois approches ne s’intègrent pas de la même manière et n’ont pas le même sens pour une équipe de développement. Envisagez-les dans un ordre chronologique. Le processus commence par l’intégration continue, puis c’est au tour de la livraison continue, et enfin du déploiement continu.

Ces concepts s’agencent dans cet ordre, et le premier ancre les deux autres. En d’autres mots, ce serait contraire aux conventions de mettre en place la livraison continue sans avoir préparé l’intégration continue d’abord.

Voyons les différences en détail.

Intégration continue (CI)

L’intégration continue consiste à fusionner les changements apportés au code dans la branche de base aussi souvent que possible. Ces changements sont validés dans une nouvelle version, laquelle est ensuite testée à l’aide de scripts. Si les résultats ne sont pas favorables, les changements ne sont pas fusionnés, et les développeurs s’évitent les problèmes d’intégration.

Les avantages de l’intégration continue

Ce processus engendre également moins de bogues en production, puisque les problèmes, notamment d’intégration, sont repérés et résolus en amont.

Livraison continue (CD)

La livraison continue est la suite logique de la CI : elle permet d’automatiser le déploiement de tous les changements apportés au code vers un environnement particulier (développement, contrôle de la qualité, test, production, etc.) après la fusion vers la branche de base. Ce mécanisme peut être intégré à la CI ou considéré de manière indépendante, puisque le processus de CI rend la source de vérité fiable. En d’autres mots, les changements sont automatiquement livrés après avoir été automatiquement testés. Les développeurs peuvent donc déployer des changements à tout moment en cliquant simplement sur un bouton ou lorsque la CI se termine.

Les avantages de la livraison continue

Puisque les développeurs peuvent déployer leurs changements n’importe quand, il est recommandé de les passer en production le plus souvent possible pour faciliter la résolution de problèmes et offrir aux utilisateurs un produit de qualité optimale le plus tôt possible. Souvent, le passage en production peut être géré par un gestionnaire désigné, à l’aide d’un processus de conformité répondant aux exigences de l’organisation. En assignant ce processus au personnel non technique, vous réduisez la charge de travail sur l’équipe de développement, qui peut alors se concentrer sur les améliorations.

Le déploiement continu (CD)

Le déploiement continu complète le processus en s’arrimant après la livraison continue. Avec cette approche, tous les changements validés par les étapes de vérification de chaque phase du pipeline sont envoyés en production. C’est un processus entièrement automatisé, et seul un échec dans les étapes de vérification annulera l’envoi d’un changement vers la phase de production.

Les avantages du déploiement continu

En dehors du fait que les clients bénéficient plus rapidement des mises à jour, les développeurs obtiennent des rétroactions plus tôt, et subissent donc moins de pression dans la mesure où les changements sont déployés petit à petit, et non tout d’un coup. Pour automatiser entièrement le déploiement, il est crucial de suivre certains indicateurs, notamment le temps moyen de réparation (MTR) et le taux de défaillance.

Regardons maintenant de plus près les différences entre ces concepts, lesquelles vous appréhendez peut-être déjà.

Intégration continue vs. livraison continue

Comme décrit plus haut, l’intégration continue est un processus d’intégration des changements* apportés au code dans le code principal. Pour la mettre en place, les développeurs utilisent une plateforme adaptée.

Par comparaison, la livraison continue est un processus qui opère une fois que les changements ont été intégrés au code principal, et qui consiste à « livrer » ces changements aux clients. La CI et la CD ne sont donc pas simplement des approches différentes, elles sont complémentaires.

En principe, il s’agit de tester et de déployer du code. L’intégration continue existe depuis beaucoup plus longtemps, et des outils spécialisés permettent d’en résoudre les problèmes. Utiliser un outil de CD au lieu de forcer l’intégration d’un pipeline CD dans votre outil de CI, c’est préférer un marteau pour enfoncer un clou et un tournevis pour serrer une vis : il faut utiliser le bon outil à bon escient.

*Veuillez noter que ceci réfère à un texte disponible en anglais seulement. 

Intégration continue vs. déploiement continu

Les différences entre l’intégration continue et le déploiement continu sont sensiblement identiques aux différences que nous venons de mentionner. Avec le déploiement continu, ce qui change, c’est que les changements sont automatiquement déployés aux clients sans intervention humaine. 

Livraison continue vs. déploiement continu

Rendus là, la différence est évidente. La livraison continue est un processus partiellement manuel lors duquel les développeurs déploient les changements en cliquant sur un bouton, alors qu’avec le déploiement continu, le processus est parfaitement automatisé.

Les pièges de l’intégration continue en isolation

Pourquoi est-il important de comprendre ces différences? En fait, de beaucoup d’organisations et d’équipes de développement mélangent les deux et finissent par ne se concentrer que sur l’intégration continue, en pensant faire de la livraison continue. Parfois, elles confondent aussi livraison continue et déploiement continu, et négligent l’ensemble du processus par manque de préparation au niveau du déploiement.

Configurer un serveur de CI qui fusionne et intègre des changements de code de manière continue ne signifie pas faire de la livraison continue. Dans ce cas, on parle juste d’utiliser un serveur d’intégration continue. Par exemple, une équipe pourrait configurer un serveur et fusionner des changements plusieurs fois par jour, mais ne pas réussir à les déployer de manière continue. C’est un début, particulièrement important pour alléger la résolution de problèmes, mais ce n’est pas de la livraison continue.

Pour correctement mettre en place un système de livraison continue, cette équipe doit configurer ses processus de test et de déploiement de manière à ce qu’ils s’exécutent automatiquement et sans interruption. Elle doit utiliser les bons outils à bon escient, et non demander à la CI d’effectuer des tâches auxquelles le processus est mal adapté.

Confondre les deux méthodes engendre également plusieurs inconvénients. Dans notre exemple, l’équipe qui pense avoir mis en place une livraison continue :

• réalisera que ses logiciels sont toujours globalement complexes à déployer et passera des jours à préparer une nouvelle version, alors qu’un véritable développement continu simplifierait radicalement ce déploiement;
• n’accélérera pas sa cadence de livraison ni le processus de rétroaction des clients, soit un des principaux avantages de la livraison continue;
• et aura beaucoup plus de mal à prendre des décisions sur des changements mineurs, tout en perdant du temps sur les itérations.

L’importance de l’intégration continue est une évidence. De fait, les équipes de développement ne devraient même pas se pencher sur la livraison continue avant d’avoir mis en place un système d’intégration continue.

Cependant, la livraison continue est tout aussi importante, sinon davantage. C’est simple, passer à côté de la livraison continue réduit grandement la fiabilité et la stabilité du processus. C’est pourquoi il est essentiel de comprendre les différences entre les deux afin de les mettre en place correctement.