Deployment-Strategien: Blue-Green und Rolling im Vergleich

Die Wahl der richtigen Deployment-Strategien ist eine der kritischsten Entscheidungen beim Ausliefern von Software, denn sie bestimmt, ob deine Nutzer überhaupt eine Ausfallzeit erleben. Ob E-Commerce-Seite, Game-Server oder Discord-Bot, jedes Update bedeutet in Wirklichkeit, ein laufendes System zu verändern, während es weiterläuft. In diesem Artikel vergleiche ich zwei gängige Ansätze, Blue-Green- und Rolling-Deployment, anhand realer Szenarien und kläre, welchen man in welcher Situation wählt.

Warum braucht man eine Strategie?

Die einfachste Methode, „Server stoppen, Code austauschen, neu starten", mag für ein kleines persönliches Projekt ausreichen. Doch sobald du Traffic hast, bedeutet jede Sekunde Ausfallzeit Umsatzverlust, eine schlechte Nutzererfahrung und einen Rückgang im Suchmaschinen-Ranking. Das gemeinsame Ziel moderner Deployment-Strategien ist es, null Ausfallzeit (Zero-Downtime) zu erreichen. Darüber hinaus gibt es drei zentrale Erwartungen:

• Schnelles Rollback: innerhalb von Sekunden zum vorherigen Zustand zurückkehren können, falls die neue Version fehlerhaft ist.
• Sichere Verifizierung: die neue Version durch Health-Checks laufen lassen, bevor man sie echtem Traffic aussetzt.
• Vorhersagbarkeit: jedes Deployment mit denselben, wiederholbaren Schritten durchführen.

Wie funktioniert Blue-Green-Deployment?

Beim Blue-Green-Ansatz hältst du zwei Spiegelumgebungen vor: blue ist die aktuell live geschaltete Version, während green eine identische Umgebung ist, in der du die nächste Version vorbereitest. Du deployst den neuen Code nach green, führst die Migrationen aus und machst die Health-Checks. Sieht alles gut aus, schaltet der Load Balancer oder Reverse Proxy den Traffic in einem einzigen Schritt von blue auf green um. Green ist jetzt live; blue wartet unberührt als Backup.

Stell dir vor, du routest den Traffic über einen Nginx-Upstream. Die Umschaltung sieht in etwa so aus:

upstream app {
    # server 127.0.0.1:8001;  # blue (alt)
    server 127.0.0.1:8002;    # green (neu)
}

Sobald du die Konfiguration änderst und nginx -s reload ausführst, gehen neue Anfragen an green. Geht etwas kaputt, gibt dir das Zurücksetzen der Zeilen und erneutes Neuladen ein sofortiges Rollback, denn die alte Umgebung steht noch.

Wie funktioniert Rolling-Deployment?

Rolling-Deployment ist für Umgebungen gedacht, in denen du mehrere Kopien (Instanzen) derselben Anwendung betreibst. Statt alle Kopien gleichzeitig zu aktualisieren, erneuerst du sie nacheinander in Gruppen. Hast du etwa vier Kopien: Du nimmst eine aus dem Traffic, deployst die neue Version, gibst sie nach bestandenem Health-Check zurück in den Pool und gehst dann zur nächsten über. Ist der Prozess abgeschlossen, laufen alle Kopien auf der neuen Version, und das System ist zu keinem Zeitpunkt vollständig offline.

Kubernetes bietet dieses Modell von Haus aus. Wenn du ein Deployment aktualisierst, ist die Standardstrategie bereits Rolling:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Hier legt maxUnavailable fest, wie viele Pods gleichzeitig nicht verfügbar sein dürfen, während maxSurge bestimmt, wie viele zusätzliche Pods vorübergehend erstellt werden dürfen. Mit diesen beiden Werten justierst du das Gleichgewicht zwischen Geschwindigkeit und Kapazitätssicherheit.

Die beiden Strategien nebeneinander

Um die Unterschiede klar zu sehen, vergleichen wir die zentralen Dimensionen:

• Ressourcenverbrauch: Blue-Green erfordert zwei vollständige Umgebungen, also vorübergehend doppelte Infrastrukturkosten. Rolling nutzt deine bestehende Kapazität und verlangt nur einen kleinen Puffer.
• Rollback-Geschwindigkeit: Bei Blue-Green ist die Rückkehr sofort; den Traffic zurück auf die alte Umgebung zu schalten genügt. Bei Rolling musst du einen neuen Rollout in umgekehrter Richtung starten, was Zeit kostet.
• Fenster gemischter Versionen: Während eines Rolling-Updates bleiben alte und neue Version eine Weile gleichzeitig live. Nicht abwärtskompatible API- oder Datenbankänderungen können daher Probleme verursachen.
• Einfachheit: Rolling ist meist in Orchestrierungstools eingebaut. Blue-Green verlangt etwas mehr Einrichtung bei Routing und Umgebungsverwaltung.

Die Datenbank: der wirklich schwierige Teil

Bei beiden Strategien ist der häufigste Stolperstein die Änderung des Datenbankschemas. Denk daran, dass sowohl der alte als auch der neue Code eine Weile in dieselbe Datenbank schreiben. Deshalb ist das Schreiben abwärtskompatibler Migrationen unerlässlich. Die praktische Regel lautet: zuerst die Spalte hinzufügen, den Code aktualisieren, dann die alte Spalte entfernen; niemals eine Spalte löschen und den Code in einem einzigen Schritt ändern.

Willst du zum Beispiel eine Spalte umbenennen, gehe statt eines einzelnen RENAME einen dreistufigen Weg: füge die neue Spalte hinzu, deploye Code, der beide Spalten befüllt, und lösche die alte Spalte erst bei einem späteren Deployment. Dieser Ansatz verhindert, dass sich überlappende Versionen während der Auslieferung gegenseitig kaputtmachen.

Welche wann wählen?

Es gibt keine einzige richtige Antwort; es kommt auf den Kontext an. Blue-Green ist ideal, wenn sofortiges Rollback entscheidend ist, bei riskanten Releases und wenn du die zusätzliche Infrastruktur vorübergehend tragen kannst. Rolling ist natürlicher für Teams, die viele Instanzen betreiben, die Kosten niedrig halten wollen und ihre Änderungen ohnehin abwärtskompatibel schreiben. Viele reife Teams kombinieren beides: Der Canary-Ansatz, der einen kleinen Prozentsatz des Traffics auf die neue Version leitet, ist eigentlich eine vorsichtige Variante von Rolling und lässt sich mit der Sicherheit von Blue-Green verbinden.

Häufige Fragen

Bedeutet Blue-Green-Deployment doppelte Kosten?

Im Moment der Umschaltung ja, beide Umgebungen laufen dann gleichzeitig. Das dauert aber meist nur während des Deployment-Fensters; ist die Umschaltung abgeschlossen, kannst du die alte Umgebung herunterskalieren oder bis zum nächsten Release abschalten. In Cloud-Umgebungen hält die minutengenaue Abrechnung diese Mehrkosten meist niedrig.

Braucht ein kleines Projekt diese Strategien überhaupt?

Für ein persönliches Projekt mit wenig Traffic kann die einfache „Stopp-Update-Start"-Methode genügen. Doch sobald deine Nutzer die Ausfallzeit zu bemerken beginnen, lohnt es sich, zumindest auf einen umkehrbaren Ablauf mit Health-Checks umzusteigen.

Ersetzt Canary-Deployment diese Ansätze?

Canary ist keine Alternative, sondern eine Ergänzung. Du setzt die neue Version einem kleinen Teil des Traffics aus, beobachtest die Metriken und weitest sie schrittweise aus, wenn es keine Probleme gibt. Es wird meist auf einem Rolling- oder Blue-Green-Fundament aufgebaut.

Möchtest du den richtigen Deployment-Ablauf für dein Projekt einrichten? Ob eine Release-Pipeline ohne Ausfallzeit oder eine sichere Migrationsstrategie, lass es uns gemeinsam planen. Nimm Kontakt mit mir auf und lass uns die Lösung besprechen, die zu deinen Anforderungen passt.