Continuous Delivery (CD)

Du hast Code geschrieben (Dev) und getestet (CI). Das Artefakt (app.zip) liegt bereit. Was nun? Continuous Delivery ist der Prozess, dieses Paket automatisch auf eine Test-Umgebung (Staging) zu bringen, damit Menschen es anschauen können. Das Ziel: Die Software ist jederzeit deploy-bereit. Es gibt nur einen Knopf ("Deploy to Prod"), den ein Mensch drücken muss. Alles davor (Build, Test, Deploy to Staging) ist automatisiert. "Delivery" heißt: Wir liefern es bis vor die Haustür der Produktion (aber gehen noch nicht rein).

Merksatz: Eine Softwareentwicklungspraktik, bei der Codeänderungen automatisch gebaut, getestet und für das Release vorbereitet werden, sodass das Deployment in die Produktion jederzeit (oft per Knopfdruck) möglich ist.

Die Pipeline sieht so aus:

Commit: Entwickler pusht Code.
CI: Unit Tests laufen. Build Artefakt wird erstellt.
CD (Staging): Artefakt wird automatisch auf den Staging-Server geladen.
E2E Tests: Ein Roboter klickt durch die Staging-Webseite ("Login geht?").
Wait: Die Pipeline stoppt und wartet.
Human Approval: Ein Manager klickt "Approve" (nach QA-Abnahme).
CD (Prod): Erst jetzt geht es live.

1. Delivery vs. Deployment

Der Unterschied ist subtil aber entscheidend.

Continuous Delivery: Das Deployment nach Prod ist manuell (Business Decision). "Wir releasen Freitag."
Continuous Deployment: Das Deployment nach Prod ist automatisch. Sobald alle Tests grün sind, geht es live. Auch nachts um 3 Uhr. High-Performer (Amazon, Netflix) machen Deployment. Regulierter Sektor (Banken) macht Delivery.

2. Artifact Promotion

Ein Anti-Pattern: "Ich baue das Artefakt für Staging neu. Und dann baue ich es für Prod nochmal neu." Gefährlich! Der zweite Build könnte anders sein (neue Library Version im Internet). Best Practice: Build Once, Deploy Anywhere. Das gleiche Binary (Hash-identisch), das auf Staging getestet wurde, wird nach Prod "promoted" (kopiert). Nur die Umgebungsvariablen (ConfigMap) ändern sich.

3. Smoke Tests & Rollbacks

Nach dem Deployment ist vor dem Deployment. Ein CD-Skript muss prüfen: "Lebt die App noch?" (Healthcheck / Smoke Test). Wenn nein -> Auto-Rollback. Das Skript stellt sofort die alte Version wieder her. "Mean Time To Recovery" (MTTR) ist wichtiger als "Mean Time Between Failures" (MTBF).

Feature Flags (Decoupling Deploy from Release)

Das größte Problem in traditionellem CD: Wenn du Code auf den Master-Branch mergst, löst es ein Deployment aus und Features gehen sofort "live" für den Kunden. Aber vielleicht ist das Marketing noch nicht bereit? Die Lösung lautet Feature Flags (Feature Toggles, z. B. LaunchDarkly oder Unleash). Du "wrapppst" deinen neuen Code in ein IF-Statement: if (flags.isNewButtonEnabled) { drawButton(); }. Das CD-System liefert den Code still und leise (Deploy). Das Team der Entwickler mergt Code weiterhin mehrfach am Tag in Produktion. Die Software ist aber "stumm". Erst wenn der Product Owner im Dashboard den Schalter umlegt (Release), sehen die Kunden das Feature. So trennt man technisches Deployment von geschäftlichem Release.

Canary & Blue/Green Deployments

Anstatt bei jedem Release sofort 100% des Cluster-Traffics auf die neu-deployten V2-Container umzulenken (Risiko von Totalausfällen), operieren High-Performer mit progressiven CD-Rollouts:

Blue/Green: Du behältst das alte Cluster (Blue) unbeschnitten am Leben. Das CD-Tool deployt eine volle V2-Version in eine leere Partition (Green). Alle Tests laufen transparent gegen Green. Wenn alles perfekt ist, schwenkt der Load Balancer (z. B. AWS Route53 Record) auf einen Schlag (Atomic Switch) den Traffic auf Green. Schlägt es fehl, Switch zurück.
Canary Release: Das Tool (z.B. Argo Rollouts oder Flagger) leitet erst 5% des Traffics auf die neue K8s-Version, testet Metriken (Latenz, HTTP 500 Fehler via Prometheus), skaliert dann nach 10 Minuten auf 20%, 50% und erst viel später auf 100% hoch. Wenn Fehler rasch ausschlagen ("Canary in the coal mine"), bricht das CD-System stumm ab und leitet alle Nutzer zurück auf die alte Version, ohne dass Kunden massiv geschädigt werden.

Configuration as Code (GitOps)

Das ultimative Level an Automatisierung ist GitOps für das Delivery (ArgoCD, Flux). Statt dass eine Jenkins Pipeline imperativ "pusht" (kubectl apply), deklariert Git den Endzustand. Die GitOps-Controller in Kubernetes lesen permanent den Main-Branch (Pull). Ändert jemand das Versions-Tag in der deployment.yaml im Repo, holt der Cluster-Controller die Info als Observer ab, gleicht seinen Ist-Zustand ab und sorgt für das Sync-Deployment. Fällt das gesamte Cluster aus, oder muss für Disaster Recovery neu aufgezogen werden, läuft der neue leere Cluster hoch, stürzt sich auf das Git-Rep und deployed exakt (!) die Architektur der Millisekunde vor dem Crash nach.