CI und CD: ein Blick hinter die Kulissen
Von Markus Eisele*
Die Akronyme CI und CD stehen für Continuous Integration und Continuous Delivery beziehungsweise Continuous Deployment. Prinzipiell zielen CI- und CD-Verfahren auf die kontinuierliche Automatisierung und Überwachung des gesamten Lifecycles einer Applikation ab, von der Integrations- und Test- bis hin zur Delivery- und Deployment-Phase. Diese zusammenhängenden Prozesse werden oft als „CI/CD-Pipeline“ bezeichnet und von Entwicklungs- und Betriebsteams unterstützt, die auf agile Weise in einem DevOps- oder SRE (Site Reliability Engineering)-Ansatz zusammenarbeiten.
CI betrifft den Automatisierungsprozess für Entwickler und umfasst im Prinzip die regelmäßige Bereitstellung von Codeänderungen. CD bezeichnet sowohl Continuous Delivery als auch Continuous Deployment. Die verwandten Konzepte werden teilweise synonym verwendet. Bei beiden Verfahren geht es um die Automatisierung weiterer Phasen der Pipeline. Werden die Begriffe unterschieden, soll die jeweilige Stufe der Automatisierung verdeutlicht werden. Continuous Delivery bedeutet, dass App-Änderungen eines Entwicklers automatisch auf Bugs getestet und in ein Repository wie GitHub oder eine Container-Registry hochgeladen werden, sodass sie vom Operations-Team in einer Live-Produktivumgebung bereitgestellt werden können. Continuous Deployment schließlich betrifft die automatische Freigabe und Übertragung von Entwickleränderungen vom Repository in die Produktivumgebung. Dieser Vorgang soll der Überlastung von Betriebsteams durch manuelle Prozesse entgegenwirken, die die Anwendungsbereitstellung verlangsamen. Continuous Deployment baut auf den Vorteilen von Continuous Delivery auf, indem es auch noch die nächste Stufe in der Pipeline automatisiert.
Der agile Workflow in einer CI/CD-Pipeline im detaillierten Überblick
In der modernen Anwendungsentwicklung arbeiten mehrere Entwickler an unterschiedlichen Features der gleichen App. Die Zusammenführung aller Quellcode-Branches an einem Tag kann zu einem hohen Arbeits- und Zeitaufwand führen, da die verschiedenen Branches und App-Änderungen isoliert und parallel arbeitender Entwickler miteinander in Konflikt treten können. Problematisch ist in diesem Zusammenhang auch, wenn jeder Entwickler seine eigene – anforderungsspezifisch angepasste – lokale IDE (Integrated Development Environment) nutzt anstatt einer gemeinsamen Cloud-basierten IDE.
Zu bewältigen sind diese Herausforderungen mit dem Continuous-Integration-Verfahren. Damit können Entwickler ihre Codeänderungen in einem gemeinsamen „Branch“ oder „Trunk“ viel häufiger zusammenführen. Sobald die Änderungen konsolidiert sind, werden sie validiert. Dies erfolgt durch die automatische Erstellung der Applikation und die Durchführung von Tests. In der Regel werden dabei Unit- und Integrationstests genutzt, um sicherzustellen, dass Änderungen die Funktionsfähigkeit der Applikation nicht beeinträchtigen. Wenn die automatische Prüfung Konflikte zwischen neuem und bestehendem Code erkennt, lassen sich diese mithilfe von CI schneller und häufiger beheben.
Nach der Automatisierung von Builds sowie Unit- und Integrationstests mittels CI wird im Continuous-Delivery-Prozess der validierte Code in ein Repository hochgeladen. Ein effizientes Continuous-Delivery-Verfahren erfordert, dass CI bereits Bestandteil der Entwicklungs-Pipeline ist. Ziel von Continuous Delivery ist eine Codebasis, die jederzeit für das Deployment genutzt werden kann. Continuous Delivery beinhaltet dabei in jeder Phase – von der Zusammenführung von Codeänderungen bis hin zur Bereitstellung produktionsreifer Builds – die Testautomatisierung und die Automatisierung der Codefreigabe. Am Ende dieses Prozesses ist das Operations-Team in der Lage, eine Anwendung schnell und einfach in der Produktionsumgebung zur Verfügung zu stellen.
Die letzte Stufe einer ausgereiften CI/CD-Pipeline ist das Continuous Deployment. Als Erweiterung der Continuous Delivery, bei der produktionsreife Builds automatisch in ein Code-Repository geladen werden, wird beim Continuous Deployment auch die Übertragung einer App in die Produktivphase automatisiert. Da dieser Phase in der Pipeline kein manuelles Gate vorgeschaltet ist, kommt es beim Continuous Deployment in hohem Maße auf eine sehr gut durchdachte Testautomatisierung an. In der Praxis bedeutet Continuous Deployment, dass App-Änderungen eines Entwicklers binnen weniger Minuten nach ihrer Erstellung live gehen können – vorausgesetzt, sie absolvieren die automatischen Tests erfolgreich.
Insgesamt führen die miteinander verbundenen CI- und CD-Verfahren zu einer weniger risikoreichen Anwendungsbereitstellung, da Änderungen in kleinen Teilen und nicht auf einmal freigegeben werden. Die initialen Investitionen dürfen allerdings nicht unterschätzt werden, gerade hinsichtlich der benötigten automatisierten Tests für die diversen Prüf- und Release-Phasen in der CI- und CD-Pipeline.
Viele Unternehmen arbeiten zunächst mit CI und setzen den Prozess später mit der Automatisierung von Delivery und Deployment fort, zum Beispiel bei der Entwicklung Cloud-nativer Apps. Ihre schnelle Bereitstellung wird durch DevOps-Workflows mit CI- und CD-Verfahren nachhaltig unterstützt.
* Markus Eisele ist Developer Strategist bei Red Hat
Creative Commons Lizenz CC BY-ND 4.0
Sie dürfen:
Teilen — das Material in jedwedem Format oder Medium vervielfältigen und weiterverbreiten und zwar für beliebige Zwecke, sogar kommerziell.
Der Lizenzgeber kann diese Freiheiten nicht widerrufen solange Sie sich an die Lizenzbedingungen halten.
Unter folgenden Bedingungen:
Namensnennung — Sie müssen angemessene Urheber- und Rechteangaben machen, einen Link zur Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden. Diese Angaben dürfen in jeder angemessenen Art und Weise gemacht werden, allerdings nicht so, dass der Eindruck entsteht, der Lizenzgeber unterstütze gerade Sie oder Ihre Nutzung besonders.
Keine Bearbeitungen — Wenn Sie das Material remixen, verändern oder darauf anderweitig direkt aufbauen, dürfen Sie die bearbeitete Fassung des Materials nicht verbreiten.
