Blue-Green Deployment

DevOps 🟡 Mid

Définition

Stratégie de déploiement maintenant deux environnements identiques (blue=actif, green=nouvelle version). Le switch est instantané via le load balancer.

Analogie

Préparer un deuxième plateau repas en cuisine puis échanger les plateaux sur la table d'un coup.

Exemple de code

# 1. Déployer la nouvelle version sur green
# 2. Tester green
# 3. Basculer le trafic
aws elbv2 modify-listener \
  --listener-arn $ARN \
  --default-actions TargetGroupArn=$GREEN_TG
# 4. L'ancien blue devient le prochain green

Cas d'usage

Déploiement zéro-downtime avec rollback instantané en cas de problème.

Anti-pattern

Pas de test sur green avant le switch : le bug arrive directement en prod.

Termes liés

#devops#scaling#interview

En entretien

Explique-moi le principe du blue-green deployment.
On maintient deux environnements identiques, blue (actif) et green (nouvelle version), et le switch se fait instantanément via le load balancer. C'est comme préparer un deuxième plateau repas en cuisine puis échanger les plateaux sur la table d'un coup.
Quel est l'intérêt principal de cette stratégie par rapport à un déploiement classique ?
Elle permet un déploiement zéro-downtime avec un rollback instantané en cas de problème, puisqu'il suffit de rebasculer le trafic sur l'ancien environnement. Le switch se fait par exemple via un appel comme aws elbv2 modify-listener pour changer le target group par défaut.
Quelle erreur peut ruiner un déploiement blue-green ?
Ne pas tester green avant de basculer le trafic : le bug part alors directement en prod. Il faut valider green après déploiement et avant le switch du load balancer.

Fiche mise à jour le 2026-09-27