Blue-Green Deployment

Das riskanteste beim Update: Der Moment, wo man den alten Code löscht und den neuen startet. Wenn der neue kaputt ist, ist die Seite down (Downtime). Blue-Green verhindert das. Du hast zwei identische Umgebungen: Blau (Live) und Grün (Leer).

Du installierst die neue Version auf Grün.
Du testest Grün in Ruhe (nur intern).
Wenn alles läuft, legst du den Schalter am Router (Load Balancer) um: Aller Traffic geht jetzt auf Grün.
Grün ist jetzt "Live". Blau ist "Backup". Wenn Grün doch kaputt ist? Schalter zurück auf Blau. (Rollback in Sekunden).

Merksatz: Eine Release-Strategie, bei der zwei identische Produktionsumgebungen parallel laufen, um Updates ohne Ausfallzeit (Zero Downtime) und mit sofortigem Rollback zu ermöglichen.

In der Cloud (Kubernetes / AWS) ist das einfach. Du erstellst einen neuen Service (Green). Du änderst den Ingress/Router: "Traffic zu Green". Die alte Umgebung (Blue) lässt man noch eine Stunde laufen ("für alle Fälle") und löscht sie dann, um Kosten zu sparen.

1. Database Schema Changes

Der Endgegner. Code ist leicht zu tauschen. Daten nicht. Wenn Version Grün eine neue Tabellenspalte braucht, die Version Blau nicht kennt? Regel: Datenbank-Änderungen müssen immer abwärtskompatibel sein. Erst Spalte hinzufügen (Deploy). Dann Code nutzen (Deploy). Dann alte Spalte löschen (Cleanup).

2. User Sessions

Wenn ich während des Switch eingeloggt bin, lande ich auf dem neuen Server. Kennt der meine Session? Nein -> Ich werde ausgeloggt (Ärgerlich). Lösung: Sessions in externen Cache (Redis) speichern, den beide Umgebungen teilen.

1. State Invalidation und Draining

Beim Switch von Blau auf Grün dürfen laufende Requests nicht hart abgeschnitten werden. Der Router führt ein Connection Draining (oder "Connection Bleeding") durch. Er signalisiert dem blauen Cluster: "Akzeptiere keine neuen TCP/HTTP-Verbindungen mehr". Bereits bestehende Streams (wie große Datei-Downloads oder WebSockets) lässt der Router aber noch bis zu einem konfigurierten Timeout (z. B. 60 Sekunden) offen. Gleichzeitig schießt Blue-Green oft Caches ab (State Invalidation). Ein "Cold Cache" im neuen grünen System führt in den ersten Sekunden nach dem Cut-Over zu extremen Latenz-Spikes (Thundering Herd) auf der Datenbank, weil plötzlich alle Queries durch den leeren Cache fallen.

2. Forward & Backward Compatibility

Da die Datenbank (oft) nur einmal existiert und von Blau und Grün geteilt wird, ist das Datenbankschema das Haupthindernis. Ein Release erfordert den "Parallel Change" (Expand-Contract) State. Variante Grün muss Code mitbringen, der sowohl die neuen Tabellenspalten füllt als auch die alten Spalten (die Blau gerade nutzt) konsistent schreibt. Dies nennt man echte Backward Compatibility (Grün toleriert den Status von Blau) und Forward Compatibility (Blau stürzt nicht ab, wenn in der DB auf einmal neue Daten von Grün auftauchen). Solche DDL-Migratonen erstrecken sich oft über Wochen und drei getrennte Release-Zyklen.

3. Dark Launch und Mirroring

Ist man sich unsicher, ob das neue grüne System unter der echten HTTP-Last standhält, kann man vor dem eigentlichen Switch-over zum Traffic Mirroring (Dark Launch) greifen. Ein Ingress Controller (wie Envoy) klont jeden eingehenden HTTP-Request und sendet ihn unbemerkt an Grün. Der User bekommt weiterhin nur die Response von Blau. Man schaut sich aber das Logging des grünen Clusters an: Würde der Code crashen, wenn er wirklich User beantworten müsste? Hatten wir "Out of Memory"? Wenn nein, macht man den Switch.