Continuous Delivery (Livraison continue, CD)

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.

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).