04

🚀 Continuous Delivery (CD)

Deploy Strategies & GitOps

"Le déploiement n'est plus un événement stressant du vendredi soir qu'on redoute, mais une routine invisible. Le CD transforme la mise en production en un non-événement absolu et fluide."

🚦 Analogie : Le Changement de Roue (Déploiement)

Rolling Update : On change les roues d'un train les unes après les autres en pleine course. L'arrêt est invisible, mais les changements sont continus.
Blue/Green : On prépare un 2ème train identique sur une voie parallèle, on bascule l'aiguillage magiquement pour tous les passagers instantanément, et on démonte l'ancien train.

⚠️ Rappel : CI vs CD

L'usine de montage assemble et crashe-teste la voiture (CI). Le camion transporte la voiture parfaite chez le concessionnaire (CD - Delivery). Mais le client ne la conduit que lorsqu'on décide de lui donner officiellement les clés (Déploiement Continue).

📖 CI vs CD vs Continuous Deployment : Ne les confondez plus !

Beaucoup utilisent ces termes comme des synonymes, mais ils représentent des étapes de maturité différentes :

  • Continuous Integration (CI) : Le code est buildé et testé automatiquement à chaque commit.
  • Continuous Delivery (CD) : Le code est prêt à être déployé en production à TOUT MOMENT, mais le clic final est manuel (décision business).
  • Continuous Deployment : Chaque commit qui passe les tests est déployé automatiquement en production, sans intervention humaine.

En CD, la production est un simple artefact que l'on promeut.

💡 Le saviez-vous ? Déployer un Vendredi après-midi ?

Dans les entreprises traditionnelles, c'est interdit (le "Friday Deploy" est tabou). En DevOps mature avec CD, c'est un non-événement.

Pourquoi ? Parce que les outils de CD permettent un Rollback instantané et une isolation du trafic (Canary). Si le déploiement de 17h échoue, le système revient en arrière automatiquement en 30 secondes sans que les Ops ne sacrifient leur week-end.

📊 A. Comparatif des Stratégies

Stratégie Risque Rollback Coût Cas d'usage
Rolling Update Moyen Lent Faible Défaut K8s
Blue/Green Faible Instant 2x infra Critique, besoin rollback rapide
Canary Faible Rapide Moyen Test sur users réels
Recreate Élevé Lent Faible Dev, non-prod

🎮 Simulateur de Déploiement (Cliquez pour tester)

Sélectionnez une stratégie...
Prêt.

🔍 Stratégies de Déploiement Avancées

🌑 Dark Launching (Feature Flags)
Le code est déployé en prod mais reste invisible pour les utilisateurs. On l'active via une config (Feature Flag) pour certains segments d'utilisateurs. Permet de tester la performance en prod sans risque métier.
👤 Shadow Deployment
Le trafic réel est dupliqué vers la nouvelle version, mais les réponses ne sont pas renvoyées aux clients. On compare les sorties de V1 et V2 pour s'assurer que V2 est stable (parfait pour les migrations de DB ou refactos complexes).

📊 Cas d'étude : Amazon - Un déploiement toutes les 11.6 secondes

11.6s Déploiement moyen
10k+ Serveurs mis à jour simultanément
0 Downtime toléré

Contexte : En 2001, Amazon était un monolithe. Un changement mineur pouvait bloquer des centaines de développeurs pendant des semaines.

Transformation :

  1. Two-Pizza Teams : De petites équipes autonomes de 6-10 personnes gèrent un service de bout en bout.
  2. Apollo : Création de leur propre outil de CD (devenu AWS CodeDeploy) pour automatiser chaque étape.
  3. Service-Oriented Architecture (SOA) : Chaque service cache sa complexité derrière une API.

Résultat : En 2011 (déjà !), Amazon effectuait 1.079 déploiements par heure en moyenne sur ses jours de semaine. Aujourd'hui, ce chiffre est bien plus élevé.

🔄 À Retenir - Continuous Delivery

  • Automatisation Totale : Si un humain intervient manuellement, ce n'est pas du CD.
  • Infrastructure-as-Code : Le déploiement doit inclure les changements d'infra (VPC, DB, LB).
  • Observabilité : On ne déploie pas sans Dashboard. Si les erreurs montent, on rollback.
  • Rollback Automatique : Le succès d'un déploiement n'est pas le "Finish", c'est le maintien des métriques stables.

🔄 B. Promotion d'Environnements

🧪
Dev
→
🔍
Staging
→
🚀
Production
Règle d'or : Ce qui marche en Staging DOIT marcher en Prod (même image, même config externalisée).

🔄 C. GitOps - Git comme Source de Vérité

GitOps est une évolution du CD où l'état désiré de l'infrastructure et des applications est déclaré dans Git, et un agent automatique synchronise continuellement l'état réel du cluster avec ce qui est dans Git.

"If it's not in Git, it doesn't exist in production."

🔱 ArgoCD

  • Pull-based : Argo surveille Git et applique les changements sur K8s
  • Web UI : Dashboard visuel de l'état de sync
  • Auto-sync : Peut corriger automatiquement les drifts
  • RBAC : Contrôle d'accès granulaire par app/projet
  • Idéal pour : Multi-tenant, équipes multiples

🌊 FluxCD

  • GitOps Toolkit : Composable, modulaire
  • Multi-source : Git, Helm repos, OCI registries
  • Image automation : Met à jour Git quand une nouvelle image est push
  • Progressive delivery : Intégré avec Flagger (Canary)
  • Idéal pour : Pipelines complexes, automatisation poussée
argocd-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/repo
    targetRevision: main
    path: k8s/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # Supprimer ressources obsolètes
      selfHeal: true   # Corriger les drifts manuels
🔒 Avantage Sécurité GitOps
Avec GitOps, les développeurs ne déploient plus directement sur le cluster (pas de kubectl apply). Ils font une PR sur Git. Cela crée un audit trail complet et permet des approvals formels avant tout déploiement en production.

🚩 D. Feature Flags & Progressive Delivery

🎚️ Feature Toggles

Déployez le code en prod, mais activez la fonctionnalité seulement pour certains utilisateurs via une configuration externe.

  • Kill Switch : Désactiver une feature cassée sans redéployer
  • A/B Testing : 50% users version A, 50% version B
  • Canary Users : Beta testers internes d'abord
  • Gradual Rollout : 5% → 25% → 100%
feature-flag.js
const featureEnabled = await launchDarkly
  .variation('new-checkout', user, false);

if (featureEnabled) {
  // Nouvelle expérience checkout
  return renderNewCheckout();
} else {
  // Ancienne version stable
  return renderOldCheckout();
}
⚠️ Attention : Dette Technique Les feature flags doivent être temporaires. Si vous ne les nettoyez pas après validation, votre code devient un spaghetti de if/else impossibles à maintenir.

⏮️ E. Stratégies de Rollback

Scénario Stratégie Défi
App Stateless Rollback image K8s instantané Aucun
App + Migration DB Backward-compatible migrations Schéma doit supporter V1 et V2
Breaking change DB Blue/Green avec DB snapshot Coûteux, perte de données post-deploy
Feature Flag activée Toggle OFF via dashboard Instant, sans redéploiement
🗄️ Migrations de Base de Données
Règle d'or : toute migration doit être forward ET backward compatible. Exemple : Ajouter une colonne ? Rendez-la NULL d'abord. Supprimer une colonne ? Laissez-la 2-3 versions avant de la drop réellement (expand/contract pattern).

🛑 Troubleshooting : Le Rollback qui aggrave la situation

  • Symptôme : La nouvelle version plante en Prod. Vous lancez un Rollback sur la version précédente, mais l'application crashe complètement cette fois-ci !
  • Diagnostic : Le code de la V2 a modifié le schéma de la base de données (ajout d'une contrainte NOT NULL, renommage d'une table) rendant le code de la V1 incompatible avec la nouvelle structure de données.
  • Remède : Découplez les changements de schéma des changements de code applicatif. Déployez le nouveau schéma d'abord de manière compatible (voir pattern expand/contract), puis le code V2 ensuite. Si V2 plante, V1 fonctionnera toujours avec le schéma étendu.

📊 Cas d'étude : Netflix - Spinnaker, le CD à l'échelle mondiale

4000+ Déploiements/jour
190+ Pays desservis
0 Downtime autorisé

Contexte : Netflix sert 220M+ abonnés mondiaux avec des pics massifs (ex: lancement Stranger Things). Un déploiement raté = millions de $ perdus.

Solution : Netflix a créé Spinnaker, un outil CD open-source multi-cloud.

  1. Canary Analysis automatique : Compare les métriques (latence, erreurs) entre Canary et Baseline. Si divergence > seuil, rollback auto.
  2. Red/Black Deploy : Variante de Blue/Green adaptée à AWS avec ELB switching.
  3. Chaos Engineering : Simian Army (Chaos Monkey) teste la résilience en tuant des instances aléatoirement, même en prod.

Résultat : Netflix peut déployer une nouvelle version en 16 minutes à l'échelle mondiale avec un taux d'échec < 0.01%.

📊 Cas d'étude : Etsy - "Deploy on Day One"

50+ Déploiements/jour
Day 1 Premier deploy d'un nouveau dev
15min Temps moyen commit → prod

Philosophie : Chez Etsy, un nouveau développeur doit déployer en production le premier jour. Cela force la compagnie à avoir un pipeline CD ultra-safe et accessible.

Pratiques clés :

  1. Feature Flags partout : Aucun code ne va en prod sans flag. Les juniors peuvent déployer sans risque.
  2. Dashboards en temps réel : Chaque développeur suit les métriques métier post-deploy (taux de conversion, erreurs).
  3. Try/Buy/Build : Prioriser les outils existants avant de construire.

Impact culturel : Les développeurs se sentent responsables du code en production dès J+1, ce qui renforce la qualité et la confiance.

🔄 À Retenir - Continuous Delivery

  • Automatisation Totale : Si un humain intervient manuellement, ce n'est pas du CD.
  • Infrastructure-as-Code : Le déploiement doit inclure les changements d'infra (VPC, DB, LB).
  • Observabilité : On ne déploie pas sans Dashboard. Si les erreurs montent, on rollback.
  • Rollback Automatique : Le succès d'un déploiement n'est pas le "Finish", c'est le maintien des métriques stables.
  • GitOps : Git devient la source de vérité unique. Audit, sécurité, traçabilité garantis.
  • Feature Flags : Séparez le déploiement de code (deploy) de l'activation de fonctionnalité (release).
← Accueil