# Deployment Strategies: Zero-Downtime & Risikominimierung

TL;DR / Management Summary Ein “Big Bang” Deployment am Wochenende ist riskant und verursacht oft stundenlange Ausfälle. Moderne Deployment-Strategien wie Blue-Green und Canary ermöglichen den Software-Wechsel im laufenden Betrieb. Während Blue-Green die gesamte Umgebung umschaltet, lässt Canary nur einen kleinen Teil der User die neue Version testen. Ein Senior Admin nutzt diese Techniken in Kombination mit dem HAProxy (Artikel 562), um im Fehlerfall innerhalb von Millisekunden auf die alte Version zurückzurollen.

# 1. Blue-Green Deployment

Das Prinzip der zwei Welten.

Hierbei existieren zwei identische Produktionsumgebungen parallel:

Blue: Die aktuelle Live-Umgebung.
Green: Die neue Version (wird im Hintergrund aufgebaut und getestet).
Der Schwenk: Wenn Green bereit ist, ändert der Admin am Loadbalancer das Ziel von Blue auf Green.
Vorteil: Sofortiger Rollback möglich (einfach wieder auf Blue schwenken).

# 2. Canary Deployment

Der ‘Kanarienvogel’ im Bergwerk.

Anstatt alle User gleichzeitig umzustellen, schieben wir nur einen winzigen Teil des Traffics auf die neue Version.

Ablauf:
1. Starte Version 2.0 auf einem einzelnen Server.
2. Leite 5% des Traffics dorthin.
3. Überwache die Error-Logs.
4. Wenn alles stabil ist -> 25% -> 50% -> 100%.
Vorteil: Fehler betreffen nur eine kleine Testgruppe, nicht die gesamte Kundschaft.

# 3. Deep Dive: A/B Testing vs. Canary

Der feine Unterschied.

Canary: Fokus auf Infrastruktur & Stabilität. (Läuft der Code ohne Absturz?).
A/B Testing: Fokus auf Funktionalität & Business. (Kaufen die Leute mehr, wenn der Button rot statt blau ist?).
Technik: Beide nutzen den Loadbalancer (z.B. HAProxy mit Weights, Artikel 746), um Traffic zu teilen.

# 4. Day-2 Operations: Automatisierte Rollbacks

Selbstheilung bei Fehl-Releases.

Eine moderne CI/CD Pipeline (Artikel 799) sollte nicht nur deployen, sondern auch überwachen.

Aktion: Das Deployment-Tool prüft die 5xx-Error-Rate nach dem Canary-Start.
Trigger: Wenn die Fehlerrate > 1% steigt -> Auto-Rollback.
Nutzen: Minimierung des Schadens bei nächtlichen Deployments.

# 5. Troubleshooting & “War Stories”

Wenn die neue Version die alte ‘stört’.

# Top 3 Herausforderungen

Symptom: “Shared Database Schema Conflict”.
- Ursache: Version 2.0 ändert die Tabellen-Struktur der Datenbank, die Version 1.0 (noch aktiv) aber weiterhin im alten Format braucht.
- Lösung: Nutzen Sie “Double-Writing” oder nur abwärtskompatible Datenbank-Migrations.
Symptom: User fliegen aus der Sitzung.
- Ursache: Session-Daten (Artikel 749) liegen nur auf dem alten Server.
- Fix: Nutzen Sie ein zentrales Session-Backend (z.B. Redis Cluster).
Symptom: Unvorhersehbare DNS-Caching Probleme beim Schwenk.

# “War Story”: Der “Zombie”-User in der Cloud

Ein Admin nutzte Blue-Green Deployment für eine Banken-App. Er schwenkte von Blue auf Green um. Das Ereignis: 99% der User arbeiteten auf Green. Aber ein kleiner Teil der User (die ihre Browser-Tabs seit Tagen offen hatten) hingen noch in Websocket-Verbindungen zur Blue-Umgebung fest. Die Katastrophe: Da der Admin die Blue-Umgebung nach 10 Minuten “erfolgreichem” Test einfach abschaltete, verloren hunderte User mitten in einer Transaktion ihre Verbindung. Lehre: Ein Deployment-Schwenk erfordert eine “Graceful Termination” Phase. Die alte Umgebung muss so lange online bleiben, bis auch der letzte langlaufende State (Draining) beendet ist.

# 6. Monitoring & Reporting

Vergleich der Versionen.

# Deployment Health Dashboard

Überwachen Sie in Echtzeit den Vergleich:

Error Rate (Blue) vs Error Rate (Green).
Response Time (Blue) vs Response Time (Green).
KPI: Wenn Green langsamer ist als Blue -> Stop der Canary-Welle.

# 7. Fazit & Empfehlung

Deployment-Strategien sind der Unterschied zwischen Stress und Professionalität.

Empfehlung: Nutzen Sie Blue-Green für große Major-Updates und Canary für tägliche Continuous Deployments.
Wichtig: Sorgen Sie für eine automatisierte Datenbank-Migration, die Rollbacks unterstützt (z.B. mit Liquibase oder Flyway).

# Anhang: Vergleichstabelle (Strategien)

Strategie	Downtime	Risiko	Kosten
Big Bang	Hoch	Maximal	Gering
Blue-Green	Null	Gering	Hoch (doppelte Infrastruktur)
Canary	Null	Minimal	Mittel
Rolling	Minimal	Mittel	Mittel