Continuous Delivery – Software-Entwicklung in der Pipeline
IONOS Redaktion
Continuous Delivery (deutsch: „fortwährende Lieferung“) ist ein innovatives Konzept der Software-Entwicklung, das sich immer größerer Beliebtheit erfreut. Bei Continuous Delivery sind die Produktionsschritte Entwicklung, Qualitätssicherung und Auslieferung nicht endgültig, sondern wiederholen sich im Entwicklungsprozess immer wieder automatisch in einer Schleife, mittels der sogenannten Continuous Delivery Pipeline. Das hat den Vorteil, dass Sie Software-Produkte stückweise und in kurzen Intervallen einer Qualitätsprüfung unterziehen und schon ausliefern können, während Sie an dem Produkt noch weiterarbeiten. Dabei erhalten Sie in der Pipeline konstant Feedback, womit Sie die Software nach jeder Änderung am Quellcode sofort gezielt verbessern können.
Continuous Delivery ist ein Modell, das in der Software-Entwicklung eingesetzt wird, um Entwicklung, Auslieferung, Feedback und Qualitätsmanagement in kurzen Intervallen in einer Dauerschleife parallel laufen zu lassen. Dadurch gewinnt die Entwicklung an Effizienz und der Kunde bekommt das Produkt früher, auch wenn dieses noch nicht fertig ist. Continuous Delivery versorgt den Entwickler mit Feedback durch automatisierte Tests, die meist nach jeder Änderung am Quellcode den Build prüfen.
Continuous Delivery beschreibt also einen wechselseitigen Prozess, der Entwicklung, Auslieferung, Feedback und Qualitätsmanagement miteinander vereint und automatisiert. So minimieren Sie langwierige und aufwendige Arbeitsschritte.
Die Vorteile von Continuous Delivery
In der klassischen Software-Entwicklung wird das Endprodukt erst ausgeliefert, wenn es alle anvisierten Features enthält, problemlos läuft und in der Qualitätsüberprüfung keine gravierenden Mängel aufweist. Anschließend versorgt der Entwickler die Software meist mit Patches und Updates in mehr oder weniger regelmäßigen Abständen. Bei Continuous Delivery wird das Produkt in einem viel früheren Entwicklungsstadium an den Kunden geliefert, noch während weiter daran gearbeitet wird. Die Vorabversion enthält oft nur die Kernfunktionen der Software, die dann vom Kunden in realer Umgebung getestet werden. Der Kunde (resp. der Software-Tester) selbst nimmt also einen wesentlichen Platz in der Qualitätssicherung ein.
Das so gewonnene Feedback hilft dem Entwickler, noch während der Entwicklung die vorhandenen Features zu verbessern. Er bekommt womöglich auch wertvolle Hinweise darauf, welches Feature als nächstes entwickelt werden sollte. Ohne Continuous Delivery ist dieser Prozess durchaus mühsam und kann zu Unmut auf beiden Seiten führen: Der Kunde erwartet in aller Regel ein fertiges Produkt, das seinen Anforderungen und Wünschen genügt; der Entwickler weiß aber bis dahin noch gar nicht, welche das genau sind. Setzt die Kommunikation über den Entwicklungsstand des Produkts bereits zu einem früheren Zeitpunkt ein, können Kundenwünsche leichter berücksichtigt und Fehler vermieden werden. Das Prinzip lässt sich als Kreislauf veranschaulichen:
Die drei Bereiche Entwicklung, Qualitätssicherung und Produktion lösen sich also nicht in einem einmaligen Prozess gegenseitig ab, sondern greifen fortlaufend ineinander. So durchläuft das Produkt die einzelnen Phasen immer wieder und wird dabei kontinuierlich verbessert. Bei einer großen Anzahl von Kunden ist dies nicht zu leisten ohne eine Automatisierung. Hier setzt Continuous Delivery an, indem es den gesamten Prozess automatisiert.
Jede Bearbeitung und Erweiterung der Software (also jede Änderung am Quellcode) können Sie dank Continuous Delivery in Echtzeit testen lassen, um Feedback zu sammeln. Unerwünschte Nebeneffekte werden dadurch schnell sichtbar, sodass Sie in noch frühen Entwicklungsstadien eingreifen können. Das ist besonders praktisch, da Sie z. B. leichter feststellen, welche Stelle im Code einen Bug verursacht. Ohne Continuous Delivery ist die Problemsuche oftmals sehr mühsam.
Auf dem Weg zum Kunden befindet sich die Software demnach in einem Zwischenstadium, der Continuous Delivery Pipeline. In ihr werden sowohl manuelle als auch automatisierte Tests durchgeführt. Jede Testphase zieht eine neue Software-Version nach sich (meist als „Beta-Version“ bezeichnet, manchmal auch als „Nightly Build“, also eine automatisiert ‚über Nacht‘ erstellte Version), die wiederum in die Pipeline gelangt. Erst wenn alle Tests erfolgreich verlaufen und ein zufriedenstellendes Feedback nach sich ziehen, wird eine ‚stabile‘ Version („Stable“) erstellt und das Produkt offiziell veröffentlicht (diesen Vorgang wie auch die publizierte Anwendung selbst nennt man „Release“). Die Wahrscheinlichkeit, dass der Kunde dann ein fehlerfreies Produkt erhält, ist ungleich höher.
Dies ist der größte Vorteil von Continuous Delivery: Der automatisierte Prozess begünstigt sowohl den Kunden als auch den Entwickler. Für den Kunden ist das Produkt schneller verfügbar und in der Regel freier von Fehlern. Für Entwickler sind die ‚Feldtests‘ weitaus effektiver als das betriebsinterne Beta-Testing, weil sie wertvollere Daten und Hinweise liefern. Der gesamte Entwicklungsprozess wird sehr viel flexibler und das Risiko, eine fehlerbehaftete Software zu veröffentlichen, minimiert sich.
Übersicht: Die Vorteile und Nachteile von Continuous Delivery
| Vorteile | Nachteile | |
|---|---|---|
| Software-Fehler lassen sich schon im Entwicklungsprozess viel effizienter finden und beseitigen. | Kostenfaktor: Ein starker und verlässlicher Integrationsserver für die automatisierten Tests ist notwendig für eine gute und sichere Auslieferung des Produkts. | |
| Der Aufwand eines klassischen Software-Release entfällt größtenteils. Die Entwickler können sich vollständig auf das tatsächliche Entwickeln konzentrieren. | Die automatisierten Tests müssen geschrieben werden und perfekt funktionieren. Fehlerhafte Tests können großen Schaden bei der Qualitätsprüfung verursachen. | |
| Die Continuous Delivery Pipeline erleichtert Entwicklern die Arbeit bei der Fehlersuche enorm. | Erfordert eine gute Abstimmung im Team, weil Codeänderungen häufig und effizient zusammengetragen werden müssen. | |
| Es entstehen weniger Kosten, die durch andere Testprozesse (z.B. Alpha- und Betatests) entstehen würden. | Erfordert eine gute und kontinuierliche Kommunikation mit Kunden und deren Zielsystemen. | |
| Die Qualitätssicherung kann mehr Ressourcen auf die konzeptuelle als auf die technische Verbesserung der Software aufwenden. | Der Kunde erwartet kontinuierliche Updates und Verbesserungen. Das Software-Projekt kann nur selten „pausiert“ werden. | |
| Die Software-Entwicklung geht grundsätzlich schneller voran, weil die Entwickler durch den größtenteils automatisierten Release-Prozess entlastet werden und weniger Pausen einlegen müssen. | Die Auslieferung von Neuerungen, Verbesserungen und Änderungen am Produkt erfolgt immer noch manuell. Um diesen Prozess zu automatisieren, muss zu Continuous Deployment übergegangen werden. | |
| Schnellere und häufigere Releases beschleunigen die Schleife aus Feedback und Verbesserung. | Der Kunde muss Bereitschaft zeigen, eine Software zu benutzen, die sich noch in der Entwicklung befindet. Er muss außerdem motiviert sein, wichtiges Feedback zu liefern. | |
| Es entsteht für die Entwickler weniger Druck bei jeder Änderung im Quellcode, weil Fehler entsprechend schnell gefunden werden. Das führt zu motivierender und inspirierter Arbeit. |
Die Phasen der Continuous Delivery Pipeline
Bei einer Änderung im Code wird die Continuous Delivery Pipeline getriggert und der Testprozess ausgeführt. Dies sind die Phasen, die die Continuous Delivery Pipeline dabei durchläuft:
- Commit Stage: In dieser ersten Testphase wird die Software-Version geprüft, die Software-Komponenten werden gebaut bzw. kompiliert und notwendige Unit-Tests durchgeführt. Nach erfolgreichem Testing ist die Phase abgeschlossen. Binärartefakte der Software-Komponenten werden im Bundle zusammengefasst und im Repository abgelegt. Dieses Paket ist anschließend maßgeblich für die Funktionalität der Pipeline, weil es den Software-Stand bestimmt. Darüber hinaus umfasst das Paket schließlich die Datenmenge, die später auf dem Zielsystem installiert wird. Die Testergebnisse in der Commit Stage lassen sich so den konkreten Änderungen im Quellcode zuordnen, was einen wesentlichen Vorteil von Continuous Delivery ausmacht.
- Acceptance Test Stage: In der zweiten Testphase erfolgen die Akzeptanztests. Dazu gehören neben Integrationstests (funktioniert das Zusammenspiel der Komponenten?) die notwendigen Systemtests (funktioniert die Software auf Benutzerseite?). Außerdem gibt es einige optionale Tests, die in die Acceptance Test Stage integriert werden, etwa Performance-Tests und andere Tests, die die nichtfunktionalen Anforderungen der Software prüfen. Für die Acceptance Test Stage wird das in der vorherigen Phase erstellte Bundle weiterverwendet und in einer passenden Testumgebung installiert.
- Eventuelle Fehler oder Komplikationen in diesen Phasen werden dokumentiert und, wenn nötig, als Feedback an den Entwickler geschickt. Das kann über E-Mail, Messaging-Programme oder spezielle Tools (s. u.) geschehen. Weil die Pipeline bei jeder Codeänderung ausgelöst wird, beziehen sich Fehlermeldungen bzw. Regressionen hier immer auf die letzte Änderung. So kann der Entwickler schnell und effizient reagieren und eventuelle Fehler beheben oder fehlerhaften Code nachbessern.
- Je nach Bedarf werden nun manuelle Tests durchgeführt. Auch für diese Tests bedient sich die Pipeline des Bundles aus der ersten Phase und installiert dieses in einer geeigneten Testumgebung.
- Werden alle Tests mit positivem Feedback abgeschlossen, kann das Paket auf dem Zielsystem manuell installiert werden. Dafür ist meist nur ein ‚Knopfdruck‘ notwendig. Ist dieser Schritt auch automatisiert, spricht man von Continuous Deployment.
Sie möchten Ihre Entwicklungsprozesse schlanker gestalten? Mit Deploy Now können Sie statische Websites ohne Umwege von GitHub auf IONOS georedundante, DDoS-geschützte Infrastruktur deployen. Legen Sie bequem Staging Deployments an um Änderungen vor dem Ausrollen live zu überprüfen und profitieren Sie von einer automatischen SSL-Provisionierung.
Continuous Integration vs. Continuous Delivery
In einem Atemzug zu Continuous Delivery wird oft der Begriff Continuous Integration genannt. Allerdings gibt es einen wesentlichen Unterschied, der im Umfang liegt: Während Continuous Integration die Automatisierung des Testprozesses meint und den größten Teil der Pipeline mit Continuous Delivery teilt, erweitert Continuous Delivery das Konzept und sieht auch den Release-Prozess der Software als automatisierten Vorgang vor. Somit ergänzt Continuous Delivery das Modell der Continuous Integration um den Endbenutzer, indem es gleichzeitig zum Testen schon das Produkt liefert.
Ob ein Entwickler lediglich Continuous Integration anwendet oder den Entwicklungsprozess auf Continuous Delivery erweitert, hängt von der Entwicklungsplanung, dem Entwicklungsteam und der Kundenbasis ab. Im Folgenden stellen wir beide Konzepte gegenüber:
| Continuous Integration (CI) | Continuous Delivery (CD) | |
|---|---|---|
| Automatisierter Testprozess, der jede Änderung im Quellcode einer kritischen Prüfung unterzieht | Erweitert den Testprozess um den Auslieferungsprozess. Neuerungen und Änderungen am Code landen automatisiert beim Endbenutzer. | |
| Das Team muss für jedes neue Feature, jede Verbesserung und jede Code-Änderung automatisierte Tests schreiben. | Die Effektivität dieser Tests ist bei CD umso wichtiger, weil die Ergebnisse unmittelbarer beim Endnutzer landen. | |
| Verlangt einen dedizierten und kontinuierlichen Integrationsserver, der die automatischen Tests überwacht und anwendet | Auch die Installation auf dem Zielsystem muss möglichst automatisiert erfolgen, was höhere Anforderungen an den Server stellt. | |
| Entwickler müssen ihre Code-Änderungen kontinuierlich und oft zusammenführen. | Entwickler müssen darüber hinaus einen guten Kundenkontakt pflegen und bezüglich der Software möglichst transparent sein. | |
| Erfordert einen relativ hohen Ressourcenaufwand, um die Produktqualität bei Auslieferung zu sichern | Dieser Aufwand wird bei CD umso höher. Dafür kann das Produkt viel früher geliefert und ‚echten‘ Tests unterzogen werden. | |
| Die Entwicklung an sich ist effizienter, wird aber durch manuelle Releases häufiger pausiert. | Es kann durchgehend entwickelt werden, weil auch der Release-Prozess größtenteils automatisiert ist. |
Bekannte Tools für Continuous Delivery
Verschiedene Programme erleichtern Ihnen den Umstieg auf Continuous Delivery. Wir stellen vier davon vor.
Jenkins
Jenkins ist eine Webanwendung, die die kontinuierliche Integration von Komponenten für Software ermöglicht. Das Java-basierte Jenkins läuft dabei in beliebigen EJB-Containern und enthält neben unterschiedlichen Build-Tools (Apache Ant, Maven/Gradle, CVS, Subversion, Git u. a.) auch die für Continuous Delivery wichtigen automatischen Testverfahren (JUnit, Emma). Optionale Plug-ins sichern die Kompatibilität zu anderen Compilern. Die REST-basierte Programmierschnittstelle erlaubt darüber hinaus, dass andere Programme auf Jenkins zugreifen können. Jenkins ist ein kostenloses Open-Source-Programm. Es wird vor allem für Anfänger empfohlen, weil Interface und Funktionalität sehr einsteigerfreundlich gestaltet sind.
CircleCI
CircleCI ist eine ebenfalls webbasierte Anwendung für Continuous Integration, Delivery und Deployment. Dabei arbeitet CircleCI bevorzugt mit GitHub, GitHub Enterprise und Bitbucket. Außerdem bietet die Plattform viele praktische Features wie Auftragsmanagement, Ressourcenmanagement, Docker Support, Unterstützung aller bekannten Programmiersprachen, sicheres Caching, Datenanalyse mit Statistiken und umfassende Sicherheitskonzepte. CircleCI erhielt 2017 von Forrester die Auszeichnung „Leader in Continuous Integration“. Der erste Container ist kostenlos, ab dem zweiten fallen 50 US-Dollar pro Container und Monat an.
Microsoft Team Foundation Server
Microsoft Team Foundation Server (TFS) ist ein Kollaborationstool für Software-Projekte, die gemeinsam geplant, erstellt und anschließend verwaltet werden sollen. TFS ist der inoffizielle Nachfolger von Microsofts Visual SourceSafe. Für das gemeinsame Arbeiten an einem Software-Projekt unterstützt TFS verschiedene Entwicklungsverfahren, darunter CMMI, agile Software-Entwicklung und Scrum. Für die Arbeit werden in TFS die bekannten Office-Programme wie Word und Excel verknüpft und integriert, sodass Sie von TFS nicht auf ein anderes Programm wechseln müssen.
Für Continuous Integration, Delivery und Deployment stehen verschiedene Features zur Verfügung, mit denen Sie eine Pipeline bauen. Grundsätzlich trennt TFS den gesamten Prozess in die Abschnitte Versionskontrolle, Build, Reports und Benutzerverwaltung.
Teams mit maximal 5 Personen benutzen die kostenlose Express-Version, alle größeren Teams die kommerzielle Version, die etwa 6 US-Dollar pro Nutzer und Monat kostet. Dazu müssen Sie aber in der Regel auch eine Server-Lizenz erwerben. Sie können TFS auch ohne Monatsabonnement erwerben; dafür müssen Sie allerdings einen lokalen Händler kontaktieren. Der Preis scheint zwischen 500 und 700 Euro zu schwanken.
Codeship
Codeship ist eine SaaS-Plattform für Continuous Integration (und Delivery), die sich in ihrem Umfang an die Bedürfnisse des Nutzers anpasst. Codeship unterstützt GitHub und Bitbucket sowie GitLab. Die verfügbaren Features richten sich dabei nach dem jeweiligen Bezahlplan: In der kostenlosen Version liefert Codeship eine voreingestellte CI-Umgebung und kümmert sich auch um den Workflow, der bei CI/CD anfällt. Darüber hinaus erlaubt die kostenlose Variante effizientes Caching und paralleles Testen von Builds in geteilten und vorkonfigurierten Containern. Der kostenlose Plan erlaubt 100 Builds pro Monat bei einem durchgängigen Build sowie eine Test-Pipeline. Hervorzuheben ist eine fehlende Obergrenze für Projekte, Nutzer und Teams.
Um mehr aus Codeship herauszuholen, können Sie „Codeship Basic“ erwerben, das ab ca. 45 Euro/Monat erhältlich ist und abhängig von der Teamgröße teurer wird. Die ebenfalls kostenpflichtige Version „Codeship Pro“ erweitert die Feature-Liste um einen Docker-Support, die „komplette Kontrolle“ über die Build-Umgebung, lokale Builds und eine bessere Kontrolle über den Workflow. Außerdem werden mehrere Tools zugänglich, die Continuous Integration/Delivery noch effizienter und transparenter machen. Codeship Pro kostet je nach Anzahl der parallelen Builds pro Monat ca. 70 Euro.
- Inklusive Wildcard-SSL-Zertifikat
- Inklusive Domain Lock
- Inklusive 2 GB E-Mail-Postfach
