Expliquez-moi la différence entre les déploiements blue green et canary, et quand vous choisiriez chacun.

Le blue green fait tourner deux environnements complets et bascule tout le trafic d'un coup, donc le retour arrière est instantané mais tous les utilisateurs rencontrent la nouvelle version au même moment. Le canary envoie une petite tranche de trafic réel vers la nouvelle version et la fait grossir pendant que vous surveillez les SLI, donc le rayon d'impact est faible mais le déploiement est plus lent. Prenez le blue green pour des bascules rapides et neutres vis-à-vis du schéma ; prenez le canary pour des changements de logique risqués à grande échelle.

Le blue green, ce sont deux piles complètes avec un aiguillage devant. Vous déployez sur celle qui est inactive, vous vérifiez, vous basculez le routeur, et si ça tourne mal vous rebasculez en quelques secondes. Le canary est progressif : 1% du trafic, puis 5, puis 25, en surveillant le taux d'erreur et la latence à chaque palier, avec un retour arrière automatique si la nouvelle version paraît pire que la référence. Je penche pour le canary dès que le risque est un changement de comportement subtil, parce que le blue green ne vous parle de la casse qu'une fois tout le monde dessus. Le blue green est très bien pour des remplacements d'infrastructure où le code ne change pas. Ce qui domine les deux, c'est la base de données. On appliquait expand and contract sur chaque changement de schéma, donc la nouvelle colonne part d'abord, les deux versions peuvent lire et écrire, et on ne supprime quoi que ce soit qu'une fois l'ancienne version complètement retirée. Sans ça, votre retour arrière instantané n'est pas réellement disponible, ce qui est une sale chose à découvrir en plein incident.