Was ist Continuous Delivery (CD)?

Was ist Continuous Delivery (CD)?

Continuous Delivery ist die Software-Engineering-Praxis, bei der jede Code-Änderung automatisch durch Build-, Test- und Validierungsschritte fortschreitet, bis sie einen produktionsreifen Zustand erreicht — und jederzeit mit einem einzigen Klick oder Befehl in Production deployed werden kann. CD ist die natürliche Erweiterung von Continuous Integration (CI): CI gewährleistet, dass jeder Commit gebaut und getestet wird; CD gewährleistet, dass jeder Commit, der passt, auch verpackt, zu Staging deployed, validiert und bereit zum Shippen ist.

Die wichtige Unterscheidung, die jedes Team verstehen sollte: Continuous Delivery ≠ Continuous Deployment. Continuous Delivery bedeutet, die Änderung ist bereit zu shippen; Menschen entscheiden, wann. Continuous Deployment bedeutet, die Änderung shippt tatsächlich automatisch bei grünem CI. Die meisten Enterprise-Teams praktizieren CD (Release auf Abruf); weniger praktizieren Continuous Deployment (automatische Promotion zu Prod). Beide kürzen zu "CD" ab, was ständige Verwirrung in Interviews und Architektur-Diskussionen verursacht.

Die CD-Pipeline-Anatomie

Eine typische CD-Pipeline hat diese Stages, jede gated die nächste:

1. Source. Trigger bei Push zu main / Merge eines PR. Pull Source, berechne Commit-Metadaten.
2. Build. Kompiliere Code, installiere Dependencies, baue Container-Images. Cache aggressiv (npm-Cache, Docker-Layer-Cache, Gradle-Cache).
3. Unit-Tests. Laufen parallel; ziele auf unter 5 Minuten. Fail-Fast bei erstem kaputten Test.
4. Statische Analyse. Linter, Type-Checker, Security-Scanner (Snyk, Dependabot, SonarQube).
5. Integrationstests. Starte Dependencies hoch (Datenbanken, Mock-Services), laufe Integrations-Suite. 5-15 Minuten typisch.
6. Artefakt-Erstellung. Baue Container-Image, signiere es, pushe es zur Registry. Oder baue statische Binaries / Pakete.
7. Deploy zu Staging. Auto-Deploy zu einer Staging-Umgebung, die Prod spiegelt.
8. Smoke-Tests / E2E. Kritische-Pfad-Validierung gegen Staging. Manche Teams laufen hier auch einen Lasttest.
9. Production-Gate. Manuelle Genehmigung (CD) oder automatische Promotion (Continuous Deployment).
10. Production-Deploy. Blue/Green, Canary oder Rolling-Deployment. Monitore Metriken nach Deploy.
11. Post-Deploy-Validierung. Smoke-Tests auf Prod. Auto-Rollback bei Regression.

Die vier Deployment-Strategien, die CD ermöglicht

• Blue/Green. Deploye neue Version ("Green") neben alter ("Blue"); switche Traffic sofort. Einfacher Rollback (zurückswitchen). Verdoppelt Infrastruktur während Übergang.
• Canary. Deploye zu kleinem % des Traffics zuerst (1-5%); monitore; erhöhe graduell. Fängt Regressionen vor Full-Rollout. Industrie-Default für High-Traffic-Systeme.
• Rolling. Ersetze Instanzen einzeln. Keine Traffic-Split-Logik nötig; langsamerer Rollout. Default in Kubernetes und den meisten Cloud-Plattform-Managed-Services.
• Feature-Flags / Dark Launching. Deploye Code dunkel, aktiviere pro Nutzer/Kohorte via Flag-Service. Entkoppelt Deploy von Release. Siehe Feature-Flags.

Was CD in der Praxis funktionieren lässt

Patterns, die reife CD-Pipelines teilen:

• Trunk-basierte Entwicklung. Kurzlebige Branches (1-2 Tage max) zu main gemerged. Keine langlebigen Feature-Branches, die wochenlang divergieren.
• Umfassende automatisierte Tests. Wenn du deiner Test-Suite nicht vertrauen kannst, kannst du CD nicht vertrauen. Ziele auf 80%+ Critical-Path-Coverage.
• Unveränderliche Artefakte. Gleiches Artefakt deployed zu Staging und Prod. Keine Rebuilds zwischen Umgebungen — zu riskant.
• Konfiguration externalisiert. Pro-Umgebungs-Konfig in Environment-Variables / Config-Service, nicht in Images gebacken.
• Database-Migration-Disziplin. Migrationen sind vorwärts-kompatibel; alter Code funktioniert weiter mit neuem Schema für mindestens einen Deploy-Zyklus (Expand-Contract-Pattern).
• Observability. Metriken, Logs, Traces in Production. Auto-Rollback triggert bei Fehlerrate / Latenz-Regression.
• Schnelle Pipeline. Deploys dauern <15 Minuten. Langsame Pipelines bedeuten weniger, größere Releases — genau der Fehlermodus, den CD verhindern soll.

Häufige CD-Pipeline-Tools

• GitHub Actions — dominant für Projekte auf GitHub. Marketplace-Ökosystem; .github/workflows YAML.
• GitLab CI/CD — erstklassig für GitLab. .gitlab-ci.yml; eingebaute Container-Registry.
• CircleCI, Buildkite, Jenkins — Drittanbieter-CI-Services. Jenkins ist Legacy, aber im Enterprise allgegenwärtig.
• Argo CD, Flux — GitOps-Controller für Kubernetes. Pull-basierte Deploys, aus Git synchronisiert.
• Spinnaker, Harness, Octopus — volle Deployment-Orchestrierungs-Plattformen. Multi-Cloud, komplexe Pipelines.
• AWS CodePipeline, Azure Pipelines, Google Cloud Build — Cloud-Anbieter-native Pipelines.

Häufige CD-Anti-Patterns

• Das "manuelle Gate für immer". CD-Pipeline endet bei Staging, weil niemand Production-Deploys vertraut. Entweder fixe das Vertrauensproblem (bessere Tests, Observability, Rollback) oder gib zu, du hast kein CD.
• Branch-basierte Umgebungen. Anderer Code auf Staging vs. Prod ("dieser Branch deployed zu Staging"). Drift akkumuliert; Staging passt, aber Prod fällt aus. Shippe nur von main.
• Deploys, die Out-of-Band-Koordination erfordern. Jemand muss eine Config-Datei in einem anderen Repo aktualisieren; ein anderes Team muss einen Service bouncen. CD überlebt das nicht.
• Catch-All-Integrationstests in Prod. Smoke-Tests sollten billig und schnell sein. Wenn deine Post-Deploy-Validierung 30 Minuten dauert, queuen sich Deploys.
• Kein Rollback-Drill. Erstes Mal, dass du den Rollback-Pfad ausführst, ist während eines echten Ausfalls. Übe Rollbacks regelmäßig.
• CI-Tests bestehen, laufen aber nicht auf dem Deploy-Artefakt. Einfach zu driften zwischen, was CI testet, und was geshippt wird. Baue einmal, teste das Artefakt, deploye das Artefakt — gleiche Bytes durchgängig.

FAQ: Continuous Delivery

Was ist der Unterschied zwischen CI, CD und Continuous Deployment?

CI (Continuous Integration): jeder Commit baut + testet. CD (Continuous Delivery): jeder Commit erreicht auch einen deploybaren Zustand, bereit zum Shippen auf Abruf. Continuous Deployment: jeder bestehende Commit auto-shippt zu Prod. CD ist nötig für Continuous Deployment, aber nicht dasselbe.

Brauche ich Kubernetes für CD?

Nein. CD funktioniert mit VMs, Containern, Serverless, sogar FTP-deploytem PHP. Kubernetes macht manche Patterns einfacher (Rolling-Updates), ist aber nicht erforderlich.

Wie lange sollte eine CD-Pipeline dauern?

Industrie-Benchmarks (DORA, Accelerate): Elite-Teams deployen in <1 Stunde ab Commit. Hochperformante Teams: 1-24 Stunden. Pipelines >24 Stunden indizieren Probleme mit Test-Infrastruktur, Dependencies oder organisatorischer Komplexität.

Kann CD in regulierten Industrien funktionieren?

Ja — Fintech, Healthcare, Government laufen alle CD. Die CD-Pipeline wird der auditierbare Trail (jede Änderung wird gebaut, getestet, signiert, deployed via reproduzierbare Schritte mit vollen Logs). Oft mehr auditierbar als manuelle Deploy-Prozesse.

Was ist mit Datenbank-Änderungen?

Der härteste Teil. Nutze Expand-Contract-Migrationen (neue Spalte hinzufügen → Code deployen, der zu beiden schreibt → alte Daten migrieren → Code deployen, der neue Spalte liest → alte Spalte droppen), Feature-Flags und Tools wie Flyway oder Liquibase, um Migrationen neben Code zu versionieren.

Wie messe ich CD-Pipeline-Qualität?

DORAs vier Schlüsselmetriken: Deployment-Frequenz, Lead-Time-für-Änderungen, Change-Failure-Rate, Mean-Time-to-Restore. Tracke diese über Zeit. Schneller + sicherer = besseres CD.

Was ist mit Microservices-CD?

Jeder Service hat seine eigene Pipeline; Deploys sind unabhängig. Koordiniere brechende API-Änderungen via Expand-Contract oder Versionierung. Vermeide verteilte Monolithen, wo N Services zusammen deployen müssen.

Wie LoadFocus zu CD-Pipelines steht

Der am häufigsten übersprungene Schritt in CD-Pipelines ist Performance-Validierung. Funktionale Tests bestehen; Latenz regrediert um 50% auf Prod-Traffic. LoadFocus-API-Lasttest integriert sich in CI/CD-Pipelines via API-Calls — lasse den Build fehlschlagen, wenn p95-Latenz deinen Schwellenwert überschreitet. Synthetisches Monitoring validiert, dass Core Web Vitals nach jedem Deploy gesund bleiben, und fängt Frontend-Regressionen, bevor Nutzer es bemerken.