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.