Blue/Green Deployment

Le Blue/Green Deployment est une stratégie de déploiement qui maintient deux environnements production identiques en parallèle : Blue (version actuelle live servant le traffic) et Green (nouvelle version déployée et validée). Le switch entre les deux est atomique (DNS update, load balancer target group swap, Kubernetes Service selector change) — instantané pour les nouveaux requests, avec possibilité de rollback immédiat en repointant vers Blue si problème détecté.

Workflow : (1) Blue est en production servant 100% traffic ; (2) déployer v2 sur Green (infra identique mais isolée, peut être un nouvel ASG, un nouveau Kubernetes Deployment, un nouveau stack CloudFormation) ; (3) smoke tests + integration tests sur Green via DNS interne ou hostname spécifique ; (4) switch traffic 100% Blue → 100% Green (LB swap, DNS update, K8s Service selector) ; (5) monitor Green ; (6) si OK, décommissionner Blue (ou garder N heures pour rollback rapide) ; (7) si KO, switch back Green → Blue en secondes, investigate.

Avantages : (1) downtime nul (théoriquement) ; (2) rollback instantané (vs rolling deployment où rollback nécessite re-deploy progressif) ; (3) test full version live avant traffic cutover (smoke test sur Green) ; (4) bonne fit pour stateless apps, microservices, web tier ; (5) integration native avec Route 53, ELB, Azure Traffic Manager, GCP Load Balancing.

Inconvénients : (1) coût 2x infra pendant la fenêtre de déploiement (peut être minimisé avec right-sizing temporaire et auto-scaling) ; (2) database migrations délicates — schemas doivent être backward et forward compatible (pattern expand-contract : étape 1 ajouter nouvelle colonne, déployer code écrivant les 2 anciens + nouveaux, étape 2 backfill, étape 3 lire seulement nouveau, étape 4 supprimer ancien) ; (3) stateful workloads (sessions, caches en mémoire) require session affinity ou external session store (Redis) ; (4) long-running connections (WebSocket, gRPC streaming) peuvent être brutalement coupées si Blue est décommissionné — nécessite drain period.

Variantes : (1) Symmetric Blue/Green — both environments full-size, switch 100% ; (2) Asymmetric Blue/Green — Green smaller, scale up before switch ; (3) Canary-then-Blue-Green — canary subset users on Green for hours, then full swap (combines benefits).

Outils : (1) AWS CodeDeploy supporte Blue/Green natif pour ECS, Lambda, EC2 ASG ; (2) Azure Web Apps Deployment Slots — slot Staging acts as Green, swap slot to Production = Blue/Green ; (3) Spinnaker — multi-cloud Blue/Green ; (4) Kubernetes — pas natif mais réalisable via 2 Deployments + Service selector swap, ou via tools comme Argo Rollouts/Flagger ; (5) Terraform — possible mais cumbersome (preferred for infra, not deployment strategy) ; (6) Cloud Foundry blue-green built-in ; (7) Heroku Pipelines Promotion approximate.

Cas d'usage idéaux : (1) e-commerce checkout pendant heures de pointe ; (2) APIs critiques avec SLA strict ; (3) apps avec downtime impossible business-wise. Évolution moderne : préférer Canary deployment pour réduire blast radius lors regression, garder Blue/Green pour cas spécifiques requiring atomic cutover.