Wie funktioniert Blue-Green Deployment?
Beim Blue-Green Deployment existieren zwei identische Produktionsumgebungen — Blue (aktiv) und Green (Standby). Ein neues Release wird auf die inaktive Umgebung deployt und getestet. Durch Umschalten des Load Balancers wird die neue Version live — bei Problemen kann sofort zurückgeschaltet werden.
Ist Blue-Green Deployment bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Blue-Green Deployment löst das Problem der Ausfallzeit beim Release durch Redundanz. Es existieren zwei vollständig funktionsfähige, identische Produktionsumgebungen. Eine ist aktiv und bedient den gesamten Live-Traffic (Blue), die andere steht bereit (Green). Eine neue Version wird vollständig auf die inaktive Umgebung deployt und dort getestet, während die aktive ungestört weiterläuft.
Der eigentliche Release ist dann ein einziger, schneller Schritt: Der Load Balancer oder Router schwenkt den Traffic von Blue auf Green um. Die neue Version ist sofort und vollständig live. Tritt ein Problem auf, ist der Rollback ebenso schnell — ein erneutes Umschalten zurück auf die alte Umgebung, die unverändert bereitsteht.
Der Hauptvorteil ist nahezu unterbrechungsfreier Betrieb mit sehr schnellem, risikoarmem Rollback. Der Preis dafür ist Ressourcenaufwand: Es müssen zeitweise zwei vollständige Produktionsumgebungen vorgehalten werden. In Cloud-Umgebungen mit elastischer Skalierung ist das gut beherrschbar, bei fester On-Premise-Hardware oder in OT-Umgebungen kann der doppelte Ressourcenbedarf zur Hürde werden.
Eine wichtige Herausforderung ist der Umgang mit Zustand, insbesondere Datenbanken. Wenn beide Umgebungen auf dieselbe Datenbank zugreifen, müssen Schema-Änderungen rückwärtskompatibel sein, damit ein Rollback nicht an inkompatiblen Datenstrukturen scheitert. Hier unterscheidet sich Blue-Green deutlich vom Canary Release, der schrittweise statt vollständig umschaltet.
In Kubernetes-Umgebungen ist der Ablauf 2026 weitgehend automatisiert: Werkzeuge wie Argo Rollouts bilden Blue-Green als eigene Strategie ab, halten einen Active- und einen Preview-Service parallel vor und schalten den Traffic erst um, wenn definierte Analysen — etwa Fehlerrate und Latenz gegen Prometheus — bestanden sind. Der früher manuelle Load-Balancer-Schwenk wird damit zu einem versionierten, wiederholbaren Pipeline-Schritt, inklusive automatischem Rollback bei Schwellwert-Verletzung.
Unterbrechungsfreies Release eines Kundenportals
Ein Industrieunternehmen deployt sein B2B-Portal über Blue-Green. Die neue Version läuft vollständig auf der Green-Umgebung, wird intern abgenommen, und der Go-Live ist ein Traffic-Switch in Sekunden — ohne Wartungsfenster für die Kunden.
Schneller Rollback nach Produktionsfehler
Nach dem Umschalten meldet das Monitoring eines Fertigungsbetriebs erhöhte Fehlerraten in der neuen Version. Das Team schwenkt den Load Balancer in unter einer Minute zurück auf die alte Umgebung, die unverändert lief — der Fehler ist verschwunden, bevor der erste Kunde anruft.
- Was unterscheidet Blue-Green Deployment vom Canary Release?
- Blue-Green schaltet den gesamten Traffic auf einmal zwischen zwei kompletten Umgebungen um. Canary leitet zunächst nur einen kleinen Prozentsatz auf die neue Version und steigert ihn schrittweise. Blue-Green ist binär, Canary graduell.
- Wie gehe ich bei Blue-Green mit Datenbank-Migrationen um?
- Schema-Änderungen sollten rückwärtskompatibel gestaltet werden, sodass alte und neue Anwendungsversion gegen dasselbe Schema laufen können. So bleibt ein schneller Rollback möglich, ohne dass Datenstrukturen den Wechsel blockieren.
- Lohnt sich Blue-Green trotz des doppelten Ressourcenbedarfs?
- Wenn niedrige Ausfallzeit und schneller, sicherer Rollback geschäftskritisch sind, ja. In elastischen Cloud-Umgebungen ist der doppelte Bedarf nur temporär. Bei knapper, fester Hardware kann ein Rolling Update oder Canary die ressourcenschonendere Wahl sein.
- Was ist der Unterschied zwischen Blue-Green Deployment und Rolling Update?
- Ein Rolling Update tauscht Instanzen nacheinander aus — alte und neue Version laufen minutenlang gemischt, ein Rollback dauert entsprechend lange. Blue-Green hält zwei komplette Umgebungen vor und schaltet den gesamten Traffic in einem Schritt um. Das kostet doppelte Ressourcen, liefert dafür einen eindeutigen Zustand und einen Rollback in Sekunden.
- Wie setze ich Blue-Green Deployment in Kubernetes um?
- Mit Argo Rollouts ersetzen Sie das Standard-Deployment durch eine Rollout-Ressource mit blueGreen-Strategie: Ein Active-Service bedient den Live-Traffic, ein Preview-Service die neue Version. Nach bestandener Analyse oder manueller Freigabe promotet Argo Rollouts die neue Version, und der Traffic wechselt vollständig — inklusive automatischem Rollback bei Fehlern.
Wo steht Ihr Team bei Blue-Green Deployment?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance