Continuous Integration, Delivery und Deployment im Vergleich

Sehen wir uns zunächst die zentralen Merkmale von CI und CD sowie die Unterschiede zwischen ihnen an.

Continuous Integration (CI)

Continuous Integration (CI) ist ein Ansatz, bei dem Ihre Codeänderungen automatisch geprüft werden, um Ihnen schnelles Feedback zu Ihrer Arbeit zu geben. In einem CI-Workflow führt Ihr CI-Server bei jedem Commit einen Buildvorgang durch und führt automatisierte Tests aus. Diese Testreihen umfassen in der Regel Unit-Tests, Integrationstests und weitere Tests wie Linting oder statische Analysen. Wenn eine Phase im CI-Prozess fehlschlägt, erhalten Sie automatisch eine Rückmeldung, damit Sie das Problem beheben können. Der Prozess beginnt von Neuem, wenn Sie eine Korrektur committen.

Continuous Delivery und Continuous Deployment im Vergleich

Der Unterschied zwischen Continuous Delivery und Continuous Deployment liegt in der abschließenden Produktionsfreigabephase.

Bei Continuous Delivery muss das Build-Artefakt manuell für die Produktion freigegeben werden. Der Releaseprozess ist in der Regel vollständig automatisiert, aber jemand muss die Entscheidung treffen, ob und wann ein bestimmter Build veröffentlicht wird. Im Gegensatz dazu wird bei Continuous Deployment der Build stets automatisch für die Produktion freigegeben, sofern die vorhergehenden Prozessphasen erfolgreich abgeschlossen wurden.

Zwischen Continuous Delivery und Continuous Deployment entscheiden

Es hängt von Ihrem Kontext ab, ob Continuous Delivery oder Continuous Deployment für Sie besser geeignet ist.

Bei Softwareprodukten wie Mobil-Apps oder APIs ist es vielleicht nicht ideal, wenn bei jedem erfolgreichen Commit eine neue Version veröffentlicht wird. Stattdessen wird manchmal vorgezogen, Releases in regelmäßigen Abständen zu veröffentlichen oder abzuwarten, bis eine Mindestanzahl von Änderungen zusammenkommt.

In diesem Fall können Sie Continuous Delivery nutzen, um Änderungen gleich nach der Umsetzung zu testen und Releases in einer Vorproduktionsumgebung zu prüfen. Continuous Delivery bietet auch eine Gelegenheit für manuelle Abnahmetests vor jedem Release.

Continuous Deployment funktioniert wiederum gut bei webbasierten Anwendungen und Services. Hier gehören häufige – tägliche oder sogar stündliche – Updates zum Standard.

Durch Continuous Deployment können Sie Updates Stück für Stück veröffentlichen und zeitnahes Feedback erhalten. Sie können Continuous Deployment auch nutzen, um Experimente durchzuführen und Ihre Annahmen mit realen Benutzer*innen zu testen, wohl wissend, dass Sie bei Bedarf mit einem neuen Release jederzeit die Richtung ändern können.

Schließlich ist es wichtig zu wissen, dass Sie auch ein gewisses Maß an manuellen Abnahme- und Explorationstests in Ihren Continuous-Deployment-Prozess integrieren können.

Anstatt manuelle Tests vor jedem Release vorzuschreiben, können Sie Änderungen regelmäßig in einer Staging-Umgebung bereitstellen und diese Tests wöchentlich oder in längeren Abständen durchführen.

In der Zwischenzeit können Änderungen, die alle automatischen Tests bestanden haben, für den Produktionseinsatz freigegeben werden. Wenn Sie in der Staging-Umgebung ein Problem entdecken, sorgt Ihre automatisierte Pipeline dafür, dass Sie schnell einen Fix für die Produktion bereitstellen können.

CI/CD stellt zwei Stufen im Build-, Test- und Releaseprozess von Softwareanwendungen dar.

Eine CI/CD-Pipeline ist ein Tool, das Ihr Vertrauen in Ihren Code schrittweise erhöht.

Jede erfolgreiche Phase stärkt Ihr Vertrauen, bis Sie sich sicher sind, dass Sie Ihren Code für den Benutzereinsatz freigeben können. Wenn hingegen eine Phase fehlschlägt, wird der Buildprozess angehalten, und Sie müssen entweder den Fehler korrigieren oder Ihre Änderungen rückgängig machen. Sobald das Problem gelöst ist, beginnt der Prozess von Neuem.

Als erste Phase im Build-, Test- und Releaseprozess bietet CI schnelles Feedback durch Prüfungen. Unmittelbares Feedback zu Ihren Codeänderungen hilft Ihnen, effizienter zu arbeiten, da Sie weniger Kontextwechsel vornehmen müssen. Anstatt stunden- oder tagelang auf die Ergebnisse manueller Tests zu warten, erhalten Sie innerhalb von Minuten Warnmeldungen über Probleme, die durch Ihre Änderungen entstanden sind.

Wenn der Build mit Ihren Änderungen die CI-Tests besteht, ist eine Bereitstellung in Vorproduktionsumgebungen gerechtfertigt. Zu diesem Zeitpunkt können Sie länger laufende und ressourcenintensivere Tests durchführen.

Durch die Automatisierung möglichst vieler CD-Schritte wird die Feedbackschleife weiter verkürzt und ein effizienterer Ablauf gewährleistet. So können Sie zum Beispiel nicht nur Tests automatisieren, sondern auch das Zurücksetzen von Vorproduktionsumgebungen und das Bereitstellen von Builds in diesen Umgebungen.

Wenn Sie neu bei CI/CD sind, würden wir Ihnen empfehlen, sich nicht so sehr auf die Wahl zwischen Continuous Integration und Continuous Delivery/Deployment zu konzentrieren, sondern stattdessen zu entscheiden, wo Sie anfangen und wie weit Sie gehen wollen.

Sowohl CI als auch CD umfassen mehrere Schritte, sodass Sie Ihre Prozesse Stück für Stück weiterentwickeln können.

Finden Sie Ihren Startpunkt

Wenn Sie bereits Teile Ihres Build- oder Releaseprozesses automatisiert oder automatisierte Tests geschrieben haben, können diese einen natürlichen Ausgangspunkt darstellen. Wenn dies nicht der Fall ist, sollten Sie zunächst überlegen, welche Teile Ihres Build-, Test- und Releaseprozesses am zeitaufwändigsten sind oder aufgrund unzureichender Tests zu Problemen in der Produktion führen können.

Viele Teams beginnen mit CI, weil dies weniger Koordination mit anderen Unternehmensbereichen erfordert und das schnelle Feedback durch automatisierte Unit- und Integrationstests die Codequalität verbessert.

Da hierbei die Vorteile von CI den Beteiligten klar werden, entsteht außerdem eine Kultur der Testautomatisierung, die für effektives CI/CD unerlässlich ist und zu einer weiteren Ausweitung Ihrer automatisierten Tests führen kann.

Wenn Sie hingegen bereits heute sowohl die Release-Koordination als auch die Codeentwicklung verantworten, könnten Sie langfristig Zeit sparen, wenn Sie als Erstes die abschließende CD-Phase (die Bereitstellung in die Produktionsumgebung) automatisieren.

CI bietet zwar eine solide Grundlage für CD, die Entscheidung zwischen Continuous Delivery und Continuous Deployment hängt jedoch von Ihren Anforderungen ab. Auch wenn Ihr langfristiges Ziel Continuous Deployment ist, besteht die übliche Strategie darin, mit Continuous Delivery zu beginnen. Sobald Sie Vertrauen in Ihre Arbeitsabläufe gefasst haben, können Sie den Sprung zur Automatisierung der abschließenden Produktionsfreigabe wagen.

Verbessern Sie Ihre CI/CD-Prozesse

CI und CD funktionieren am besten, wenn Sie Entwicklungsaufgaben in kleinere Blöcke aufteilen und Ihre Änderungen regelmäßig committen.

Wenn Sie Continuous Deployment anstreben, müssen Sie sich überlegen, wie Sie Funktionen verwalten, die noch nicht veröffentlichungsreif sind, obwohl dazugehörige Änderungen es bereits in Commits geschafft haben. Dazu können Sie Feature-Flags oder eine Branching-Strategie verwenden, die unvollständige Entwicklungen vom Release-Branch isoliert und gleichzeitig sicherstellt, dass jede Codeänderung trotzdem automatisch kompiliert und getestet wird.

Fassen wir kurz zusammen:

• Bei Continuous Integration (CI) werden automatisierte Tests durchgeführt und geprüft, ob Ihre Anwendung nach jedem Commit kompiliert werden kann.
• Sowohl Continuous Delivery als auch Continuous Deployment (CD) beinhalten die automatische Bereitstellung von Build-Artefakten in Test- und Staging-Umgebungen, um weitere Tests durchzuführen. Normalerweise werden diese Schritte nach Abschluss der CI-Phase durchgeführt.
  • Bei Continuous Delivery entscheiden Sie, wann Sie ein bestimmtes Build-Artefakt für die Produktion freigeben; die Freigabe erfolgt manuell.
  • Beim Continuous Deployment wird jede Codeänderung nach erfolgreichem Abschluss der vorherigen Phasen automatisch für die Produktion freigegeben.
• CI und CD ergänzen einander und zielen darauf ab, Probleme schnell zu erkennen und Ihnen Vertrauen in Ihre Änderungen zu geben, bevor Sie sie veröffentlichen.
• Ein robuster, auf Testautomatisierung aufbauender CI/CD-Prozess ermöglicht eine schnellere und sicherere Bereitstellung von Fehlerkorrekturen, sollte es ein Fehler einmal in der Produktion schaffen.
• Ein vollständig automatisierter Build-, Test- und Releaseprozess umfasst sowohl CI als auch CD – aber Sie können auch nur mit dem einen oder dem anderen beginnen und Ihren Prozess schrittweise ausbauen.
  • Viele Teams beginnen mit Continuous Integration, da die Testautomatisierung normalerweise in die Verantwortung des Entwicklungsteams fällt.
  • Wenn Ihre Zuständigkeiten jedoch auch das Release-Management umfassen, können Sie Zeit sparen, indem Sie zunächst diesen Bereich automatisieren, um sich dann auf den Aufbau Ihres CI-Prozesses zu konzentrieren.