METHODE

Continuous Delivery

Jede Änderung wird automatisch fürs Release vorbereitet. Den Knopf zum tatsächlichen Production-Push drückt ein Mensch.

Zuletzt geprüft: 2026-05-24 vonKevin Riedl wiki ↗

Continuous Delivery ist die verantwortliche Cousine von Continuous Deployment. Jede Änderung durchläuft dieselbe automatisierte Build-, Test- und Release-Vorbereitungs-Pipeline. Das Artefakt am Ende ist shippbar. Ob es tatsächlich shippt, entscheidet ein Mensch.

Warum die meisten Teams bei CD stoppen statt zu Continuous Deployment überzugehen: Die Kosten eines schlechten Deploys sind hoch genug, dass ein Mensch in der Schleife die Latenz wert ist. Auf Continuous Deployment wechseln, wenn Monitoring, Testabdeckung und Rollback-Story gut genug sind, dass der Mensch nichts mehr signalisiert."

// FAQ

Häufige Fragen

Häufige Fragen

Sobald der menschliche Push-Knopf nichts mehr signalisiert außer Latenz. Wenn der Verantwortliche jeden Build durchwinkt, ohne wirklich zu prüfen, ist die manuelle Stufe Theater. Voraussetzung für den Wechsel: Monitoring mit Alerting, Feature Flags und einminütige Rollback-Story.
Dann nicht zu Continuous Deployment wechseln. CD mit schwachen Tests heißt: jeder Bug geht eine Stunde schneller live. Erst Test-Confidence aufbauen, dann automatisieren. Tooling vor Disziplin ist immer falsch.
Der Engineer, der das Change geschrieben hat, nicht eine zentrale Release-Person. Wer den Code kennt, kennt den Blast-Radius. Zentrale Release-Manager sind ein Reflex aus Wasserfall-Zeiten und passen nicht in CD-Workflows.