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

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

Continuous Delivery est la pratique d'ingénierie logicielle dans laquelle chaque changement de code progresse automatiquement à travers des étapes de build, test et validation jusqu'à atteindre un état prêt pour la production — et peut être déployé en production à tout moment d'un seul clic ou commande. CD est l'extension naturelle de Continuous Integration (CI) : CI s'assure que chaque commit est construit et testé ; CD s'assure que chaque commit qui passe est aussi packagé, déployé en staging, validé et prêt à être livré.

La distinction cruciale que chaque équipe devrait comprendre : Continuous Delivery ≠ Continuous Deployment. Continuous Delivery signifie que le changement est prêt à être livré ; les humains décident quand. Continuous Deployment signifie que le changement est réellement livré automatiquement sur CI vert. La plupart des équipes d'entreprise pratiquent CD (release à la demande) ; moins pratiquent Continuous Deployment (promotion automatisée vers la prod). Les deux s'abrègent en "CD" causant une confusion constante dans les entretiens et discussions d'architecture.

L'anatomie du pipeline CD

Un pipeline CD typique a ces étapes, chacune contrôlant la suivante :

1. Source. Déclenchement sur push vers main / fusion de PR. Pull source, calcul des métadonnées de commit.
2. Build. Compiler le code, installer les dépendances, construire les images de conteneur. Mettre en cache agressivement (cache npm, cache de couche Docker, cache Gradle).
3. Tests unitaires. Exécuter en parallèle ; viser sous 5 minutes. Fail-fast au premier test cassé.
4. Analyse statique. Linters, vérificateurs de types, scanners de sécurité (Snyk, Dependabot, SonarQube).
5. Tests d'intégration. Démarrer les dépendances (bases de données, services mock), lancer la suite d'intégration. 5-15 minutes typique.
6. Création d'artefact. Construire l'image de conteneur, la signer, la pousser au registre. Ou construire des binaires/packages statiques.
7. Déploiement vers staging. Auto-déploiement vers un environnement staging qui reflète la prod.
8. Smoke tests / E2E. Validation de chemin critique contre staging. Certaines équipes lancent aussi un test de charge ici.
9. Gate de production. Approbation manuelle (CD) ou promotion automatique (Continuous Deployment).
10. Déploiement de production. Blue/green, canary ou déploiement rolling. Surveiller les métriques après déploiement.
11. Validation post-déploiement. Smoke tests en prod. Auto-rollback en cas de régression.

Les quatre stratégies de déploiement que CD permet

• Blue/green. Déployer la nouvelle version ("green") aux côtés de l'ancienne ("blue") ; basculer le trafic instantanément. Rollback facile (rebasculer). Double l'infrastructure pendant la transition.
• Canary. Déployer à un petit % du trafic d'abord (1-5%) ; surveiller ; augmenter graduellement. Attrape les régressions avant le rollout complet. Par défaut de l'industrie pour les systèmes à fort trafic.
• Rolling. Remplacer les instances une à la fois. Pas besoin de logique de répartition de trafic ; rollout plus lent. Par défaut dans Kubernetes et la plupart des services gérés des plateformes cloud.
• Feature flags / dark launching. Déployer du code dans le noir, activer par utilisateur/cohorte via un service de flags. Découple déploiement et release. Voir feature flags.

Ce qui fait fonctionner CD en pratique

Patterns que les pipelines CD matures partagent :

• Développement basé sur le trunk. Branches de courte durée (1-2 jours max) fusionnées vers main. Pas de branches de fonctionnalités à longue durée qui divergent pendant des semaines.
• Tests automatisés complets. Si vous ne pouvez pas faire confiance à votre suite de tests, vous ne pouvez pas faire confiance à CD. Visez 80%+ de couverture de chemin critique.
• Artefacts immuables. Le même artefact se déploie en staging et prod. Pas de rebuilds entre environnements — trop risqué.
• Configuration externalisée. Config par environnement dans les variables d'environnement / service de config, pas cuite dans les images.
• Discipline de migration de base de données. Les migrations sont compatibles vers l'avant ; l'ancien code continue de fonctionner avec le nouveau schéma pendant au moins un cycle de déploiement (pattern expand-contract).
• Observabilité. Métriques, logs, traces en production. Auto-rollback se déclenche sur régression de taux d'erreur / latence.
• Pipeline rapide. Les déploiements prennent <15 minutes. Les pipelines lents signifient moins de releases plus grandes — exactement le mode d'échec que CD est censé prévenir.

Outils courants de pipeline CD

• GitHub Actions — dominant pour les projets sur GitHub. Écosystème marketplace ; YAML .github/workflows.
• GitLab CI/CD — première classe pour GitLab. .gitlab-ci.yml ; registre de conteneurs intégré.
• CircleCI, Buildkite, Jenkins — services CI tiers. Jenkins est legacy mais omniprésent en entreprise.
• Argo CD, Flux — contrôleurs GitOps pour Kubernetes. Déploiements basés sur pull synchronisés depuis Git.
• Spinnaker, Harness, Octopus — plateformes complètes d'orchestration de déploiement. Multi-cloud, pipelines complexes.
• AWS CodePipeline, Azure Pipelines, Google Cloud Build — pipelines natifs des fournisseurs cloud.

Anti-patterns courants de CD

• Le "gate manuel pour toujours". Le pipeline CD se termine en staging parce que personne ne fait confiance aux déploiements en production. Soit corrigez le problème de confiance (meilleurs tests, observabilité, rollback), soit admettez que vous n'avez pas de CD.
• Environnements basés sur les branches. Code différent sur staging vs. prod ("cette branche se déploie en staging"). Le drift s'accumule ; staging passe mais prod échoue. Livrez seulement depuis main.
• Déploiements nécessitant une coordination hors-bande. Quelqu'un doit mettre à jour un fichier de config dans un autre repo ; une autre équipe doit rebooter un service. CD ne survit pas à ça.
• Tests d'intégration fourre-tout en prod. Les smoke tests devraient être bon marché et rapides. Si votre validation post-déploiement prend 30 minutes, les déploiements s'accumulent.
• Pas d'exercice de rollback. La première fois que vous exercez le chemin de rollback, c'est pendant une vraie panne. Pratiquez les rollbacks régulièrement.
• Tests CI passant mais pas exécutés sur l'artefact de déploiement. Facile de dériver entre ce que CI teste et ce qui est livré. Construisez une fois, testez l'artefact, déployez l'artefact — mêmes bytes partout.

FAQ : Continuous Delivery

Quelle est la différence entre CI, CD et Continuous Deployment ?

CI (Continuous Integration) : chaque commit construit + teste. CD (Continuous Delivery) : chaque commit atteint aussi un état déployable, prêt à être livré à la demande. Continuous Deployment : chaque commit qui passe auto-livre en prod. CD est nécessaire pour Continuous Deployment mais pas la même chose.

Ai-je besoin de Kubernetes pour CD ?

Non. CD fonctionne avec VMs, conteneurs, serverless, même PHP déployé par FTP. Kubernetes rend certains patterns plus faciles (rolling updates) mais n'est pas requis.

Combien de temps devrait prendre un pipeline CD ?

Benchmarks de l'industrie (DORA, Accelerate) : les équipes élite déploient en <1 heure depuis le commit. Équipes haute performance : 1-24 heures. Pipelines >24 heures indiquent des problèmes avec l'infrastructure de tests, dépendances ou complexité organisationnelle.

CD peut-il fonctionner dans les industries réglementées ?

Oui — fintech, santé, gouvernement exécutent tous CD. Le pipeline CD devient la trace auditable (chaque changement est construit, testé, signé, déployé via des étapes reproductibles avec logs complets). Souvent plus auditable que les processus de déploiement manuels.

Et les changements de base de données ?

La partie la plus difficile. Utilisez les migrations expand-contract (ajouter nouvelle colonne → déployer code qui écrit aux deux → migrer anciennes données → déployer code qui lit nouvelle colonne → supprimer ancienne colonne), feature flags et outils comme Flyway ou Liquibase pour versionner les migrations à côté du code.

Comment mesurer la qualité du pipeline CD ?

Les quatre métriques clés de DORA : fréquence de déploiement, lead time pour les changements, taux d'échec des changements, temps moyen de restauration. Tracez celles-ci au fil du temps. Plus rapide + plus sûr = meilleur CD.

Et le CD microservices ?

Chaque service a son propre pipeline ; les déploiements sont indépendants. Coordonnez les changements d'API cassants via expand-contract ou versioning. Évitez les monolithes distribués où N services doivent se déployer ensemble.

Comment LoadFocus se rapporte aux pipelines CD

L'étape la plus sautée dans les pipelines CD est la validation de performance. Les tests fonctionnels passent ; la latence régresse de 50% sur le trafic de production. Les tests de charge d'API LoadFocus s'intègrent dans les pipelines CI/CD via des appels API — faites échouer le build si la latence p95 dépasse votre seuil. Le monitoring synthétique valide que les Core Web Vitals restent sains après chaque déploiement, attrapant les régressions frontend avant que les utilisateurs ne le remarquent.