Definition „Continuous-Integration- und -Delivery-Pipeline“ Was ist eine CI/CD-Pipeline?

Von Gedeon Rauch

Mit der CI/CD-Pipeline lässt sich die Software-Entwicklung und -Bereitstellung vom frühen Build bis zum Deployment über automatisierte Prozesse optimieren. Alle Elemente und Entwicklungsobjekte müssen die Pipeline durchlaufen.

Anbieter zum Thema

Die CI/CD-Pipeline soll dafür sorgen, dass Code-Änderungen und Neuerungen möglichst schnell beim User ankommen.
Die CI/CD-Pipeline soll dafür sorgen, dass Code-Änderungen und Neuerungen möglichst schnell beim User ankommen.
(Bild: CAN Europe - flickr.com / CC0 )

Von einer Softwareversion zur nächsten – dieser Schritt kann für Teams extrem aufwendig sein und viele der Probleme lassen sich in agilen Workflows besser bewältigen. Einer dieser Workflows ist die sogenannte CI/CD-Pipeline, die qualitativ hochwertige Software von der Entwicklung bis zur Auslieferung begleitet.

Wie das in der Praxis funktioniert, ist am verständlichsten, indem man die Schritte einzeln betrachtet.

Was beinhaltet das Framework der CI/CD-Pipeline?

  • Continuous Integration

Continuous Integration, kurz CI, verfolgt den Ansatz, eine stabile Code-Basis durch neuen Code zu ergänzen. Anstatt also neuen Code zunächst zu vollenden und abschließend zu integrieren, wird der neue Code kontinuierlich in die Basis eingefügt. Hierbei wird automatisiert getestet und Probleme können früher identifiziert und behoben werden, so dass Probleme nicht erst in der Nähe von Release-Versionen bemerkt werden.

  • Continuous Delivery

Continuous Delivery oder CD beschreibt einen Prozess, der durch die schnelleren Update-Zyklen moderner Apps tief im Alltag von Usern integriert ist. Continuous Delivery versteht sich als Prozess, bei dem jede Veränderung release-fähig ist. Dies bedeutet auf der einen Seite stabil, auf der anderen Seite aber auch dokumentiert.

Hierbei können auch inkrementelle Änderungen im Code veröffentlicht werden und laufen stabil. Dies kann nur durch eine konsistente Pipeline erfolgen, in der Code Test- und Produktionszyklen durchläuft.

Auch wenn Continuous Integration und Continuous Delivery für die CI/CD-Pipeline namensgebend sind, basiert das Framework zusätzlich auf anderen Bestandteilen:

  • Continuous Testing

Im Software Development Life Cycle schließt ein kontinuierlicher Testzyklus die Lücke zwischen schneller Entwicklung und verlässlicher User Experience für die Anwenderinnen und Anwender.

Das manuelle Sammeln und Verarbeiten von Feedback ist nicht effizient und schnell genug, um lückenlos eine hohe Qualität zu gewährleisten. Stattdessen arbeiten im Continuous Testing automatisierte Skripts an der Quality Assurance, indem sie den Entwicklungsprozess kontinuierlich begleiten. So können Teams schneller auf Fehler und Lücken hingewiesen werden, was die Entwicklung beschleunigt.

Schnelle Simulationen können langwierige Tests mit Usern hierbei in vielen Fällen ersetzen.

  • Continuous Deployment

Der letzte Schritt in der CI/CD-Pipeline ist Continuous Deployment, also die kontinuierliche Auslieferung von neuen Softwareversionen an die Endanwender. Auch wenn dies in der Praxis nicht zwingend erforderlich ist, ist Continuous Deployment doch heute in den Alltag vieler User integriert und durch automatische Update via App Stores problemlos möglich.

Continuous Deployment erfordert dabei eine Reihe von automatischen Tests, die eine stabile Software garantieren. Der größte Vorteil liegt darin, Benutzerinnen und Benutzern auch inkrementelle Updates jederzeit anbieten zu können - das bedeutet, dass der gesteigerte Wert eines Updates sofort bei den Endusern ankommt.

Unterschiede zwischen Continuous Delivery und Continuous Deployment

Im letzten Schritt der CI/CD-Pipeline ist es wichtig, den Unterschied zwischen Delivery und Deployment zu verstehen, zumal die Abkürzung CD hier verständlicherweise für Mehrdeutigkeit sorgen kann.

Nur im Continuous Deployment durchläuft der neue Code einen automatisierten Testprozess, der mit einem automatisierten Release endet. Deployment beendet die CI/CD-Pipeline also auf den Endgeräten und geht damit einen Schritt weiter als Continuous Delivery. Für das Beschreiben einer vollständigen CI/CD-Pipeline ist Deployment allerdings kein zwingendes Erfordernis.

Continuous Delivery hingegen bedeutet lediglich, dass neuer Code in eine Produktionsumgebung übertragen wird, in der weitere Testschritte erfolgen und eine menschliche Quality Assurance stattfindet. Um den Code und die neue Softwareversion tatsächlich auszuliefern, braucht es menschliches Einschreiten.

In der Praxis haben beide Formen des Abschlusses einer CI/CD-Pipeline ihre Berechtigung, abhängig von den Bedürfnissen der entwickelnden Teams und Unternehmen. Agile DevOps Teams etwa veröffentlichen Software in der Regel in kürzeren Zyklen, andere Teams sind nicht auf häufige Updates angewiesen (etwa bei B2B-Software).

Die Phasen der CI/CD-Pipeline im Überblick

Build: Der Code wird geschrieben und kompiliert, Teams können auch interagieren und sich basierend auf einem gemeinsamen Quellcode abstimmen.

Test: In der Testphase durchläuft der Code automatisierte Tests.

Delivery: Nach dem Passieren der Testphase wird der Code in eine Produktionsumgebung geschickt.

Deployment: Die Auslieferung des Codes kann entweder automatisiert erfolgen oder sie wird durch nach der Genehmigung des Teams freigegeben.

So profitiert die Entwicklung von mehr Automation

Besonders in der agilen Softwareentwicklung brauchen Teams eine schnelle und wirtschaftliche Herangehensweise, um die Softwarebereitstellung zu optimieren. Die CI/CD-Pipeline kann durch die kürzeren Zyklen zwischen dem Schreiben von Code und dem Deployment einen wichtigen Beschleuniger darstellen.

Zudem ist das kontinuierliche automatische Testen besonders für kleinere Teams essentiell, um bereits im Testprozess nachbessern zu können, ohne auf menschliches Feedback warten zu müssen. Fehler können so früher erkannt und besser behandelt werden.

Die Automatisierung ersetzt dabei natürlich nicht die menschliche Komponente, doch sie erlaubt es auch kleineren Teams durch den Hebel der Automation Software zu entwickeln, die sonst eine wesentlich aufwendigere (und teurere) Produktion erfordern würde.

(ID:45106809)