GitOps & Blue-Green / Deployment ohne Ausfallzeit

Symptom

Ziel: Schema- und Anwendungsänderungen ohne Ausfallzeit ausrollen; sich mit Expand-Contract-Migrationen, Blue-Green-Umgebungen, Feature Flags und automatischem Rollback dem Zero-Downtime-Ziel nähern.

1. GitOps: Git zur einzigen Quelle der Wahrheit machen

Definiere Infrastruktur, Schemamigrationen und Anwendungsversion in Git; das Deployment wird durch einen Merge ins Repository ausgelöst (GitOps). Ein Reconciler (Argo CD/Flux oder CI/CD) wendet den Sollzustand auf die reale Umgebung an. Jede Änderung ist dann nachvollziehbar, wiederholbar und lässt sich bei Bedarf auf einen früheren Commit zurücksetzen.

PostgreSQL

# repo/
#   migrations/  (Vxxx__*.sql)
#   k8s/         (Deployment, Service)
#   flags/       (feature flag config)

2. Schema abwärtskompatibel ändern (Expand-Contract)

Für null Ausfallzeit ändere das Schema nicht in einem einzigen brechenden Schritt, sondern teile es in zwei Phasen. EXPAND: Füge die neue Struktur hinzu (neue Spalte/Tabelle), sodass alter und neuer Code gleichzeitig laufen können (nullable Spalte, mit Default, doppeltes Schreiben). Erst NACHDEM die Anwendung auf die neue Struktur umgestellt ist, CONTRACT: Entferne die nicht mehr genutzte alte Spalte/Tabelle in einer separaten Migration. Alte und neue Anwendungsversion laufen dann während des Deployments problemlos parallel.

PostgreSQL

-- EXPAND (V5): backward-compatible addition
ALTER TABLE customer ADD COLUMN email text;

-- for a while the code writes/reads both columns

-- CONTRACT (V9): drop the old column
ALTER TABLE customer DROP COLUMN mail_old;

3. Riskantes Verhalten hinter ein Feature Flag legen

Führe den neuen Codepfad (etwa das Lesen der neuen Spalte) bedingt hinter einem Feature Flag aus; schalte das Flag ein, wenn das Schema bereit ist, und bei Problemen wieder aus, ohne das Deployment anzufassen. Ein Flag trennt das Ausrollen des Codes (Deploy) von der Aktivierung des Features (Release). Die Expand-Phase wird ausgeliefert, die Verhaltensänderung aber kontrolliert aktiviert und lässt sich schnell zurücknehmen.

PostgreSQL

-- application layer (pseudocode)
-- if flag('new_email_field'):
--     SELECT email FROM customer ...
-- else:
--     SELECT mail_old FROM customer ...

4. Blue-Green-Umgebung einrichten

Halte zwei identische Umgebungen vor: 'blue' (live) und 'green' (neue Version). Rolle die neue Anwendungsversion auf green aus und validiere sie, bevor sie echten Verkehr erhält; ist sie bereit, schalte Router/Verkehr auf green um. Wichtig: Die Datenbank ist meist GEMEINSAM genutzt, daher muss das Schema mit beiden Versionen kompatibel sein (das stellt Expand-Contract sicher). Auch wenn sich beim Umschalten das Verbindungsziel ändert, bedeutet Schemakompatibilität keine Ausfallzeit.

PostgreSQL

# traffic is switched to green (new version)
# shared DB: schema must be compatible with both blue and green

5. Deployment per Monitoring validieren (Canary/Beobachtung)

Überwache vor dem Umschalten des gesamten Verkehrs Metriken wie Fehlerrate, Latenz, Fehler-/Lock-Anzahl der Datenbank und Replikations-Lag; sende optional einen kleinen Prozentsatz des Verkehrs (Canary) an green und beobachte. Sind die Gesundheitsindikatoren gut, erhöhe den Verkehr schrittweise; sind sie schlecht, fahre nicht fort. Das Monitoring liefert die Grundlage für die Entscheidung zum automatischen Rollback.

PostgreSQL

-- live health queries
SELECT count(*) FROM pg_stat_activity WHERE wait_event_type='Lock';
SELECT * FROM pg_stat_replication;

6. Automatisches Rollback vorbereiten

Überschreiten die Metriken den Schwellenwert, muss das Deployment automatisch zurückgerollt werden: Bei Blue-Green wird der Verkehr schnell zurück auf blue (die alte Version) geschaltet. Das Rollback der Anwendung erfolgt sofort, da blue noch läuft. Auf Schemaseite ist ein Rollback meist NICHT NÖTIG: Dank Expand-Contract ist das neue Schema auch mit dem alten Code kompatibel, daher genügt das Zurückrollen der Anwendung. Deshalb sollten Schemaänderungen unabhängig vom Anwendungs-Deployment bleiben und stets abwärtskompatibel sein.

PostgreSQL

# traffic instantly returns to blue (application rollback)
# schema is not rolled back: expand-contract is compatible with old code
# if truly needed: write a new corrective migration