Blue-Green-Deployment ist eine Deployment-Strategie, bei der zwei identische Umgebungen betrieben werden: Blue (die aktuelle Version) und Green (die neue Version). Der gesamte Verkehr läuft auf Blue. Die neue Version wird komplett auf Green installiert und getestet — erst wenn sie verifiziert ist, wird der Datenverkehr per Umschalter (Router, Load Balancer) auf Green umgeleitet. Im Fehlerfall schaltet man einfach zurück auf Blue.
So läuft ein Blue-Green-Deployment ab
1. Blue läuft produktiv (Version 1.0)
2. Green wird aufgebaut und mit Version 2.0 bestückt
3. Green wird getestet (automatisiert + manuell)
4. Verkehr wird auf Green umgeschaltet → Version 2.0 live
5. Blue bleibt als Rückfall bereitstehen
6. Bei Problemen: sofort zurückschalten auf Blue (Rollback)- Umschalten in Sekunden: Der Wechsel ist ein reiner Routing-Vorgang — kein Umbau von Dateien, kein Neustart der Anwendung. Ein Rollback (Zurückschalten) ist damit genauso schnell wie ein Update.
- Zwei komplette Umgebungen: Beide Versionen laufen parallel, inklusive Datenbank. Bei datenbankbasierten Systemen müssen Migrationen abwärtskompatibel sein (die alte Version muss mit dem neuen Schema weiterarbeiten können).
- Kosten: Es laufen doppelte Ressourcen — bei kleinen Systemen oft akzeptabel, bei großen zu bedenken.
Varianten
- Canary-Release: Statt komplett umzuschalten, wird ein kleiner Teil des Verkehrs (z. B. 5 %) auf die neue Version geleitet und beobachtet. Läuft alles gut, wird der Anteil erhöht. Das Risiko ist noch kleiner als bei Blue-Green.
- Rolling Deployment: Die neue Version wird schrittweise auf den vorhandenen Servern ausgerollt (Server für Server). Es braucht keine zweite Umgebung, aber das Rollback ist aufwendiger.
- Feature Flags: Neue Funktionen stecken hinter Schaltern im Code und können pro Nutzer oder Gruppe aktiviert werden — kombiniert mit Blue-Green sehr flexibel.
Wann lohnt sich Blue-Green?
- Bei Anwendungen, bei denen Ausfallzeiten vermieden werden müssen (Shops, Portale, APIs).
- Wenn Releases häufig stattfinden und ein schneller Rückweg entscheidend ist.
- Wenn automatisierte Tests vor dem Umschalten laufen und die Qualität absichern.
- In CI/CD-Pipelines, die den Wechsel automatisch auslösen.
Praxis-Tipps
- Datenbank-Migrationen so planen, dass beide Versionen mit dem Schema arbeiten können (additive Änderungen, kein destruktives Umbenennen).
- Die alte Umgebung nach erfolgreichem Betrieb einige Tage behalten, bevor sie abgebaut wird — nicht sofort löschen.
- Den Umschaltvorgang automatisieren (Skript oder Pipeline-Schritt) und dokumentieren, damit er jederzeit reproduzierbar ist.
- Beide Umgebungen mit echtem Monitoring versehen — nach dem Umschalten sofort Fehler und Latenz vergleichen.
Verwandte Grundlagen: CI/CD, Pipeline, Testing, Container, Monitoring, Automatisierung, Snapshots, Git.