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.
Auch bekannt als: Blue/Green Deployment · Blau-Grün-Deployment · Blue Green
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.
Der Ablauf hat vier Schritte. Blue ist die aktive Produktionsumgebung und bedient den gesamten Traffic, Green ist eine identische zweite Umgebung ohne Nutzer. Das Team deployt die neue Version auf Green und testet sie dort, während Blue ungestört weiterläuft. Dann schwenkt der Load Balancer oder Router den Traffic in einem Schritt auf Green. Blue bleibt unverändert stehen, bis die neue Version sich bewährt hat. Martin Fowler hat das Muster 2010 unter diesem Namen beschrieben.
Der Rollback ist derselbe Schritt in umgekehrter Richtung. Meldet das Monitoring nach dem Umschalten Fehler, schwenkt der Router zurück auf Blue, das mit der alten Version noch läuft. Es muss nichts neu gebaut oder deployt werden, deshalb dauert der Rückweg Sekunden bis wenige Minuten.
Die Abgrenzung zu den anderen Strategien liegt in der Art des Umschaltens. Ein Rolling Update, in Kubernetes die Standardstrategie, tauscht Instanzen nacheinander aus, und für einige Minuten laufen alte und neue Version gemischt. Ein Canary Release gibt der neuen Version zuerst nur einen kleinen Anteil des Traffics. Blue-Green schaltet alles auf einmal um und hat dafür zu jedem Zeitpunkt einen eindeutigen Zustand.
Der Preis ist Kapazität. Für die Dauer des Wechsels laufen zwei vollständige Produktionsumgebungen. In der Cloud mit elastischer Skalierung ist das eine Frage von Stunden an Rechenzeit. Bei fester On-Premise-Hardware oder in OT-Umgebungen, wo eine zweite Umgebung eine zweite Steuerung bedeuten würde, ist es oft das Ausschlusskriterium.
Der ehrlichste Stolperstein ist die Datenbank. Teilen sich Blue und Green eine Datenbank, muss jede Schema-Änderung mit beiden Versionen funktionieren, sonst scheitert der Rollback an Datenstrukturen, die die alte Version nicht lesen kann. Die übliche Lösung trennt Migration und Release. Zuerst geht eine rückwärtskompatible Schema-Änderung live, danach die neue Anwendungsversion, und alte Spalten entfernt ein späteres Release. In Kubernetes automatisieren Werkzeuge wie Argo Rollouts den Umschaltvorgang. Sie halten einen Active- und einen Preview-Service vor und schalten erst um, wenn Analysen gegen Fehlerrate und Latenz bestanden sind.
Kundenportal geht ohne Wartungsfenster live
Ein Industrieunternehmen kündigte Releases seines B2B-Portals früher mit einem Wartungsfenster am Samstag an. Heute läuft die neue Version vorab vollständig auf der Green-Umgebung und wird dort intern abgenommen. Der Go-Live ist ein Traffic-Switch unter der Woche, den die Kunden nicht bemerken.
Rollback in unter einer Minute nach steigender Fehlerrate
Kurz nach dem Umschalten meldet das Monitoring eines Fertigungsbetriebs steigende Fehlerraten in der neuen Version. Das Team schwenkt den Load Balancer zurück auf die alte Umgebung, die unverändert weiterlief. Nach weniger als einer Minute ist der Fehler weg, und die Analyse findet am nächsten Morgen ohne Zeitdruck statt.
Welche Deployment-Strategie passt zu Ihrem Risiko?
Blue-Green, Canary oder Rolling — die richtige Strategie hängt an Ihrem Risikoprofil und Ihrem Infrastruktur-Spielraum. Zwei Klicks zeigen, was zu Ihnen passt.
Was ist Ihnen beim Ausrollen am wichtigsten?
- 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.
- Was ist der Unterschied zwischen Blue-Green Deployment und Rolling Update?
- Ein Rolling Update tauscht Instanzen nacheinander aus, alte und neue Version laufen dabei für einige Minuten gemischt, und ein Rollback dauert ähnlich lange. Blue-Green hält zwei komplette Umgebungen vor und schaltet den gesamten Traffic in einem Schritt um. Das kostet doppelte Ressourcen und liefert dafür einen eindeutigen Zustand und einen Rollback in Sekunden.
- Ist Blue-Green Deployment riskant?
- Das Umschalten selbst ist risikoarm, weil die alte Umgebung für den Rollback bereitsteht. Das eigentliche Risiko liegt bei gemeinsam genutzten Daten: Eine Schema-Änderung, die die alte Version nicht mehr lesen kann, macht den Rückweg unbrauchbar. Hinzu kommt, dass ein Fehler nach dem Umschalten sofort alle Nutzer trifft, anders als beim Canary Release.
- Wie gehe ich bei Blue-Green mit Datenbank-Migrationen um?
- Gestalten Sie Schema-Änderungen rückwärtskompatibel, sodass alte und neue Anwendungsversion gegen dasselbe Schema laufen. Bewährt hat sich die Reihenfolge: erst die Migration deployen, dann die neue Version, und veraltete Spalten erst in einem späteren Release entfernen. So bleibt der schnelle Rollback möglich.
- Lohnt sich Blue-Green trotz des doppelten Ressourcenbedarfs?
- Ja, wenn geringe Ausfallzeit und ein schneller Rollback geschäftskritisch sind. In elastischen Cloud-Umgebungen fällt der doppelte Bedarf nur während des Wechsels an. Bei knapper, fester Hardware ist ein Rolling Update oder Canary Release die sparsamere Wahl.
- 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; bei Fehlern rollt das Werkzeug automatisch zurück.
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.
Weiterführende Primärquellen zu Blue-Green Deployment: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Martin FowlerBlue-Green Deployment(externe Seite, öffnet in neuem Tab)
Die ursprüngliche Beschreibung des Verfahrens mit Umschaltpunkt und Rücksprung.
- /02AWS WhitepaperBlue/Green Deployments(externe Seite, öffnet in neuem Tab)
Umsetzungsvarianten über DNS, Load Balancer und Autoscaling-Gruppen.
- /03Argo ProjectBlue-Green Strategy(externe Seite, öffnet in neuem Tab)
Konkrete Umsetzung in Kubernetes mit Preview-Service und manueller Freigabe.
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