Zero-Downtime-Deployments
Deployment ist ein Nicht-Ereignis.
Blue-Green, Canary Releases, Feature Flags. Ihr Team deployt taeglich ohne Stress — automatisiert, getestet, mit sofortigem Rollback.
Warum Deployment kein Event sein darf¶
Wenn Ihr Team ein „Deployment-Fenster” hat und alle in Bereitschaft sind, sagt Ihnen das System etwas Wichtiges: Der Deployment-Prozess ist kaputt. Deployment sollte Routine sein — wie ein Commit, wie ein Code Review. Automatisiert, getestet, mit einem klaren Rollback-Plan.
Blue-Green-Deployment¶
Zwei identische Umgebungen:
- Blue — aktuelle Produktion, bedient 100 % des Traffics
- Green — neue Version, deployed und getestet
- Smoke-Tests auf Green ✅ → Traffic-Umschaltung (DNS oder Load Balancer)
- Problem? In Sekunden zurueck zu Blue schalten
Fuer Kubernetes: Argo Rollouts mit automatischen Health Checks. Rollout stoppt, wenn Metriken Schwellenwert ueberschreiten.
Canary Releases¶
Progressive Rollout fuer grosse Systeme:
- Neue Version bekommt 5 % Traffic
- Automatische Metriken: Fehlerrate, Latenz, Business-KPIs
- Metriken OK → 25 % → 50 % → 100 %
- Schlechte Metriken → automatischer Rollback
Gesamter Prozess: 30-60 Minuten. Menschliches Eingreifen nur bei Eskalation. Argo Rollouts oder Flagger fuer Kubernetes.
Feature Flags¶
Trennung von Deploy und Release:
- Code in Produktion, Feature deaktiviert — Deploy ohne Risiko
- Progressive Aktivierung — intern → Beta → 10 % → 100 %
- A/B-Testing — Variante A vs. B, Metriken entscheiden
- Kill Switch — sofortiges Deaktivieren eines problematischen Features
- Targeting — Feature nur fuer bestimmte Benutzer/Segmente
Tools: LaunchDarkly, Unleash, kundenspezifische Loesungen. CI/CD-Integration — Feature Flag wird automatisch erstellt, wenn PR mit Feature-Flag-Annotation gemergt wird.
Datenbank-Migrationen¶
Der riskanteste Teil des Deployments. Regeln:
Expand-Contract-Pattern: 1. Expand — Neue Spalte hinzufuegen, alte behalten 2. Migrieren — Daten kopieren/transformieren 3. Umschalten — Anwendung liest aus neuer Spalte 4. Contract — Alte Spalte entfernen
Kein ALTER TABLE mit Locks. Kein DROP COLUMN waehrend des Deployments. Jede Migration ist rueckgaengig machbar.
CI/CD-Pipeline¶
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌─────────┐ ┌──────────┐
│ Commit │──▶│ Build │──▶│ Test │──▶│ Stage │──▶│ Prod │
│ │ │ + Lint │ │ Unit │ │ E2E │ │ Canary │
│ │ │ + SAST │ │ Integ │ │ Smoke │ │ → Full │
└─────────┘ └──────────┘ └──────────┘ └─────────┘ └──────────┘
│
Auto-Rollback
bei Schwellenwert
Commit → Produktion in < 15 Minuten. Automatisiert. Mit Quality Gates bei jedem Schritt.
Häufig gestellte Fragen
Expand-Contract-Pattern. Wir fuegen eine neue Spalte hinzu (Expand), migrieren die Daten, entfernen die alte (Contract). Keine Breaking Changes, keine Table Locks.
Ja. Blue-Green-Deployment funktioniert sowohl fuer Monolithen als auch fuer Microservices. Feature Flags trennen Deploy von Release unabhaengig von der Architektur.
Basis-Pipeline (Build → Test → Deploy): 2-4 Wochen. Vollstaendiger Progressive-Delivery-Stack (Canary, Feature Flags, automatischer Rollback): 4-8 Wochen.