Blue-Green Deployment

Deux environnements identiques en parallèle, un routeur de trafic qui bascule de l'un à l'autre — le pattern de déploiement infrastructure sans downtime, complémentaire des feature flags applicatifs.

Problème

Déployer une nouvelle version d'un gateway AS2 ou d'un parseur EDIFACT central impose habituellement : stop du processus, upgrade des binaires, restart, smoke test. Pendant ce cycle (5-30 min), le service est indisponible — les partenaires reçoivent des timeouts AS2, les MDNs ne reviennent pas, des retries s'accumulent. Pire : si la nouvelle version a un bug bloquant, le retour arrière demande de redéployer l'ancienne version, soit 10-30 min supplémentaires. Pour un hub EDI tier-1 avec SLA < 5 min d'indisponibilité, ce mode opératoire est rédhibitoire.

Forces

L'indisponibilité doit être minimale : idéalement de l'ordre de la seconde, par bascule de routage.
Le rollback doit être instantané : le retour arrière ne doit pas demander un redéploiement.
La double infrastructure a un coût : maintenir deux environnements complets double les ressources pendant la fenêtre de bascule.
L'état partagé doit être géré : DB, message broker, file storage — typiquement partagés entre blue et green, donc compatibles avec les deux versions.
Les sessions actives doivent être drainées : les MDN asynchrones en cours doivent arriver sur la bonne version.

Solution

Provisionner deux environnements complets : blue (actuellement actif, version v1.0) et green (nouvellement déployé, version v2.0). Les deux partagent les ressources stateful (DB, Kafka, S3) mais sont sinon isolés. La couche de routage (DNS, load balancer, service mesh) pointe vers blue. Quand green est prêt : tests synthétiques sur green sans trafic réel, puis bascule du routeur vers green en une opération atomique. Si OK, blue devient idle (et sera mis à jour pour la prochaine bascule). Si KO, retour instantané sur blue. Le drainage des sessions actives nécessite généralement une fenêtre courte (30-60s) de connection draining.

Deux environnements parallèles, un routeur de trafic :

   ┌──────────────────┐
   │ Partenaire AS2   │
   │ envoie INVOIC    │
   └─────────┬────────┘
             │
             ▼
   ┌──────────────────────┐
   │ Load Balancer / DNS  │  ← bascule atomique
   │ pointe sur : BLUE    │
   └────────┬─────────────┘
            │
   ┌────────┴────────┐
   ▼                 ▼
┌──────┐         ┌──────┐
│ BLUE │         │ GREEN│
│ v1.0 │         │ v2.0 │
│ (actif)        │ (idle, mais up)
└──────┘         └──────┘
   │                 │
   ▼                 ▼
identique DB, identique config Kafka, identique partner master

Avant bascule : tests sur GREEN avec trafic synthétique.
Bascule : LB pointe sur GREEN → trafic réel y arrive en 1s.
Rollback : LB pointe sur BLUE → trafic revient en 1s.
Après stabilisation : BLUE devient nouveau "GREEN" pour le prochain rollout.

Implémentation EDI

Cas concret : upgrade de IBM Sterling B2B Integrator v6.2 vers v6.3, qui modifie la lib AS2 sous-jacente. Sans Blue-Green : fenêtre de maintenance d'1h, communication partenaires 1 semaine avant, risque résiduel élevé. Avec Blue-Green : deux clusters Sterling sont opérationnels en parallèle, partageant la DB Oracle et le stockage SAN. Le load balancer F5 BIG-IP route le trafic AS2/HTTPS sur le cluster blue (v6.2). On déploie green (v6.3), on configure les Trading Partners identiquement, on injecte en green des messages synthétiques pour valider parsing, MDN, archivage. Puis bascule du LB : set rule /Common/edi_router { ... pool green_pool ... }. Le trafic bascule en 1-2s, les sessions en cours drainent en 30s. Surveillance intense pendant 24h, puis blue est upgradé à v6.3 et devient le nouveau green idle. Outils : AWS Elastic Beanstalk Blue-Green natif, Azure DevOps deployment slots, GitLab CI Blue-Green script, HashiCorp Nomad/Consul, Kubernetes via deux Services pointant sur deux Deployments + bascule du Service.

Anti-patterns

Schéma DB incompatible : si green nécessite une migration de schéma incompatible avec blue, on perd l'instant-rollback. Solution : migrations toujours backward compatible (ajouts only, pas de drop).
State local par environnement : blue et green doivent partager le state, sinon les MDN/receipts en cours sur blue se perdent à la bascule.
Pas de tests synthétiques sur green : bascule du trafic réel sur un green non vérifié = roulette russe.
Pas de drainage de sessions : bascule brutale coupe les connexions AS2 en cours, génère des retries en masse.
Double dépense permanente : laisser blue et green tous deux actifs (et non l'un idle) double le coût sans bénéfice.

Patterns liés

Canary Release — variante progressive, là où Blue-Green est tout-ou-rien.
Feature Flag — pattern applicatif complémentaire de Blue-Green infrastructure.
Dark Launch — variante où green reçoit du trafic dupliqué sans retour utilisateur.
Circuit Breaker — protection runtime indépendante.

Sources

Fowler M. — BlueGreenDeployment (martinfowler.com, 2010). La définition canonique du pattern. martinfowler.com — BlueGreenDeployment
Humble J., Farley D. — Continuous Delivery, Addison-Wesley 2010. Chapitre 10 §3 — les techniques de déploiement zero-downtime, dont blue-green.
Nygard M. — Release It! Design and Deploy Production-Ready Software, Pragmatic Bookshelf, 2e éd. 2018. Discussion des stratégies de mise en production résiliente.
AWS Architecture Center — Blue/Green Deployments on AWS. Documentation et patterns d'implémentation cloud. docs.aws.amazon.com — Blue/Green Deployments
Beda K., Burns B., Hightower K. — Kubernetes Up & Running, O'Reilly 2022 (3e éd.). Chapitre sur les Services et leur usage en blue-green.
Google Cloud Architecture Center — Blue/green deployment patterns on Google Cloud. cloud.google.com — deployment-strategies

Fondamentaux

Standards

Messages phares

Outils