Das Prinzip ist unspektakulär: Es existieren zwei vollständige, produktionsfähige Umgebungen. Eine bedient den Verkehr, die andere steht bereit. Ein Release wird auf der stillen Umgebung installiert, dort geprüft — und erst dann wird der Verkehr umgeleitet.
Der Ablauf in fünf Schritten
- Bereitstellen: Die neue Version läuft auf der inaktiven Umgebung, mit produktionsnaher Konfiguration.
- Aufwärmen: Caches füllen, Verbindungen aufbauen, Startlast abfangen — sonst trifft der erste echte Verkehr eine kalte Umgebung.
- Prüfen: Automatisierte Kontrollen gegen die neue Umgebung, über einen separaten Zugang, ohne Nutzerverkehr.
- Umschalten: Der Router oder Load Balancer zeigt auf die neue Umgebung.
- Beobachten: Die alte Umgebung bleibt unangetastet stehen — als Rückweg, nicht als Reserve für die nächste Version.
Der letzte Punkt ist der, an dem in der Praxis gespart wird. Wer die alte Umgebung sofort für den nächsten Build überschreibt, hat kein Blue-Green mehr, sondern ein normales Deployment mit zusätzlichem Aufwand.
Blue-Green löst das Anwendungsproblem, nicht das Datenproblem. Beide Umgebungen greifen in aller Regel auf dieselbe Datenbank zu — und eine Migration, die das alte Schema unbrauchbar macht, macht den Rückweg unmöglich. Der Schalter am Router nützt nichts, wenn die Daten ihn nicht mitmachen.
Datenbanken: der Teil, der wirklich Arbeit macht
Damit ein Rollback funktioniert, müssen alte und neue Version dasselbe Schema gleichzeitig vertragen. Das erzwingt eine Disziplin, die unabhängig vom Deployment-Verfahren sinnvoll ist:
- Spalten werden zuerst hinzugefügt, nie im selben Release umbenannt oder entfernt.
- Neue Spalten sind zunächst optional und haben einen sinnvollen Standardwert.
- Die alte Version darf unbekannte Felder nicht als Fehler behandeln.
- Das Entfernen alter Felder erfolgt in einem späteren, eigenen Release.
Diese Reihenfolge — erweitern, umstellen, aufräumen — kostet ein zusätzliches Release, macht aber jeden Rückweg möglich. Sie ist der eigentliche Preis des Verfahrens.
Abgrenzung: Canary und Feature Flags
Blue-Green schaltet alles auf einmal um. Ein schrittweiser Rollout an einen wachsenden Anteil der Nutzer ist ein anderes Verfahren, und die Steuerung einzelner Funktionen im laufenden Betrieb wieder ein drittes. Die drei schließen sich nicht aus — sie beantworten verschiedene Fragen.
Wie sich Funktionen unabhängig vom Auslieferungszeitpunkt aktivieren lassen, beschreibt der Beitrag zu Feature Flags.
Was es kostet
Ehrlich: die doppelte Infrastruktur, zumindest für die Dauer des Wechsels. Bei zustandslosen Diensten in einer Cloud-Umgebung ist das überschaubar, weil die zweite Umgebung nur zeitweise existiert. Bei Systemen mit großem Datenbestand, langen Startzeiten oder Lizenzkosten pro Instanz kann der Aufwand den Nutzen übersteigen.
- Passt gut: zustandslose Dienste, klare Schnittstellen, automatisierte Prüfungen, häufige Releases.
- Passt schlecht: Systeme mit langlebigen Sitzungen im Arbeitsspeicher, teure Lizenzmodelle, seltene Releases mit großen Änderungen.
Konfiguration und Geheimnisse mitdenken
Zwei Umgebungen bedeuten zwei Konfigurationen — und genau dort entstehen die Fehler, die am schwersten zu finden sind. Ein abweichender Endpunkt, ein nicht übernommener Schlüssel, ein Wert, der beim manuellen Anlegen der zweiten Umgebung vergessen wurde: Das Ergebnis ist eine Version, die im Test funktioniert und nach dem Umschalten scheitert.
Der einzige belastbare Weg ist, beide Umgebungen aus derselben Quelle zu erzeugen und Unterschiede ausschließlich über einen benannten Parameter zu steuern. Was von Hand angelegt wird, driftet — nicht sofort, aber verlässlich innerhalb weniger Wochen.
Hintergrundprozesse und Warteschlangen
Der Verkehr lässt sich umschalten. Laufende Hintergrundarbeit nicht. Wenn beide Versionen gleichzeitig Aufträge aus derselben Warteschlange ziehen, muss die Nachricht von beiden verstanden werden — sonst bleiben Aufträge liegen oder werden doppelt verarbeitet.
Praktisch bewährt hat sich, geplante Aufgaben und Warteschlangen-Verarbeiter kurz vor dem Umschalten anzuhalten, den Wechsel durchzuführen und sie danach auf der neuen Umgebung wieder zu starten. Das kostet eine kurze Verzögerung in der Hintergrundverarbeitung und ist deutlich billiger als doppelt ausgeführte Aufträge.
Der eigentliche Gewinn
Er liegt nicht in der Ausfallzeit — die ist bei sauber gebauten Systemen ohnehin gering. Er liegt in der Entscheidung unter Druck. Wenn nach dem Umschalten etwas nicht stimmt, lautet die Frage nicht mehr „Wie reparieren wir das jetzt?“, sondern „Zurückschalten oder nachbessern?“. Die erste Frage kostet Stunden, die zweite Sekunden.