Deployment-Strategien: Big Bang, Rolling, Blue-Green, Canary
In L1 hast du gelernt was Deployment ist und welche Risiken es birgt. Diese Lektion beschäftigt sich mit der zentralen Frage: WIE rolle ich Software aus, ohne Production zu crashen?
Es gibt vier etablierte Deployment-Strategien, die jeweils unterschiedliche Trade-offs zwischen Geschwindigkeit, Risiko und Komplexität bieten: Big Bang, Rolling Update, Blue-Green Deployment und Canary Release. Wer diese vier kennt und einsetzen kann, ist in Bewerbungsgesprächen für DevOps-Positionen klar im Vorteil.
1) Überblick der vier Strategien
Bevor wir in die Details gehen, hier eine schnelle Übersicht. Klick auf jede Karte um direkt zur Erklärung zu springen:
2) Big Bang Deployment
Die klassischste und einfachste Strategie: alles auf einmal. Alle Server werden gleichzeitig auf die neue Version umgestellt. Während der Umstellung läuft die alte Version nicht und die neue noch nicht – kurze Downtime ist die Folge.
3) Rolling Update
Bei Rolling Update wird Server für Server auf die neue Version umgestellt. Während Server 1 noch upgedatet wird, halten Server 2-4 den Betrieb am Laufen. Kein Downtime, aber zwei Versionen laufen kurzzeitig parallel:
maxUnavailable und maxSurge steuerst du wie schnell und wie viel parallel.4) Blue-Green Deployment
Bei Blue-Green hast du zwei komplette Umgebungen: Blue (aktuell live) und Green (Standby). Die neue Version wird auf die Standby-Umgebung deployed und ausgiebig getestet. Wenn alles passt: ein einziger Switch im Load Balancer – schon ist Green live, Blue wird zur neuen Standby.
5) Canary Release
Der Canary ist die ausgefeilteste Strategie: die neue Version bekommt erst einen kleinen Anteil des Traffics (z.B. 5%). Wenn keine Probleme auftreten, wird der Anteil schrittweise erhöht (10%, 25%, 50%, 100%). Bei Problemen kann man jederzeit zurückrollen – nur wenige Nutzer waren betroffen.
6) A/B Testing vs. Canary
Eine oft verwechselte Variante: A/B Testing. Sieht aus wie Canary, hat aber ein anderes Ziel:
- Canary: technische Strategie. „Funktioniert die neue Version technisch?" – wenn ja, alle bekommen sie.
- A/B Testing: geschäftliche Methode. „Welche Variante konvertiert besser?" – Variante A und B laufen parallel, Daten entscheiden.
A/B-Tests laufen oft Wochen, sind statistisch ausgelegt, und die „bessere" Variante bleibt. Bei Canary ist die neue Version immer das Ziel – die Frage ist nur ob sie funktioniert.
7) Strategien im direkten Vergleich
Welche Strategie für was? Hier die Übersicht:
8) Datenbank-Migration als Sonderfall
Eine wichtige Komplikation: Datenbank-Schemata. Wenn die neue Version eine andere DB-Struktur braucht, muss beim Rolling oder Canary die DB beide Versionen gleichzeitig unterstützen. Best Practice: Expand and Contract Pattern:
- Expand: neue Spalten/Tabellen hinzufügen, alte bleiben. Beide Versionen können arbeiten.
- Deploy neue App-Version, die neue Struktur nutzt
- Contract: nach erfolgreicher Migration alte Strukturen entfernen
Das ist mühsam, aber zwingend bei Zero-Downtime-Deployments. Viele Production-Incidents kommen daher dass DB und App nicht synchron sind.
9) Feature Flags: Deployment ≠ Release
Mit Feature Flags kann man Deployment und Release trennen:
- Code wird deployed (technisch live, aber Feature ist hinter Flag deaktiviert)
- Später wird das Flag aktiviert – für bestimmte User, Regionen, oder zu definierter Uhrzeit
- Bei Problemen: Flag deaktivieren statt rollback
Tools wie LaunchDarkly, Unleash, Flagsmith bieten Feature-Flag-Management mit Targeting (per User-ID, Land, Browser, etc.). In großen Tech-Companies Standard – Code geht ständig live, Features werden bewusst aktiviert.
10) Welche Strategie für welches Szenario?
Konkrete Empfehlungen aus der Praxis:
| Szenario | Empfehlung |
|---|---|
| Kleine Webapp, 1-2 Server | Big Bang in Wartungsfenster |
| Mittlere Webapp, mehrere Server, Kubernetes | Rolling Update (Kubernetes Default) |
| Kritische API, Banking, Healthcare | Blue-Green für sofortigen Rollback |
| Großer Konsumenten-Service (Netflix, Spotify) | Canary + Feature Flags |
| Mobile App (App Store) | Staged Rollout (Apples/Googles Canary) |
| Microservice-Architektur | Rolling pro Service, Canary für kritische |
| Legacy-Monolith | Blue-Green wenn möglich, sonst Big Bang nachts |
| Embedded/IoT-Geräte | Phased Rollout über Tage/Wochen (Canary-Stil) |
11) Was wenn ein Deployment schiefgeht?
Egal welche Strategie: Rollback-Plan muss bereit sein. Drei Hauptszenarien:
- Sofortiger Rollback: bei kritischen Bugs (App startet nicht, Fehler ab Sekunde 1). Mit Blue-Green/Canary in Sekunden.
- Verzögerter Rollback: bei subtilen Problemen (5% mehr Errors, leichte Performance-Probleme). Erkennung dauert Minuten bis Stunden.
- Forward Fix: statt Rollback ein Hotfix-Deploy. Manchmal schneller als Rollback, vor allem bei DB-Migrationen.
Mehr zu Rollback-Strategien in L9.
Zusammenfassung
Vier Hauptstrategien für Software-Deployment: Big Bang (alle gleichzeitig, Downtime, einfach), Rolling Update (Server für Server, kein Downtime, Kubernetes-Standard), Blue-Green (zwei Umgebungen, schneller Rollback durch Load-Balancer-Switch, doppelte Kosten), Canary (schrittweise Traffic-Verlagerung 5%→100%, minimales Risiko, komplex). Unterscheidung Canary vs. A/B Testing: Canary ist technisch, A/B ist geschäftlich. Feature Flags trennen Deployment von Release. DB-Migrationen als Komplikation: Expand-Contract-Pattern für Zero-Downtime. Wahl der Strategie: Big Bang nur für klein/Hobby, Rolling für Standard, Blue-Green für kritisch, Canary für sehr große Systeme. Immer mit Rollback-Plan deployen.