Einführung in Continuous Delivery

Continuous Delivery (CD) baut auf Continuous Integration (CI) auf und automatisiert die Schritte, die für die Produktionsfreigabe einer Softwareanwendung notwendig sind.

Jedes Mal, wenn Sie Codeänderungen in einen dafür vorgesehenen Branch mergen, führt Ihr CI-Prozess eine Reihe von Prüfungen durch – zum Beispiel automatisierte Unit-Tests – und erstellt einen Build. Durch Continuous Delivery wird dieser Prozess erweitert, indem jeder Build automatisch in einer Reihe von Test- und Staging-Umgebungen bereitgestellt und dort mit weiteren automatisierten Tests geprüft wird.

Diese Tests können Integrationstests, UI-Tests, Performancetests (darunter Last-, Soak- und Stresstests) oder End-to-End-Tests sein. Je nach Branche kann Continuous Delivery auch genutzt werden, um die Sicherheit oder Barrierefreiheit zu testen oder manuelle Benutzerakzeptanztests oder explorative Tests durchzuführen. Wenn ein Build jede Phase erfolgreich durchlaufen hat, ist er bereit für die Produktionsfreigabe.

Wie bei Continuous Integration liegt das Geheimnis eines effektiven Continuous-Delivery-Systems darin, den Prozess so weit wie möglich zu automatisieren. Dazu gehört auch Feedback zu jeder Phase und die Benachrichtigung des Teams, wenn ein Build eine Phase nicht besteht, damit das Problem schnell behoben werden kann.

Sowohl Continuous Delivery als auch Continuous Deployment beinhalten die automatische Bereitstellung von Builds in Umgebungen und die Durchführung automatisierter Tests. Aus diesem Grund werden die beiden Begriffe manchmal synonym verwendet. Es gibt jedoch einen relevanten Unterschied zwischen Continuous Delivery und Continuous Deployment.

Bei Continuous Deployment werden Codeänderungen automatisch in die Produktion übernommen, sobald sie die einzelnen Testphasen erfolgreich durchlaufen haben. Bei Continuous Delivery hingegen wird der letzte Schritt – die Freigabe Ihrer Software für die Produktion – manuell durchgeführt.

Continuous Deployment mag zwar als Idealziel für jedes Software-Entwicklungsteam erscheinen, aber es gibt gute Gründe, warum sich viele Teams für Continuous Delivery entscheiden.

Mehr zum Unterschied zwischen Continuous Delivery und Continuous Deployment.

Die letzte Phase eines CI/CD-Prozesses umfasst das Deployment Ihrer Codeänderungen in die Produktion. Bei Continuous Delivery erfolgt die Entscheidung über die Produktionsfreigabe manuell, auch wenn der eigentliche Releaseprozess automatisiert ist.

Einige Teams verwenden Continuous Delivery als Zwischenschritt zu Continuous Deployment. Das manuelle Auslösen der endgültigen Bereitstellung in die Produktion schafft ein Sicherheitsnetz, während Sie Vertrauen in Ihre automatisierten Tests und Prüfungen aufbauen. So könnten Sie sich zum Beispiel dafür entscheiden, mehrere Monate lang Continuous Delivery zu verwenden, bevor Sie dazu übergehen, jede Codeänderung, die Ihre Tests besteht, automatisch in die Produktion zu übernehmen.

Die Bereitstellung von mehreren Updates pro Tag oder Stunde ist jedoch nicht immer die beste Wahl. Bei versionierter Software – etwa Mobil-Apps, APIs, Embedded-Software oder Desktopanwendungen – ist es oft sinnvoll, Änderungen in größere Releases zusammenzufassen. Benutzer*innen von installierten Produkten wollen nicht ihre Anwendungen alle paar Stunden aktualisieren, und bei APIs kann ein Update auf eine neue Version erhebliche Auswirkungen auf die Nutzung haben. Bei der Entscheidung zwischen Continuous Delivery und Continuous Deployment geht es darum, die richtige Wahl für Ihr Unternehmen und Ihre Benutzer*innen zu treffen.

Auch wenn die genauen Buildschritte, Umgebungen und Tests von Ihrem Produkt und Ihrer Organisation abhängen, können Ihnen die folgenden allgemeinen Grundsätze beim Aufbau Ihres Continuous-Delivery-Prozesses helfen:

• Mit CI beginnen: Die Einführung von Continuous Integration vor Continuous Delivery ist in den meisten Fällen sinnvoll. Da CI in erster Linie das Entwicklungsteam betrifft, kann sich dieses an die Automatisierung des Build-, Test- und Deployment-Prozesses gewöhnen, bevor externe Beteiligte einbezogen werden.
• CD-Prozess auf schnelles Feedback ausrichten: Durch eine frühzeitige Erkennung von Problemen wird Ihr Entwicklungsprozess effizienter. Bestimmte Phasen können parallel ausgeführt werden, z. B. automatisierte UI-Tests auf unterschiedlichen Plattformen. Ebenso können länger laufende oder ressourcenintensive Performancetests aufgeschoben werden, bis der Build die vorherigen Phasen erfolgreich durchlaufen hat.
• Stakeholder einbeziehen: Die DevOps-Philosophie hinter CI/CD ermutigt Entwicklungsteams, Silos zu durchbrechen und den Software-Entwicklungsprozess in seiner Gesamtheit zu betrachten. Beziehen Sie in die Gestaltung Ihrer CD-Pipeline alle Personen ein, die am aktuellen Releaseprozess beteiligt sind – von Operations über Sicherheit bis hin zu Marketing und Support.
• Tests automatisieren: Automatisierte Tests sind eine Grundvoraussetzung für Continuous Delivery, da sie zuverlässig und schnell bestätigen, dass sich Ihre Software wie vorgesehen verhält. Wenn Sie noch keine automatisierten Tests haben, priorisieren Sie die Bereiche mit dem größten Wirkungspotenzial und bauen Sie Ihre Test-Coverage schrittweise auf.
• Build-Artefakte wiederverwenden: Um Inkonsistenzen zu vermeiden, sollten Build-Artefakte aus der CI-Phase in identischer Form in den einzelnen Vorproduktionsumgebungen und in der Produktion selbst eingesetzt werden.
• Testumgebungen automatisch zurücksetzen: Idealerweise sollten die Testumgebungen für jeden neuen Build in Ihrem CI/CD-Prozess zurückgesetzt werden. Durch Container und Infrastructure-as-Code-Ansätze wird es einfacher, neue Umgebungen nach Bedarf anzulegen und zu entsorgen.
• Stakeholder-Bedürfnisse berücksichtigen: Eine Ausnahme vom vorangegangenen Punkt bilden Staging-Umgebungen, die von Support-, Vertriebs- oder Marketingteams genutzt werden, um Neuerungen kennenzulernen. Diese Teams bevorzugen es möglicherweise, Umgebungen nur auf Anfrage zu aktualisieren, um laufende Arbeitsvorgänge nicht zu unterbrechen.
• DevSecOps einbeziehen: Aufgrund der Verzögerungen durch Sicherheitsaudits und die damit verbundenen langen Berichte gelten Infosec- und Cybersecurity-Teams oft als Hindernisse für häufige Releases. Nutzen Sie den DevSecOps-Ansatz und integrieren Sie Sicherheitsanforderungen von Anfang an in Ihre Pipeline.
• Manuellen Testbedarf berücksichtigen: Je nach Geschäftsbereich sollten Sie einige manuelle Explorationstests durchführen, um unerwartete Fehlermöglichkeiten zu identifizieren. Anstatt für jede Codeänderung manuelle Tests vorzuschreiben, sollten Sie optionale Schritte oder alternative Pipelines erwägen, die wöchentlich oder monatlich ausgeführt werden.
• Releasevorgang automatisieren: Continuous Delivery bedeutet zwar, dass die Entscheidung über die Produktionsfreigabe manuell getroffen wird, aber der Releasevorgang selbst sollte automatisiert werden. Sie sollten in der Lage sein, jeden „guten“ Build mit einem einzigen Befehl in die Produktion zu übernehmen.

Durch Continuous Delivery können Teams ihre Software schneller und häufiger veröffentlichen und gleichzeitig die Anzahl der Bugs reduzieren, die es in die Produktionsumgebung schaffen. Der Schlüssel dazu ist, sicherzustellen, dass Ihr Code immer releasefähig ist, indem Änderungen kontinuierlich getestet und Probleme sofort behoben werden.

Continuous Delivery bietet darüber hinaus zahlreiche weitere Vorteile:

• Häufigere Releases bedeuten, dass Sie Ihre Markteinführungszeiten verkürzen und neue Funktionen, Korrekturen und Verbesserungen schneller bereitstellen können.
• Durch den kontinuierlichen Testprozess erhalten Sie schnelles Feedback zu Ihrer Arbeit. Wenn eine kürzlich vorgenommene Änderung eine Sicherheitslücke einschleust, Ihre App unter bestimmten Umständen zum Einfrieren bringt oder einen API-Aufruf fehlschlagen lässt, erfahren Sie davon viel früher als bei einem herkömmlichen Release-Test-Prozess.
• Das frühere Erkennen von Problemen sorgt für einen effizienteren Entwicklungsprozess. Einerseits ist die Änderung noch relativ frisch in Ihrem Gedächtnis, und andererseits ist das Risiko geringer, dass weitere Codeänderungen auf den fehlerhaften Code aufbauen.
• Die Automatisierung wiederholungsintensiver Build-, Test- und Release-Aufgaben stellt eine konsistente Ausführung sicher und verringert das Fehlerrisiko. Gleichzeitig können sich die Teammitglieder verstärkt auf die Wertschöpfung konzentrieren.
• Wenn Sie in automatisierte Tests investieren, können Sie Ihre Software gründlicher testen. Dazu gehören z. B. konsistente Tests auf mehreren Plattformen, die Überprüfung der Barrierefreiheit oder der Abgleich der Performance mit einer Baseline.
• Indem Sie das Zurücksetzen von Umgebungen und das Deployment von Builds automatisieren, können Sie Ihre Infrastruktur effizienter nutzen, ganz gleich, ob Sie On-Premises-Server oder eine Cloud-Buildfarm verwenden.
• Automatisierte Deployments auf Staging-Sites sorgen dafür, dass Ihre Produkt-, Marketing- und Supportteams neue Features ohne zusätzliche manuelle Unterstützung durch das Entwicklungs- oder Operations-Team ausprobieren können.
• Durch Continuous Delivery wird Ihr Releaseprozess robust und reproduzierbar. Gleichzeitig behalten Sie die Kontrolle über den genauen Release-Zeitpunkt. Mit einem CD-System können Sie kleinere Verbesserungen wöchentlich, täglich oder sogar stündlich vornehmen.

Die Implementierung eines Continuous-Delivery-Prozesses kann mit einigen Herausforderungen verbunden sein:

• Teamübergreifende Kooperation: Sie werden wahrscheinlich eine Zusammenarbeit zwischen mehreren Unternehmensbereichen benötigen, z. B. Operations-, Infrastruktur- und Sicherheitsteams. Das Durchbrechen von Silos kann zwar kurzfristig mit Herausforderungen verbunden sein, führt aber langfristig zu einer verbesserten Zusammenarbeit und Effektivität.
• Zeitaufwand: Die Automatisierung Ihrer Build-, Test- und Releaseprozesse braucht Zeit. Wenn Sie jedoch Ihren Prozess mit einem iterativen Ansatz sukzessive aufbauen, lässt sich dieser Aufwand leichter bewältigen. Die Erfassung von Statistiken z. B. zu Fehlerquoten und Buildzeiten sowie der Vergleich mit manuellen Verfahren ist eine wirksame Methode, um den Stakeholdern die Rentabilität Ihrer Investitionen zu demonstrieren.
• Skalierungsprobleme: Wenn Sie Ihren Continuous-Delivery-Prozess skalieren, werden Sie wahrscheinlich mehrere Builds und Tests parallel ausführen wollen. An diesem Punkt kann die Anzahl der verfügbaren Server einen Engpass darstellen. Nachdem Sie die Performance Ihrer Pipeline optimiert haben, sollten Sie den Wechsel zu einer cloud-gehosteten Infrastruktur erwägen, um Ihre Buildfarm nach Bedarf skalieren zu können.

Der Aufbau eines Continuous-Delivery-Prozesses mag schwierig erscheinen, aber mit der richtigen Herangehensweise können Sie damit Ihre Software-Releases dramatisch beschleunigen und gleichzeitig Fehler minimieren.

Entscheidend für eine effektive Implementierung von Continuous Delivery ist eine DevOps-Mentalität. Anstatt die Softwareentwicklung als eine Einbahnstraße zu betrachten, auf der Anforderungen, Code und Berichte von einem Team an das nächste weitergereicht werden, geht es bei DevOps um Zusammenarbeit und schnelles Feedback mittels kurzer, iterativer Zyklen.

Wenn Sie sich diese Mentalität zu eigen machen wollen, hilft es, wenn Sie Ihre Definition von „fertig“ überdenken. Statt einen Beitrag als abgeschlossen zu betrachten, sobald Sie Ihren Code an das nächste Team in der Kette übergeben haben, gilt Ihr neues Feature oder Ihre Codeänderung erst dann als fertig, wenn das Release veröffentlicht wurde. Wenn an irgendeinem Punkt in der Pipeline ein Problem auftritt, wird durch sofortiges Feedback und gemeinsame Korrekturarbeit schneller eine Lösung gefunden als durch langwierige Berichte, die über ein Change Board übermittelt und genehmigt werden müssen. Darum geht es bei der Continuous Delivery.

Weitere Tipps für den Einstieg in Continuous Delivery finden Sie in unserem Best-Practices-Leitfaden für CI/CD.

Continuous Delivery erleichtert und beschleunigt die Bereitstellung von Software-Releases, sodass Sie die Releasefrequenz Ihrer Produktionsversionen hochfahren können. Anstelle eines großen vierteljährlichen oder jährlichen Updates können häufig kleinere Updates bereitgestellt werden. Dies bedeutet nicht nur, dass Ihre Kunden schneller von neuen Funktionen und Fehlerkorrekturen profitieren. Sie erhalten darüber hinaus auch einen Einblick in die Nutzung Ihrer Software „in freier Wildbahn“ und können Ihre Pläne entsprechend anpassen.

Während einige Organisationen lieber die Kontrolle über den letzten Schritt des Releaseprozesses behalten wollen, besteht für andere die logische Konsequenz einer CI/CD-Pipeline darin, mit einer Methode namens Continuous Deployment auch die Veröffentlichung von Produktionsreleases zu automatisieren. Mehr dazu erfahren Sie im nächsten Abschnitt unseres CI/CD-Leitfadens.

TeamCity ist eine CI/CD-Plattform, die umfassende Unterstützung für eine Vielzahl von Buildtools, Testframeworks, Containern und Cloudinfrastruktur-Systemen bietet. Ganz gleich, ob Sie Ihre Build-Systeme lokal, in der Cloud oder kombiniert hosten – TeamCity koordiniert Ihre Build-Aufgaben mit maximaler Effizienz.

Dank der individualisierbaren Pipeline-Logik von TeamCity können Sie wählen, wann Sie Prozesse parallel ausführen möchten – z. B. Tests auf unterschiedlichen Plattformen – und wann ein erfolgreicher Abschluss erforderlich ist, bevor die nächste Phase beginnen kann. Konfigurierbare Benachrichtigungen stellen Ihnen stets die benötigten Informationen bereit, egal wo Sie gerade arbeiten, und sie helfen Ihnen, unnötige Unterbrechungen zu vermeiden. Detaillierte Ergebnisse wiederum sorgen dafür, dass es immer einen klaren Weg in die Produktion gibt.