Continuous Delivery
Jede Änderung wird automatisch fürs Release vorbereitet. Den Knopf zum tatsächlichen Production-Push drückt ein Mensch.
Continuous Delivery ist die verantwortliche Cousine von Continuous Deployment. Jede Änderung durchläuft dieselbe automatisierte Build-, Test- und Release-Vorbereitungs-Pipeline (das CI/CD-Rückgrat). 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 kein Signal mehr addiert.
Beispiel für die Wahl pro Service, nicht pro Firma: Dieselbe Firma betreibt eine Marketing-Site und ein Payments-Ledger. Die Marketing-Site ist ein großartiger Fit für volles Continuous Deployment, wo ein schlechter Deploy einen Tippfehler bedeutet und ein Rollback trivial ist, also kann jeder grüne Build unbeaufsichtigt shippen. Das Payments-Ledger bleibt bei Continuous Delivery mit einem Menschen, der den Knopf drückt, weil ein schlechter Deploy dort Geld falsch bewegt und der Mensch wirklich Signal addiert, nicht nur Latenz. „Sollen wir Deploys automatisieren" als eine firmenweite Entscheidung zu behandeln ist der Fehler; es ist ein Risiko-Urteil pro Service.
Es gibt eine regulatorische Dimension, die es zu benennen lohnt. In Domänen mit Change-Control- oder Audit-Anforderungen (Finanzen, Gesundheit, alles, was personenbezogene Daten unter der DSGVO berührt) ist der menschliche Freigabeschritt in Continuous Delivery nicht nur Risikomanagement, sondern oft die dokumentierte Kontrolle, die ein Prüfer sehen will: wer dieses Release freigab, gegen welche Evidenz, wann. Teams in solchen Umfeldern sollten volles Continuous Deployment nicht als Reife-Abzeichen jagen; das manuelle Gate ist ein Feature, von dem ihre Compliance-Story abhängt. Automatisiere alles bis zum Knopf, dann lass den Knopf, wo der Audit-Trail ihn braucht.
Der ehrliche Trade-off: Continuous Delivery kauft dir den Großteil der Geschwindigkeit voller Automatisierung, während ein menschliches Veto auf dem unumkehrbaren Schritt bleibt, zum Preis, dass dieses Veto ein Engpass ist, wenn der Mensch langsam oder abwesend ist. Die Voraussetzung, darüber hinauszuwachsen, ist real, nicht aspirativ: eine TDD-gestützte Suite, hinter der das Team shippt, ein Minuten-nicht-Stunden-Rollback und eine On-Call-Rotation. Ohne diese drei ist „Continuous Delivery" ein Knopf, den niemand zu drücken wagt, und die Pipeline ist Dekoration auf einem ansonsten gesunden SDLC.