Definition

Continuous Delivery (Livraison continue, CD)

La livraison continue (CD, Continuous Delivery) est une approche de la publication de logiciels dans laquelle les équipes de développement produisent et testent le code dans des cycles courts, en s’appuyant généralement sur une plus grande automatisation.

Ce processus permet de créer, tester et déployer des logiciels rapidement en privilégiant des mises à jour incrémentielles, au lieu de refontes complètes.

La livraison continue vise à raccourcir au maximum les boucles de rétroaction, afin d’améliorer la qualité des logiciels. Le code est livré à intervalles réguliers pour être soumis à des tests d’acceptation (UAT, User Acceptance Testing, aussi appelés Bêta tests), ou essayé dans l’environnement de test, afin de mettre en évidence les causes et les effets. Il est ainsi possible d’en tester tous les aspects opérationnels, notamment au niveau de la logique des règles métier, dans l’optique de réduire les problèmes inattendus de performances lors de la mise en production.

Avec la CD et des tests réalisés en amont, un concept parfois appelé shift left (c’est-à-dire « déplacer vers la gauche », sous-entendu dans le calendrier des tâches), les développeurs peuvent élaborer des correctifs avant d’aborder un autre aspect du projet, limitant ainsi les difficultés qui surviennent en cas de reprise d’une tâche après un certain délai.

L’arsenal des techniques de CD comprend également des tests de l’interface utilisateur, des tests de charge et des tests d’intégration.

Avantages de la livraison continue

Par rapport à d’autres méthodologies, comme le « modèle en cascade », la CD simplifie le déploiement des logiciels, car elle évite à l’équipe de développement de passer trop de temps à préparer la publication d’un référentiel de code, ou à regrouper de nombreuses petites modifications au sein d’une version plus importante. À la place, l’équipe met le code à jour en continu et le publie par petits incréments.

En effet, des versions plus petites permettent de déceler rapidement d’éventuels bogues (bugs) dans le nouveau code. Par exemple, si une équipe de développement déploie du code dans l’environnement de production et qu’une erreur est détectée, il sera plus facile d’isoler le code fautif dans l’une des mises à jour incrémentielles. Il suffit alors aux développeurs de supprimer le problème, de tester le code corrigé et de le redéployer, avant de recevoir un nouveau retour.

En outre, la CD permet des itérations plus rapides des applications, car de nombreux développeurs peuvent collaborer et créer du code à différents moments sans impacter d’autres projets.

Si un processus itératif devient difficile à gérer en raison de la complexité croissante du projet, la CD permet de revenir à des publications plus restreintes mais plus fréquentes, qui gagnent ainsi en fiabilité, en prévisibilité et en gérabilité.

Intégration continue et livraison continue

La livraison continue est une extension du concept d’intégration continue (CI, Continuous Integration). Tandis que la CI porte sur la partie build/test du code initial du cycle de développement pour chaque version, la CD se concentre sur ce qu’il advient d’une modification validée une fois cette étape franchie.

La CI offre un moyen de fusionner fréquemment les copies de tous les développeurs dans un référentiel de code. Les modifications isolées peuvent être testées et intégrées rapidement à l’aide de tests unitaires et d’intégration. L’intégration continue peut apporter à l’équipe un retour spécifique sur les modifications ou les ajouts portant sur le référentiel de code. Si un bogue est introduit, les tests du code en CI devraient la mettre en évidence bien avant la phase de publication.

La CI et la CD sont souvent associées sous l’appellation CI/CD, car la CD s’inscrit dans le prolongement de la CI. Avec la CD, toute validation qui satisfait aux tests automatisés peut être considérée comme raisonnablement prête pour la publication. Grâce à la CI et à la CD, une entreprise peut mettre en œuvre des processus de test et de simulation automatisés permettant ainsi aux développeurs de décider à quel moment et selon quelle fréquence déployer leur code en production.

Processus de livraison continue

En CD, les builds, tests et déploiements de simulation automatisés sont intégrés dans un seul processus continu. Les processus de CI/CD comprennent généralement quatre phases : celles des composants, des sous-systèmes, des systèmes et de la production.

On considère en principe que la phase des composants fait partie de l’intégration continue, bien qu’elle puisse également être vue comme un élément de la livraison continue. C’est pendant cette phase que les développeurs écrivent et valident les plus petites unités distribuables de code. Le code est ensuite testé par le biais d’évaluations, de tests unitaires et d’analyses statiques. Ces tests menés sur de petites quantités de code sont plus efficaces que des tests de bout en bout, et ils permettent d’isoler les problèmes.

Les phases des sous-systèmes se concentrent sur de nombreux composants associés de façon informelle. Ce code doit être exécutable. Les tests effectués au niveau des sous-systèmes portent sur les fonctionnalités, les performances et la sécurité. Ils servent à s’assurer que le code développé répond aux normes de qualité de l’utilisateur final et aux spécifications du projet.

Les phases des systèmes se traduisent par des sous-systèmes intégrés qui réclament encore des essais au niveau de l’interface utilisateur et des réseaux, et éventuellement d’autres évaluations des fonctionnalités, des performances et de la sécurité. À ce stade, les composants de l’application peuvent être maintenus séparés en tant que microservices ou être intégrés pour former un système complet.

Lors de la phase de production, les sous-systèmes indépendants ou systèmes intégrés sont prêts à être déployés dans l’environnement de production. Couramment employé en CD, le déploiement bleu/vert est une méthode dans laquelle deux environnements sont configurés à l’identique. L’un d’entre eux est mis à la disposition des utilisateurs, tandis que l’autre sert au déploiement d’un nouveau code et reste soumis à des tests (test de charge, par exemple, pour mesurer les performances à capacité élevée). Lorsque le code publié est jugé prêt, les sources de trafic des environnements sont inversées et le nouveau code devient à son tour accessible aux utilisateurs. Si un problème est découvert après le transfert, il est possible de rediriger de nouveau le trafic vers l’environnement qui était considéré comme fiable le temps pour l’équipe informatique de trouver une solution.

Outils de livraison continue

De nombreux outils open source et commerciaux sont disponibles à chaque étape de la livraison continue, de même que des outils qui assurent à la fois intégration et livraison continues.

En général, les équipes informatiques qui pratiquent la CI/CD utilisent un système de contrôle des versions pour gérer le code, un moteur de build automatisé, des systèmes de test fonctionnel et d’intégration, des testeurs de performances pour les essais réalisés en charge normale et en contrainte, des outils de gestion de la configuration, et enfin un référentiel/dépôt d’artefacts. Ces équipes peuvent également utiliser des conteneurs pour créer un modèle de déploiement logiciel cohérent allant du développement à la production en passant par les tests, ainsi que des environnements de développement intégrés pour faciliter le travail de build et de test. Tous ces outils s’intègrent grâce à un outil de pipeline CI/CD, tel que Jenkins ou CircleCI. Les entreprises ayant également besoin d’exercer un contrôle sur la gestion de production et de la capacité, il est donc possible d’intégrer des outils à cet effet au pipeline CI/CD.

 Pipeline CI/CD
Cet exemple de pipeline CI/CD couvre le développement et la livraison de code et un échantillon de tests, qui permettent de s'assurer que les versions sont prêtes pour la production.

Les fournisseurs de cloud public, tels qu’AWS, proposent des ensembles intégrés d’outils de CI/CD, que les développeurs et les informaticiens chargés de l’exploitation peuvent utiliser de la phase de développement à la mise en production, ainsi que pour les tâches de surveillance et de dimensionnement.

Livraison continue et déploiement continu

Les concepts de livraison continue et de déploiement continu, dont le sens est proche, sont souvent confondus. Dans la livraison continue, le code passe successivement par différentes étapes qui le préparent à sa publication en production, mais il n’est pas automatiquement mis en service. Les modifications du code doivent d’abord être approuvées et il est probable que des tests et une assurance qualité (QA pour Quality Assurance) manuels soient requis. En cas de déploiement continu en revanche, le code peut être automatiquement testé, validé et mis en production, où il fera automatiquement l’objet d’un dimensionnement en fonction des besoins des utilisateurs et d’une surveillance des problèmes susceptibles de nécessiter un retour arrière (rollback).

 Livraison continue vs. déploiement continu
La livraison continue et le déploiement continu diffèrent dans la façon dont le code atteint l'environnement de production en direct.
Cette définition a été mise à jour en janvier 2019

Pour approfondir sur Outils de développement

Close