Ein Blue-Green Deployment ist eine Release-Strategie mit zwei identischen Produktionsumgebungen. Eine Umgebung (Blue) bedient den Live-Traffic, während die neue Version auf der anderen (Green) bereitgestellt und getestet wird. Anschließend wird der Traffic in einem Schritt auf Green umgeschaltet; das Zurückschalten auf Blue ermöglicht ein schnelles Rollback.
Was ein Blue-Green Deployment ist
Ein Blue-Green Deployment trennt das Installieren einer neuen Version von ihrer Freigabe für Nutzer. Sie betreiben zwei möglichst identische Produktionsumgebungen. Zu jedem Zeitpunkt erhält eine davon, etwa Blue, den gesamten Nutzer-Traffic. Das neue Release wird auf die ruhende Umgebung Green ausgerollt, dort aufgewärmt, per Smoke-Test geprüft und gegen echte Abhängigkeiten verifiziert. Ist das Team zufrieden, verschiebt eine Änderung an Router, Load Balancer oder DNS den Traffic von Blue auf Green. Blue bleibt in Bereitschaft: Geht etwas schief, wird einfach zurückgeschaltet.
Bekannt wurde die Technik unter anderem durch Martin Fowler, als Weg zu Releases nahezu ohne Ausfallzeit und zu einem Rollback, das weder Neubau noch erneutes Deployment erfordert. Nach einem erfolgreichen Release tauschen die Umgebungen die Rollen: Green ist nun live, Blue wird Ziel des nächsten Deployments.
So funktioniert das Umschalten
- Auf die ruhende Umgebung deployen. Green erhält den neuen Build, Blue bedient weiter.
- Verifizieren. Smoke-Tests, Health Checks und synthetische Transaktionen über einen internen oder Preview-Endpunkt gegen Green ausführen.
- Traffic umschalten. Target Group des Load Balancers, Selector des Kubernetes-Service, Ingress-Regel oder DNS ändern, sodass neue Requests bei Green landen.
- Beobachten. Fehlerrate, Latenz und Sättigung auf Green mit der Baseline vor dem Release vergleichen.
- Behalten oder zurückrollen. Bleiben die Signale gesund, wird Blue abgebaut oder wiederverwendet, sonst wird zurückgeschaltet.
In Kubernetes nutzt eine einfache Variante zwei Deployments mit Labels wie version: blue und version: green sowie einen Service, dessen Selector geändert wird. Werkzeuge wie Argo Rollouts formalisieren das mit einem aktiven und einem Preview-Service und optionaler automatischer Analyse vor der Freigabe. In der Cloud bieten etwa AWS CodeDeploy oder gewichtete Target Groups dasselbe Muster.
Blue-Green vs. Canary Deployment
| Aspekt | Blue-Green | Canary |
|---|---|---|
| Traffic-Verlagerung | Auf einmal (oder in sehr wenigen Schritten) | Schrittweise, z. B. 1 %, 10 %, 50 %, 100 % |
| Auswirkung eines fehlerhaften Release | Alle Nutzer bis zum Rollback | Nur der Canary-Anteil |
| Rollback | Zurückschalten, meist Sekunden | Canary-Gewicht auf null setzen |
| Infrastruktur | Zwei vollständige Umgebungen während des Release | Wenig Zusatzkapazität für den Canary |
| Aussagekraft der Signale | Sofort volle Produktionslast | Braucht genug Canary-Traffic zum Vergleich |
Viele Teams kombinieren beides: Green deployen, zunächst einen kleinen Canary-Anteil dorthin leiten und dann vollständig umschalten. Den schrittweisen Ansatz beschreibt der Eintrag Canary Deployment.
Was Sie beim Umschalten beobachten sollten
Ein Blue-Green-Wechsel ist nur so sicher wie die Signale, nach denen Sie ihn bewerten. Versehen Sie jeden Span und jede Metrik mit der ausgerollten Version, zum Beispiel über das OpenTelemetry-Resource-Attribut service.version, damit Dashboards Blue und Green trennen können. Sinnvolle Prüfungen in den ersten Minuten nach dem Umschalten:
- Fehlerrate und p95/p99-Latenz pro Endpunkt im Vergleich zum selben Zeitraum vor dem Release.
- Die Burn Rate des Error Budgets über ein kurzes Fenster, die zeigt, ob das Release das SLO gefährdet.
- Sättigungssignale wie Connection Pools, CPU und kalte Caches, die direkt nach dem Wechsel oft ansteigen.
- Business-Signale wie erfolgreiche Checkouts oder Logins, die funktionale Fehler mit HTTP 200 aufdecken.
Wo es kompliziert wird
Datenbanken. Meist teilen sich beide Umgebungen eine Datenbank, daher muss jede Schemaänderung mit alter und neuer Version gleichzeitig funktionieren. Die übliche Antwort ist das Expand-and-Contract-Muster: zuerst neue Spalten oder Tabellen abwärtskompatibel hinzufügen, dann den Code ausrollen und alte Strukturen erst in einem späteren Release entfernen. Sonst scheitert das „sofortige Rollback“, weil Blue nicht lesen kann, was Green geschrieben hat.
Langlebige Verbindungen und Sessions. WebSockets, gRPC-Streams und Sessions im Arbeitsspeicher bleiben nach dem Wechsel auf Blue. Planen Sie Connection Draining ein und halten Sie Session-Daten außerhalb der Instanzen.
Kosten und Drift. Zwei vollständige Umgebungen verdoppeln während des Release die Kapazität, und eine selten genutzte Umgebung driftet mit der Zeit von der Produktionskonfiguration weg. Infrastructure as Code hilft, beide identisch zu halten.
Hintergrundjobs und Consumer. Queue-Consumer und Scheduler in beiden Farben verarbeiten dieselbe Arbeit womöglich doppelt, wenn nicht nur die Live-Umgebung sie ausführen darf. Steuern Sie solche Komponenten über ein Feature Flag oder eine Konfiguration, die beim Umschalten mitwechselt.
DNS-Caching. Wer per DNS umschaltet, muss mit Resolvern und Clients rechnen, die alte Einträge länger als die TTL behalten. Für schnelle und vollständige Wechsel ist ein Load Balancer oder Ingress meist zuverlässiger.
Wie Obseria unterstützt
Das Deployment Tracking von Obseria erfasst jedes Release als Ereignis und vergleicht Fehlerrate, Latenz und SLO-Burn vor und nach dem Umschalten, getrennt nach service.version. Workflows in Obseria Automation können als Release Gate dienen und bei einer Verschlechterung von Green ein Rollback auslösen, mit SLOs als objektivem Kriterium.
