Stratégies : big bang, rolling, bleu-vert

Prérequis : cours 4.3 (expand-then-contract) et 5.3 (ordre de déploiement).

Pourquoi

« Mettre en prod » n'est pas une commande, c'est une stratégie avec un coût et un risque. La choisir consciemment, c'est éviter la coupure surprise comme le rollback impossible.

Concepts

• Big bang : on redémarre tout d'un coup (pull && up -d), 5 à 30 s de coupure. Simple, prévisible : parfait en solo ou maintenance annoncée, avec backup frais avant.
• Rolling : conteneurs remplacés un par un derrière le proxy, pas de coupure si l'app supporte deux versions en parallèle (d'où les migrations compatibles).
• Bleu-vert : deux stacks complètes (bleue = actuelle, verte = nouvelle), bascule du proxy quand la verte est healthy, rollback = rebasculer. Coût : 2× ressources + données partagées à gérer (sinon la verte corrompt la bleue).
• Stateless : sans état conservé en mémoire (vu dans le cursus dev, HTTP) : n'importe quelle instance peut servir n'importe quelle requête — pré-requis du rolling serein.

Exemple : choisir

Cas réel

Rolling sur une app qui stocke les sessions en mémoire (stateful, l'inverse de stateless) : à chaque conteneur remplacé, ses users sont déconnectés — « pas de coupure » sur le papier, des centaines de déconnexions en pratique. D'où : sessions en base/cookie signé avant le rolling.

Pièges

• Bleu-vert sans penser aux données partagées : la verte écrit un schéma que la bleue ne comprend plus.
• Big bang sans fenêtre annoncée : même 30 s se remarquent — et s'expliquent après, pas avant.
• Choisir bleu-vert « pour faire sérieux » avec 2× le budget infra : la stratégie doit matcher le risque réel.

À retenir

Big bang assumé, rolling si stateless + compatible, bleu-vert pour les gros risques, données toujours pensées.