Continuous Delivery
- 1. Was ist Continuous Delivery?
- 2. Continuous Integration, Continuous Delivery, Continuous Deployment
- 3. Die CI/CD-Pipeline in der Praxis
- 4. Continuous Delivery vs. traditionelle Softwarewartung
- 5. Voraussetzungen für Continuous Delivery
- 6. Continuous Delivery und ISO 27001
- 7. Weiterführende Informationen
Was ist Continuous Delivery?
Continuous Delivery — häufig als CD abgekürzt — beschreibt eine Softwareentwicklungspraxis, bei der jede Codeänderung automatisch durch eine Reihe von Qualitätsprüfungen geschleust wird: Build, automatisierte Tests, statische Analyse, Staging-Deployment. Am Ende der Pipeline steht ein Artefakt, das jederzeit in die Produktionsumgebung ausgeliefert werden könnte.
Das Schlüsselwort ist „könnte”. Im Gegensatz zu Continuous Deployment, bei dem jede erfolgreiche Pipeline-Durchlauf automatisch in die Produktion geht, behält Continuous Delivery den letzten Schritt — das tatsächliche Deployment — als bewusste Entscheidung bei. Ein Mensch oder ein definierter Prozess gibt das Release frei. Das macht Continuous Delivery auch für regulierte Umgebungen praktikabel, in denen automatische Produktions-Deployments nicht zulässig oder nicht gewünscht sind.
Der Ursprung des Konzepts liegt im gleichnamigen Buch von Jez Humble und David Farley (2010), das den Ansatz erstmals systematisch beschrieb. Die Kernthese: Wenn das Ausliefern von Software schmerzhaft ist, sollte man es häufiger tun — nicht seltener. Häufige, kleine Releases reduzieren das Risiko jeder einzelnen Auslieferung und machen Probleme schneller sichtbar.
Mehr zum Thema Softwarebetreuung kann in unserem Leitfaden zum Application Management nachgelesen werden.
Continuous Integration, Continuous Delivery, Continuous Deployment
Die drei Begriffe werden häufig vermischt. Sie beschreiben unterschiedliche Reifegrade desselben Grundgedankens.
Continuous Integration (CI) ist die Basis. Entwickler integrieren ihre Codeänderungen mehrmals täglich in ein gemeinsames Repository. Jede Integration löst einen automatisierten Build und eine Testsuite aus. Das Ziel: Integrationsprobleme sofort erkennen, nicht erst Wochen später beim manuellen Zusammenführen.
Continuous Delivery (CD) baut auf CI auf. Zusätzlich zu Build und Tests durchläuft jede Änderung weitere Qualitätsstufen: Integrationstests, Performance-Tests, Security-Scans, Deployment auf eine Staging-Umgebung. Das Ergebnis ist ein Release-Kandidat, der jederzeit ausgeliefert werden kann — aber nicht automatisch ausgeliefert wird.
Continuous Deployment geht einen Schritt weiter. Jede Änderung, die alle automatisierten Prüfungen besteht, wird ohne manuellen Eingriff in die Produktion ausgeliefert. Das setzt ein sehr hohes Vertrauen in die Testabdeckung und die Pipeline-Qualität voraus. In der Praxis setzen vor allem SaaS-Unternehmen mit hoher Deployment-Frequenz auf dieses Modell.
Für die meisten Individualsoftware-Projekte — insbesondere in regulierten Branchen — ist Continuous Delivery der pragmatische Sweetspot: automatisiert genug, um menschliche Fehler zu reduzieren, kontrolliert genug, um Compliance-Anforderungen zu erfüllen.
Die CI/CD-Pipeline in der Praxis
Eine typische CI/CD-Pipeline besteht aus mehreren Stages, die eine Codeänderung durchlaufen muss, bevor sie als auslieferbar gilt.
-
Build: Der Quellcode wird kompiliert oder gebündelt. Abhängigkeiten werden aufgelöst. Das Ergebnis ist ein ausführbares Artefakt — ein Docker-Image, ein JAR-File, ein kompiliertes Binary. Wenn der Build fehlschlägt, geht nichts weiter.
-
Unit Tests: Automatisierte Tests prüfen die kleinsten Einheiten des Codes: Funktionen, Klassen, Module. Sie laufen schnell (Sekunden bis wenige Minuten) und decken die Grundfunktionalität ab.
-
Integrationstests: Tests, die das Zusammenspiel mehrerer Komponenten prüfen — etwa die Kommunikation zwischen Backend und Datenbank oder zwischen Microservices. Sie sind langsamer als Unit Tests, aber decken Fehler ab, die isolierte Tests nicht finden.
-
Statische Analyse und Security Scans: Tools wie SonarQube, ESLint oder SAST-Scanner prüfen den Code auf Qualitätsprobleme, potenzielle Bugs und Sicherheitslücken — ohne den Code auszuführen. Dependency Scanner (Snyk, Trivy) prüfen verwendete Bibliotheken auf bekannte Schwachstellen.
-
Staging-Deployment: Das Artefakt wird auf eine produktionsnahe Umgebung ausgeliefert. Hier können manuelle Abnahmetests, Performance-Tests oder explorative Tests stattfinden. Die Staging-Umgebung bildet die Produktionsumgebung möglichst genau nach — gleiche Infrastruktur, gleiche Konfiguration, maskierte Daten statt Produktionsdaten.
-
Release-Freigabe: Bei Continuous Delivery: Ein definierter Prozess oder eine berechtigte Person gibt das Deployment in die Produktion frei. Bei Continuous Deployment: automatisch, sobald alle vorherigen Stages grün sind.
Continuous Delivery vs. traditionelle Softwarewartung
Der Unterschied zwischen Continuous Delivery und traditioneller Wartung liegt nicht nur in der Technik, sondern im Grundansatz.
Traditionelle Wartung folgt einem Zyklusmodell: Änderungen werden gesammelt, in einem Release gebündelt und zu einem geplanten Zeitpunkt ausgeliefert — oft quartalsweise oder halbjährlich. Jedes Release ist groß, enthält viele Änderungen und birgt entsprechend viele Risiken. Rollbacks sind aufwendig, weil unklar ist, welche der vielen Änderungen das Problem verursacht hat. Sicherheits-Patches warten bis zum nächsten geplanten Release.
Continuous Delivery dreht dieses Modell um. Änderungen werden einzeln oder in kleinen Gruppen ausgeliefert, sobald sie validiert sind. Jedes Release ist klein, überschaubar und leicht rückgängig zu machen. Sicherheits-Patches können innerhalb von Stunden statt Wochen ausgeliefert werden. Das Risiko verteilt sich auf viele kleine Schritte statt auf wenige große.
Für die Wartung von Individualsoftware hat das konkrete Vorteile. Patch Management wird vom geplanten Großereignis zur Routineaufgabe. Fehlerbehebungen erreichen die Produktion schneller. Und die Codebasis akkumuliert weniger technische Schulden, weil Änderungen kontinuierlich integriert statt aufgeschoben werden.
Der Übergang von traditioneller Wartung zu Continuous Delivery ist allerdings kein Schalter, den man umlegt. Er erfordert Investitionen in Testautomatisierung, Pipeline-Infrastruktur und — oft unterschätzt — in die Disziplin des Teams. Eine Pipeline nützt nichts, wenn sie von niemandem gepflegt wird.
Voraussetzungen für Continuous Delivery
Continuous Delivery funktioniert nicht in einem Vakuum. Es setzt eine Reihe von Grundlagen voraus, die nicht technisch trivial sind.
Automatisierte Testabdeckung. Ohne Tests ist eine Pipeline ein leeres Versprechen. Die Testabdeckung muss nicht bei 100 % liegen — aber die kritischen Pfade der Anwendung müssen durch automatisierte Tests abgesichert sein. Andernfalls ist jede automatisierte Auslieferung ein Blindflug.
Versionskontrolle und Branch-Strategie. Continuous Delivery setzt voraus, dass der Hauptbranch jederzeit auslieferbar ist. Das erfordert eine Branch-Strategie (Trunk-Based Development, GitFlow oder eine Variante davon) und die Disziplin, keine halbfertigen Features in den Hauptbranch zu mergen.
Reproduzierbare Builds. Das Artefakt, das aus der Pipeline kommt, muss deterministisch sein: gleicher Input, gleiches Ergebnis. Das erfordert fixierte Abhängigkeiten (Lock-Files), definierte Build-Umgebungen (Container) und keine manuellen Eingriffe im Build-Prozess.
Umgebungsparität. Entwicklungs-, Test- und Produktionsumgebung sollten sich so wenig wie möglich unterscheiden. Je größer die Differenz, desto wahrscheinlicher ist es, dass ein Artefakt in Staging funktioniert und in der Produktion nicht. Container-Technologien und Infrastructure-as-Code reduzieren diese Differenz erheblich.
Continuous Delivery und ISO 27001
Für Unternehmen, die nach ISO-72001 arbeiten oder mit zertifizierten Dienstleistern zusammenarbeiten, ist Continuous Delivery kein Widerspruch zur Norm — im Gegenteil. Die Annex-A-Controls der ISO 27001, insbesondere die Controls 8.25 bis 8.28, fordern genau das, was eine gute CI/CD-Pipeline liefert: dokumentierte Entwicklungsprozesse, automatisierte Tests, Umgebungstrennung und nachvollziehbare Änderungshistorien.
Die sichere Softwareentwicklung nach ISO 27001 verlangt, dass Sicherheitsprüfungen Teil des Entwicklungsprozesses sind — nicht nachgelagert. Eine CI/CD-Pipeline, die SAST-Scans, Dependency Checks und automatisierte Sicherheitstests integriert, erfüllt diese Anforderung strukturell. Jede Änderung wird geprüft, jedes Ergebnis dokumentiert, jeder Deployment-Schritt ist nachvollziehbar.
