Erklär mir den Unterschied zwischen Blue-Green- und Canary-Deployments und wann du was wählst.

Blue Green betreibt zwei komplette Umgebungen und schaltet den Traffic auf einen Schlag um, das Rollback ist also sofort, aber jeder User trifft im selben Moment auf die neue Version. Canary schickt einen kleinen Anteil echten Traffics auf die neue Version und erhöht ihn, während du die SLIs beobachtest, der Blast Radius ist also klein, aber das Rollout langsamer. Nimm Blue Green für schnelle, schemaneutrale Umschaltungen, nimm Canary für riskante Logikänderungen im großen Maßstab.

Blue Green sind zwei komplette Stacks mit einem Schalter davor. Du deployst auf den untätigen, verifizierst, kippst den Router, und wenn es schiefgeht, kippst du in Sekunden zurück. Canary ist progressiv: 1% des Traffics, dann 5, dann 25, mit Blick auf Fehlerrate und Latenz bei jedem Schritt und einem automatischen Rollback, wenn die neue Version schlechter aussieht als die Baseline. Ich tendiere zu Canary, wenn das Risiko in subtilen Verhaltensänderungen liegt, denn Blue Green sagt dir erst etwas über den Bruch, wenn schon alle drauf sind. Blue Green ist super für Umschaltungen auf Infrastrukturebene, bei denen der Code unverändert bleibt. Was beides dominiert, ist die Datenbank. Wir haben bei jeder Schemaänderung Expand and Contract gefahren, die neue Spalte geht also zuerst live, beide Versionen können lesen und schreiben, und erst wenn die alte Version komplett ausgemustert ist, wird etwas gelöscht. Ohne das steht dein sofortiges Rollback gar nicht wirklich zur Verfügung, und das ist eine hässliche Erkenntnis mitten im Incident.