Qu'est-ce que Continuous Delivery (CD) ?

Qu'est-ce que Continuous Delivery (CD) ?

La livraison continue (Continuous Delivery) est une discipline de développement logiciel dans laquelle chaque changement est compilé, testé et promu automatiquement, de sorte que le logiciel puisse partir en production à tout moment. Martin Fowler la définit ainsi : le logiciel "can be released to production at any time". Décider de livrer, et quand, reste un choix humain ou métier. La pratique s'appuie sur l'intégration continue et utilise en général un pipeline de déploiement.

Livraison continue ou déploiement continu

Les deux s'abrègent en "CD", d'où la confusion. La distinction de Fowler : avec le déploiement continu (Continuous Deployment), chaque changement qui traverse le pipeline est mis en production automatiquement. Avec la livraison continue, vous pourriez déployer souvent, mais vous pouvez choisir de ne pas le faire, par exemple parce que le métier préfère un rythme de mises en production plus lent. Le déploiement continu est donc la livraison continue plus une dernière étape automatique. L'inverse est faux.

Comment fonctionne un pipeline de livraison

Un changement franchit des étapes, et un échec à l'une d'elles l'arrête :

1. Commit et build. Un merge sur la branche principale lance un build qui produit un seul artefact, par exemple une image de conteneur.
2. Tests rapides. Les tests unitaires et les analyses statiques répondent en quelques minutes.
3. Déploiement dans un environnement proche de la production. Le même artefact est promu, jamais reconstruit, pour que ce qui a été testé soit ce qui est livré.
4. Contrôles plus lents. Tests d'intégration, de bout en bout et de régression passent ici, tout comme un test de charge.
5. Mise en production. Une personne la déclenche (delivery) ou le pipeline (deployment).

Deux techniques rendent les livraisons fréquentes plus sûres : les feature flags séparent le déploiement du code de l'activation d'une fonctionnalité, et un déploiement progressif limite le nombre d'utilisateurs qui voient d'abord un changement.

Exemple

Une équipe fusionne une pull request à 10 h 00. À 10 h 15, le pipeline a construit une image, passé les tests unitaires et déployé en préproduction, où la suite de bout en bout et un court test de charge passent aussi. Le build est marqué livrable. Le product owner attend l'annonce marketing et livre jeudi d'un clic. Si le pipeline avait livré à 10 h 15 sans cette étape, ce serait du déploiement continu.

Erreurs courantes

• Appeler "CD" le serveur de build. Sans tests automatisés ni étape de livraison reproductible, le logiciel n'est pas livrable à la demande.
• Reconstruire pour chaque environnement. Un artefact différent en production et en préproduction annule l'intérêt du pipeline.
• Branches de longue durée. Intégrer rarement rend chaque livraison volumineuse et risquée.
• Préparer les environnements à la main. Une préproduction qui dérive de la production cache les problèmes jusqu'au jour J. L'infrastructure as code aide.
• Ignorer la performance. Les tests fonctionnels passent alors qu'un changement ralentit l'application sous charge.

Livraison continue, tests de charge et supervision

Un build livrable doit aussi tenir la charge. La page tests de charge de LoadFocus décrit une GitHub Action qui lance un test de charge, lit le verdict réussi ou échoué et peut bloquer un déploiement quand un seuil est dépassé. Après la livraison, la supervision d'API indique si la production se comporte comme le pipeline le laissait prévoir. Pour des conseils pratiques sur les pipelines, voyez nos bonnes pratiques CI/CD (en anglais) et le guide du déploiement canary (en anglais).

Questions fréquentes

La livraison continue est-elle la même chose que le déploiement continu ?

Non. La livraison continue garde chaque changement dans un état livrable et laisse la décision de livrer aux personnes. Le déploiement continu met automatiquement en production chaque changement qui réussit le pipeline.

Faut-il d'abord de l'intégration continue ?

En pratique, oui. La livraison continue s'appuie sur l'intégration continue : les changements doivent être intégrés et testés souvent avant de franchir les étapes suivantes.

La livraison continue signifie-t-elle livrer plusieurs fois par jour ?

Non. Elle signifie que vous pouvez livrer à tout moment. La fréquence réelle est un choix métier.

Où placer les tests de charge dans le pipeline ?

Après le déploiement dans un environnement proche de la production, parmi les contrôles plus lents. Un seuil sur le temps de réponse ou le taux d'erreurs peut faire échouer le build avant la livraison.