© DrHitch/Shutterstock.com
Agilität und Continuous Delivery

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.

Abb.1_1.png

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 informiert.

Obwohl sich dieser prinzipielle Ablauf seit der Veröffentlichung von Fowlers Artikel nicht verändert hat, gab es durchaus nennenswerte Weiterentwicklungen in den letzten zehn Jahren. So wurden zum Beispiel zwischenzeitlich mehrere CI-Patterns und Anti-Patterns [4] beschrieben, welche sich mit so genannten Problemen der zweiten Generation befassen, etwa der Reduzierung von Testlaufzeiten bei großen Projekten. Darüber hinaus hat man heute die Wahl zwischen diversen CI-Servern verschiedener Hersteller mit unterschiedlichen Features.

Denkt denn niemand an die Kunden?

Der Schwerpunkt von CI liegt also ganz eindeutig auf Seiten der Entwickler. Diese sind zufrieden, wenn der CI-Server klar signalisiert, dass der letzte Commit in das VCS erfolgreich war. Themen wie Bereitstellung zum Benutzertest oder Produktivsetzung der Software sind dabei in erster Näherung nicht von Bedeutung.

Dem Anwender der Software andererseits ist es in der Regel gleichgültig, ob der aktuelle CI Build gut war. Ihn interessiert die Verfügbarkeit neuer Funktionalität auf seinem Produktivsystem, sodass diese auch tatsächlich zum Einsatz kommen kann.

Dieser Anwenderwunsch hinsichtlich Verfügbarkeit, den es seitens der Entwickler zu erfüllen gilt, findet sich auch im ersten Prinzip des Agilen Manifests wieder, das etwa zur gleichen Zeit wie Fowlers CI-Artikel entstanden ist [5]: „Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

Zwischen einem erfolgreichen CI Build und der Verfügbarkeit für den Kunden liegt leider das Release, das in der Praxis oft nicht so gut beherrscht wird wie die CI-Infrastruktur. Dies zeigt sich dadurch, dass beim Durchführen eines Releases üblicherweise mehrere Personen beteiligt sind, die viele Aufgaben von Hand erledigen müssen, was wiederum hohe Fehlerraten nach sich zieht.

Organisatorisch ist häufig eine Vermeidungsreaktion die Folge, das bedeutet seltene Releases mit jeweils vielen Änderungen und Neuerungen, die gerne auch als Big-Bang-Releases bezeichnet werden. Aus Sicht des Anwenders ist dies natürlich ärgerlich, da er hierbei auf einzelne Features generell lange zu warten hat. Darüber hinaus lösen Big-Bang-Releases noch nicht einmal das eigentliche Problem, da in der Praxis auch weiterhin nicht geplante Releases notwendig sind, etwa beim Einspielen von kritischen Hotfixes.

Die Idee, neue Features und Bugfixes, auch wenn diese klein sein sollten, zeitnah und ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang