Continuous Deployment (CD)

Das erfordert extrem hohes Vertrauen in Tests ("Test Coverage 95%+"). Wenn deine Tests schlecht sind, deployest du Bugs automatisch (das nennt man "Continuous Bugs"). Um das Risiko zu senken, nutzt man Sicherheitsnetze:

1. Feature Flags: Das neue Feature ist deployed, aber versteckt (Off). Man schaltet es erst später an.
2. Canary Deployment: Erst 1% der User bekommt das Update. Wenn Fehler -> Rollback.

1. The Fear Barrier (Kultur)

Das größte Hindernis ist nicht Technik, sondern Angst. "Was, wenn wir die DB löschen?" Continuous Deployment zwingt zu Small Batches. Statt einem Riesen-Update alle 3 Monate (hohes Risiko), machst du 50 Mini-Updates am Tag. Wenn ein Mini-Update crasht, ist der Fehler sofort zu finden ("Es war der Commit von 14:02 Uhr"). Das Risiko sinkt paradoxerweise durch die Häufigkeit der Deployments.

2. Post-Deployment Verification

Da kein Mensch testet, muss das Monitoring testen. Das System prüft nach dem Deploy:

• "Ist die CPU-Last normal?"
• "Sind die Bestellungen pro Minute stabil?" Wenn eine Metrik abweicht (Anomaly Detection), löst das System automatisch den Rollback aus. Menschliche Reaktionszeit: 15min. Maschine: 30sek.

3. Database Migrations

Datenbanken sind schwer (State). Wie macht man ALTER TABLE vollautomatisch? Tools wie Liquibase/Flyway laufen in der Pipeline. Regel: Expand and Contract. Schritt 1: Spalte hinzufügen (Deploy). Code schreibt in beide Spalten. Schritt 2: Daten migrieren. Schritt 3: Code liest nur neue Spalte (Deploy). Schritt 4: Alte Spalte löschen (Deploy). Alles scriptgesteuert, ohne Downtime.

1. Immutable Infrastructure und GitOps

In Produktions-High-End-Umgebungen bedeutet Deployment nie "Wir loggen uns auf dem Server ein und machen git pull". Das ist verpönt. Stattdessen gilt Immutable Infrastructure. Ein Server oder Container wird nach dem Start niemals manipuliert. Beim Continuous Deployment wird immer das gesamte Docker-Image oder die AMI virtuell komplett neu gedreht. Der Rollout-Prozess geschieht oft via GitOps (Tools wie ArgoCD oder Flux). Wenn in der Registry ein neues Image v2 auftaucht, merkt der Controller-Loop im K8s-Cluster das Delta zum Git-Sollzustand und löscht eiskalt die v1 Pods, um sie generisch frisch durch v2 Images zu ersetzen. Keine Drift, keine Geisterzustände.

2. DORA Metrics und Deployment Performance

Wie misst ein CTO, ob CD funktioniert? Google ("Accelerate") erschuf die DORA Metriken:

1. Deployment Frequency: Wie oft liefern wir am Tag aus? (Top-Performer: Mehrfach täglich).
2. Lead Time for Changes: Vom git commit bis das Zeug in Prod ist (Top: < 1 Stunde).
3. Time to Restore Service: Wenn alles down geht, wie schnell fixed die CI/CD Pipeline das durch ein automatisiertes Rollback?

   Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Das erfordert extrem hohes Vertrauen in Tests ("Test Coverage 95%+"). Wenn deine Tests schlecht sind, deployest du Bugs automatisch (das nennt man "Continuous Bugs"). Um das Risiko zu senken, nutzt man Sicherheitsnetze: 1. Feature Flags: Das neue Feature ist deployed, aber versteckt (Off). Man schaltet es erst später an. 2. Canary Deployment: Erst 1% der User bekommt das Update. Wenn Fehler - Rollback.
4. Change Failure Rate: Wie viel Prozent der Deploys führen zur Havarie? CD maximiert die Deployment Frequency massiv und drückt im Gegensatz meist den Failure, weil durch extreme Iterations-Zyklen menschliche Release-Tage obsolet sind.

3. Blue-Green Schema Migrations

Datenbank-State zerreißt Pipelines gerne. Ein "No Touch Deployment" erfordert Backward & Forward Compatible Database Schemas. Muss ich eine Spalte Firstname und Lastname zu Fullname zusammenführen, teilt sich das in mindestens drei Deployments: Deployment 1: Neue Spalte anlegen. Alter Code läuft. Deployment 2: Neuer Code (vX) deployed. Er liest von Fullname falls da, sonst alte; er schreibt beide (Dual Write). Jetzt migriert ein Script asynchron alle 50 Mio Datenbankeinträge über Batch-Runs. Deployment 3: Alter Code liest nur noch die neue Spalte. Deployment 4: Alter Spaltensatz wird fallengelassen. All das muss im Continuous Tunnel passieren, um Downtimes zu umgehen.