Agiliät und Continuous Delivery

Von Steffen Schluff, Axel Fontaine und René Lengwinat

Build Management zusammen mit den etablierten Konzepten rund um Continuous Integration wurde unlängst um neue Ideen ergänzt, die unter dem
Namen Continuous Delivery zusammengefasst werden. Continuous Delivery beginnt dort, wo Continuous Integration endet. Das erste Kapitel erläutert zunächst die Parallelen in
der Entstehung von CI und CD und beschreibt, inwieweit CD als mögliche Weiterführung von CI gesehen werden kann. Im zweiten Kapitel folgt die Betrachtung
von Techniken, die es ermöglichen, eine Softwarearchitektur so aufzubauen, dass sie das Versprechen von CD Realität werden lässt. Das dritte Kapitel
beschäftigt sich letztlich mit CD in der Praxis und beleuchtet die Vor- und Nachteile der auf Continuous Delivery beruhenden architektonischen Entscheidungen.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 11. Nov. 2013
• ISBN: 9783868024906

Buchvorschau

Steffen Schluff, Axel Fontaine,

René Lengwinat, Michael Fait, Marc Hofer

Agilität und Continuous Delivery

ISBN: 978-3-86802-490-6

© 2013 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Continuous Delivery

Entstehung, aktueller Stand und Ausblick

Das Thema Build Management zusammen mit den etablierten Konzepten rund um Continuous Integration wurde unlängst um neue Ideen ergänzt, die unter dem Namen Continuous Delivery zusammengefasst werden.

Continuous Delivery (CD) wird dabei häufig als Weiterentwicklung von Continuous Integration (CI) bezeichnet, wobei insbesondere die Idee einer Deployment Pipeline dabei helfen soll, den entscheidenden Schritt von CI zu CD zu machen.

Das folgende Kapitel erläutert die Parallelen in der Entstehung von CI und CD, beschreibt, inwieweit CD als mögliche Weiterführung von CI gesehen werden kann und zeigt abschließend, welche Tools zurzeit verfügbar sind, um diese neuen Ideen umsetzbar zu machen.

Ausgangspunkt Continuous Integration

Eines der ältesten Probleme in der Softwareentwicklung ist die Tatsache, dass bei der Zusammenarbeit mehrerer Entwickler unvermeidbar so genannte Integrationsfehler entstehen. Je später diese Fehler entdeckt werden, umso aufwendiger und damit teurer ist deren Beseitigung. Obwohl über dieses Thema schon zuvor ausführlich publiziert worden war [1], ist es hauptsächlich Martin Fowlers Onlineartikel „Continuous Integration" [2] aus dem Jahre 2000, der den bis dato gültigen De-facto-Standard in diesem Bereich darstellt.

Es waren vor allem die folgenden drei Faktoren, die rückblickend für den nachhaltigen Erfolg von Fowlers Ansatz verantwortlich sind:

Continuous Integration ist ein sehr eingängiger Begriff, der nicht nur den technischen Sachverhalt gut zusammenfasst sondern auch als „Buzzword" taugt. Letzteres ist vor allem dann bedeutsam, wenn um Mittel und Ressourcen geworben wird.

Fowler benennt detailliert konkrete „Key Practices", die als Orientierungshilfe beim Einsatz von CI dienen, wie zum Beispiel „Automate the Build oder „Make Your Build Self-Testing. Somit existiert eine Referenz anhand derer man zeigen kann, dass man tatsächlich CI verwendet und sich nicht nur mit einem Modewort schmückt.

Begleitend zu dem Artikel waren einsetzbare Tools erhältlich, sodass die dargestellten Konzepte auch sofort in der Praxis angewendet werden konnten. Genauer gesagt hatte die Firma ThoughtWorks zu dem damaligen Zeitpunkt den Quellcode von CruiseControl [3], einem frei verfügbaren Open-Source-CI-Server, bereitgestellt.

Abbildung 1.1 zeigt den schematischen Aufbau eines typischen CI-Systems, bestehend aus dem Server selbst sowie weiteren Bestandteilen.

Abbildung 1.1: Schematischer Aufbau eines CI-Systems

Der abgebildete Kreislauf startet, wenn das Entwicklerteam Änderungen an einem Projekt durchführt und diese an das Version Control System (VCS) übergibt. Der CI-Server, der in bestimmten Zeitabständen das VCS prüft, stößt im Falle einer Änderung einen so genannten CI Build an. Hierbei wird mittels eines Build-Tools wie Maven oder Ant der aktuelle Projektstand kompiliert und üblicherweise auch automatisiert getestet. Abschließend wird der Build durch den CI-Server als erfolgreich oder fehlgeschlagen klassifiziert und das Entwicklerteam entsprechend