Continuous Integration endet mit einem getesteten Artefakt. Das klingt gut, aber ein grüner Build heisst nicht, dass die Software in einer realistischen Umgebung tatsächlich funktioniert. Unit Tests laufen isoliert. Integrationstests laufen gegen Mocks. Solange man die Software nicht irgendwo hinstellt, das aussieht wie Produktion, und sie unter echten Bedingungen ausführt, hat man eigentlich noch nichts bewiesen. Continuous Delivery ist der Schritt, der diese Lücke schliesst.
Was Continuous Delivery tatsächlich ist#
Continuous Delivery nimmt das Artefakt aus der CI und deployed es automatisch in eine produktionsähnliche Umgebung — meist Staging genannt — wo ein weiteres Set automatisierter Tests dagegen läuft. End-to-End-Tests, Performance-Tests, Contract Tests, Security-Tests wie DAST, manchmal sogar Penetration Tests. Ziel ist es, die Probleme zu finden, die erst auftauchen, wenn die Software wirklich läuft, mit echten Services spricht und echte Datenformen verarbeitet.
Wichtig: Das Deployment nach Staging ist automatisch, aber das Release in Produktion nicht. Continuous Delivery bedeutet, dass die Software jederzeit releasbar ist — aber ein Mensch (oder eine Business-Regel) entscheidet, wann sie tatsächlich an die Kunden geht. Du bekommst einen Knopf. Du drückst ihn, wenn das Business bereit ist.
Continuous Delivery vs. Continuous Deployment#
Das ist die häufigste Verwechslung im gesamten CI/CD-Vokabular, deshalb hier ganz explizit:
- Continuous Delivery = jede Änderung wird automatisch nach Staging deployed und könnte nach Produktion released werden. Die Release-Entscheidung ist manuell.
- Continuous Deployment = jede Änderung, die alle automatisierten Tests besteht, geht automatisch in Produktion. Es gibt kein manuelles Gate.
Beide teilen sich die Abkürzung CD — das ist tatsächlich unglücklich. Wenn jemand sagt “wir machen CD”, frag nach, welches gemeint ist. Die Trade-offs sind unterschiedlich, die nötige organisatorische Reife ist unterschiedlich, und das Risikoprofil ist unterschiedlich.
Warum Continuous Delivery für die meisten Teams der Sweet Spot ist#
Die meisten Organisationen sind noch nicht reif für Continuous Deployment, und das ist in Ordnung. Regulierte Industrien, Consumer-Produkte mit marketingkoordinierten Launches, mobile Apps mit Store Approval — alle haben legitime Gründe, einen Menschen für die finale Release-Entscheidung im Loop zu behalten.
Continuous Delivery liefert fast alle Vorteile, ohne diese Entscheidung zu erzwingen. Die Pipeline beweist, dass jede Änderung theoretisch live gehen könnte. Das Artefakt ist gebaut, getestet, nach Staging deployed, nochmal getestet. Das Risiko beim Release ist klein, weil beim Release nichts Überraschendes passiert. Der Deployment-Mechanismus ist schon Hunderte Male gelaufen. Releases werden zur Routine statt zum Event.
Was im Continuous-Delivery-Schritt läuft#
Ein typischer Continuous-Delivery-Schritt ergänzt zur CI:
- Automatisches Provisioning oder Update der Staging-Umgebung.
- Deployment des Artefakts nach Staging mit demselben Mechanismus, den Produktion verwendet.
- End-to-End-Tests gegen das laufende System.
- Performance- und Load-Tests mit repräsentativen Daten.
- Dynamic Application Security Testing (DAST), das nur gegen ein laufendes System funktioniert.
- Smoke Tests, die Integrationen mit nachgelagerten Systemen prüfen.
Alles, was ein laufendes System, echte Datenformen oder echtes Netzwerkverhalten braucht, gehört hier hin.
Die Disziplin, die Continuous Delivery verlangt#
Continuous Delivery funktioniert nur, wenn die Staging-Umgebung wie Produktion aussieht — gleiches Configuration Management, gleicher Deployment-Mechanismus, gleiches Datenbanksystem, im Idealfall gleicher Massstab. Unterschiede zwischen Staging und Produktion sind die Stellen, an denen Bugs sich verstecken. Behandle Configuration Drift zwischen Umgebungen als Defekt, nicht als Feature.
Ausserdem muss der Deployment-Prozess selbst Code sein. Manuelle Schritte, Notizen in einem Wiki, “frag den Karl, der weiss es” — das skaliert nicht. Wenn ein Mensch während des Deployments etwas tun muss, ist das Deployment noch nicht wirklich automatisiert.
Key Takeaways#
- Continuous Delivery deployed jedes Artefakt automatisch in eine produktionsähnliche Umgebung. Das Release nach Produktion bleibt eine menschliche Entscheidung.
- Verwechsle Delivery nicht mit Deployment. Beide werden CD abgekürzt, aber das zweite entfernt das manuelle Gate. Sei präzise, was du tatsächlich machst.
- Es geht darum, jederzeit releasebar zu sein. Egal ob du den Knopf bei jeder Änderung drückst — die Option muss da sein.
- Staging muss wie Produktion aussehen. Drift zwischen Umgebungen ist die Stelle, an der Bugs sich verstecken.
- Deployment muss Code sein, nicht Schritte in einem Wiki. Manuelle Schritte brechen die Kette und das Vertrauen.
- Für die meisten Teams ist Continuous Delivery das richtige Ziel. Continuous Deployment ist der nächste Schritt — aber erst, wenn Organisation, Tests und Monitoring dafür bereit sind.