Ihr Fahrplan für Releases am laufenden Band

On the Road to Continuous Delivery

Thorsten Kamann und Hanno Wendt
Auf geht’s!

Wir werfen einen genaueren Blick auf die Roadmap und wenden uns innerhalb der einzelnen Stages den Clustern und Jobs zu, die in Abbildung 2 zu sehen sind. Nach und nach arbeiten wir uns gemeinsam in der strategisch sinnvollen Reihenfolge durch die anstehenden Aufgaben.

Abb. 2: Detaillierte Roadmap
Development – Continuous Build

Ist es möglich, das Projekt vollständig und automatisiert zu bauen? Wenn nicht, sollte als erstes ein geeignetes Build-Tool gefunden werden, mit dem Sie Ihr Projekt mit einem einzigen Aufruf auf der Kommandozeile bauen und paketieren können. Schon jetzt sollten Sie mögliche Abhängigkeiten zu benötigten Bibliotheken im Auge behalten. Ihr Build-Tool sollte in der Lage sein, diese einzubinden und zu verwalten.

Als Nächstes sollte dafür gesorgt werden, dass das Projekt auch unabhängig von den Rechnern der Entwickler auf einer zentralen Instanz, dem Build-Server, gebaut werden kann. Verfügen Sie über ein Versionskontrollsystem für Ihren Quellcode? Wenn nicht, sollten Sie diesen Schritt dringend nachholen. Setzen Sie nun einen Build-Server auf und legen Sie eine Projektkonfiguration an, sodass er auf Änderungen in der Versionierung mit der Ausführung des Build-Skripts reagiert. Wenn Sie einen Build-Server als Instanz verwenden, spart Ihnen dies viel Zeit gegenüber einer eigenen Lösung, da sich der Build eines Projekts damit innerhalb von Minuten konfigurieren lässt.

Lassen Sie in der Projektkonfiguration den Build-Server regelmäßig überprüfen, ob Änderungen vorliegen. Es empfiehlt sich, ein kurzes Intervall einzurichten, denn das Ziel des automatisierten Builds ist es, Änderungen so früh wie möglich und in Einzelschritten zu integrieren. Viele Build-Server sind übrigens kostenlos unter Open-Source-Lizenzen verfügbar. Sie haben nun in der Stage Development das Cluster Continuous Build fertig gestellt und Folgendes erreicht:

  • Ihre Software lässt sich automatisch bauen.
  • Sie haben ein Versionskontrollsystem bereitgestellt.
  • Sie haben einen zentralen Build-Server eingerichtet, der in der Lage ist, Änderungen aus dem Versionskontrollsystem zu registrieren und das Build-Skript auszuführen.
Development – Continuous Unit Tests

Existieren bereits Unit Tests für Ihren bestehenden Code und entwickeln Sie für neuen Code ebenfalls Tests? Sie sollten sich für den Bestandscode, ebenso wie für neue Features, um eine solide Abdeckung mit Unit Tests bemühen, da eine gesunde Testbasis Kontrolle über das Auftreten möglicher Nebeneffekte oder Regressionen gibt. Ergreifen Sie diese Maßnahmen: Jeder Entwickler muss für neuen Code Tests schreiben und diese ausführen. Ebenfalls sollte er vor dem Commit alle Unit Tests des Projekts auf seinem Rechner laufen lassen. Sind diese positiv verlaufen, können der neue Code und die zugehörigen Tests eingecheckt werden.

Integrieren Sie die Durchführung aller Unit Tests in den Software-Build. Auf diese Weise werden die Tests auf den Entwicklungsrechnern und dem Build-Server automatisch ausgeführt. Sie verfügen nun über Regressive Unit Tests.

Für eine bessere Übersicht über die Testergebnisse sollten Sie sich nun Gedanken darüber machen, wie diese sich in einer Übersicht (Report) aggregieren lassen. Viele Build-Tools verfügen über Plug-ins, mit denen sich übersichtliche Reports in HTML/XML erzeugen lassen. Wenn Sie sich auf einen der gängigen Build-Server und gängige Build-Tools eingelassen haben, werden Sie nun belohnt, da diese Ihnen durch die Bank die Möglichkeit bieten, Testreports der Build-Tools automatisiert zu analysieren. Bei Fehlschlägen eines oder mehrerer Tests ist der Build gescheitert, und es wird kein Artefakt ausgeliefert. Damit Sie auch erfahren, ob Ihr Continuous Build gesund ist, richten Sie eine automatische Benachrichtigung ein. Alle Continuous-Integration-Server verfügen über Messaging-Komponenten oder lassen sich durch Plug-ins entsprechend erweitern. Dabei ist dann verschiedenes möglich: Der Erfolgsstatus kann auf einer Website angezeigt, per E-Mail oder Instant Messenger verschickt werden. Der Baustein Notification im Cluster Continuous Unit Test ist vollendet, und damit sind auch die Automatisierungsmaßnahmen in der Stage Development erfolgreich abgeschlossen. Das haben Sie in diesem Cluster erreicht:

  • Sie verfügen über Unit Tests mit guter Abdeckung.
  • Die Tests werden automatisiert mit dem Build ausgeführt.
  • Fehlgeschlagene Tests brechen den Build ab.
  • Reports über den Testerfolg werden erzeugt und Benachrichtigungen bei Fehlschlägen verschickt.
Integration – Continuous Integration Test

Innerhalb der Stage Integration gibt es Integration Tests, die sicherstellen, dass die Methoden und Komponenten nicht nur jeweils für sich, sondern auch in der Interaktion und einem Teil der Infrastruktur (z. B. Datenbanken) funktionieren. Als Voraussetzung für den Integration Test müssen Sie eine dedizierte Umgebung für die Ausführung bereitstellen. Diese muss keine exakte Kopie der späteren Produktionsumgebung, ihr aber möglichst ähnlich sein. Um später darauf automatisiert testen zu können, müssen Sie das Deployment Ihrer Software automatisieren. Die Ähnlichkeit des Integration-Test-Systems mit dem Produktionssystem ist für das Deployment ein großer Vorteil. Haben Sie diesen Ablauf einmal automatisiert, können Sie ihn auf den verschiedenen Ebenen wiederverwenden. Das Deployment sollte also auf allen Ebenen gleich ablaufen. Wenn Sie dann später Software automatisch in Betrieb nehmen, ist auch das Deployment bereits vielfach erprobt, und alle Beteiligten sind mit dem Prozess vertraut. Legen Sie also auf Ihrem Build-Server eine Konfiguration für das automatisierte Deployment und die Testausführung an. Diese soll immer ausgeführt werden, wenn ein Feature soweit fertig gestellt wurde, dass die Ausführung von Integrationstests sinnvoll ist. Im Cluster Continuous Integration Test haben Sie Folgendes umgesetzt:

  • Sie haben Integrationstests für Ihr System entwickelt,
  • Sie haben eine dedizierte Umgebung bereitgestellt.
  • Sie haben das Deployment und Test auf dieser Umgebung im Build-Server automatisiert.
Integration – Artefaktverwaltung

Die Artefaktverwaltung bildet das zweite Cluster in der Stage Integration. Wir möchten alle Build-Artefakte aufbewahren, die es bis hier geschafft haben, da sie sich als Kandidaten für unser Release bewährt haben. Die Artefaktverwaltung soll uns die Möglichkeit bieten, Artefakte automatisch aus dem Build-Server heraus unter einem eindeutigen Bezeichner abzulegen. Aus diesem soll sich ablesen lassen, aus welchem Build-Lauf und aus welcher Version des Codes im Versionskontrollsystem der Build hervorgegangen ist. Dadurch lässt sich später genau sagen, welche Features in dieser Version enthalten sind.

Die Artefaktverwaltung soll es uns außerdem ermöglichen, Releasekandidaten und Releases zu unterscheiden. Ferner soll der Build-Server nicht nur Artefakte im System ablegen können, sondern daraus auch Artefakte für das automatisierte Deployment über den Bezeichner beziehen können. Die verfügbaren, teilweise kostenlosen Artifact-Repository-Server erfüllen diese Anforderungen gut und lassen sich über grafische Oberflächen vernünftig verwalten.

Installieren Sie einen entsprechenden Server und konfigurieren Sie Ihren Build Server so, dass Ergebnisse des Builds, die die vorangegangenen Teststufen bestanden haben, in die Artefaktverwaltung in den Bereich der Releasekandidaten kopiert werden. Die meisten Build-Server unterstützen Sie dabei mit passenden Plug-ins. Richten Sie Ihre Projektkonfiguration im Build-Server so ein, dass erfolgreiche Builds Ihre Artefakte in das Repository kopieren. Ihre Deployment-Skripte sollten Sie so einrichten, dass sie Artefakte immer aus der Artefaktverwaltung beziehen. Diese wird von nun an zur einzigen Quelle für das Deployment. Sie haben nun einen wichtigen Meilenstein erreicht:

  • Alle Änderungen werden kontinuierlich gebaut und getestet.
  • Das Ergebnis kann automatisch auf ein Testsystem installiert werden.
  • Das geprüfte Artefakt wird in die Artefaktverwaltung kopiert, die alle Versionen für Sie aufbewahrt.
  • Aus der Artefaktverwaltung können Kandidaten und Releases per Knopfdruck installiert werden. Prinzipiell sind nun alle Bausteine der Automatisierung für Ihren Delivery-Prozess fertig gestellt.
Staging Qualitätssicherung

Im Staging Quality Assurance (QA) wird ein Releasekandidat für die Prüfungen durch die Qualitätssicherung auf einer Umgebung automatisiert bereit gestellt. Hierfür können dieselben Deployment-Skripte wie zuvor für das Deployment des Integration-Test-Systems genutzt werden. Das passiert nicht automatisch, sondern auf Bestellung per Knopfdruck im Build-Server durch den QA-Mitarbeiter. Dieser bezieht das Artefakt aus dem Repository, ermittelt eine verfügbare QS-Instanz und installiert es dort. Nach erfolgreicher Installation sollten zuerst automatisch einige Smoke Tests durchgeführt werden, die sicherstellen, dass die grundlegenden Funktionen in Ordnung sind. Ist dieser Health Check positiv verlaufen, sollte der Tester über die Messaging-Komponente mitgeteilt bekommen, dass die angeforderte Version zum Test bereit steht und wo er sie findet.

Sobald die QS zufriedenstellend abgeschlossen wurde, kann die getestete Version für die nächste Stage, den Last-Test, durch den Tester freigegeben werden. Im Falle eines Misserfolges scheidet der Releasekandidat aus.

Staging Last-Test

In der Stage für den Last-Test wird eine wichtige nichtfunktionale Anforderung überprüft. Das installierte Artefakt soll nun einer Belastungsprobe unterzogen werden. Dazu bieten sich je nach Art des entwickelten Systems verschiedene Werkzeuge an. Damit dieser Test eine möglichst gute Aussagekraft für den späteren produktiven Einsatz der Software hat, sollte der Last-Test auf identischer Hardware und mit identischer Konfiguration stattfinden.

Auch die Ausführung dieser Skripte lässt sich in den Build-Servern konfigurieren, sodass der Last-Test direkt im Anschluss an das Deployment automatisiert erfolgen kann. Richten Sie also hierfür in der Projektkonfiguration eine Aktion ein, die das Deployment und die Ausführung des Tests auslöst.

Staging-Produktion

Jetzt hat Ihr Kandidat die letzte Hürde genommen. Dem Einsatz als Release steht nun nichts mehr im Wege – nichts, außer Ihnen selbst! Denn Sie entscheiden schließlich anhand der fachlichen Bedürfnisse und Notwendigkeiten, wann eine Version als Release produktiv genutzt werden kann. Damit haben Sie nun das Ziel erreicht. Sie haben anhand der Roadmap über drei Stages einen durchgängigen automischen Delivery-Prozess umgesetzt. Das Deployment auf die Produktion läuft genauso wie das Deployment auf den vorigen Stages ab. Erweitern Sie Ihre Projektkonfiguration um eine entsprechende Aktion.

Dabei sind aber einige wichtige Unterschiede zu beachten: Das Deployment auf Produktion sollte wenigen Personen vorbehalten sein, da eine große Verantwortung damit verbunden ist. Sie sollten dies also in den Projektkonfigurationen entsprechend absichern. Ebenso muss noch eine Strategie für den Wechsel der aktuellen Nutzer zwischen den Versionen ausgewählt werden. Die Möglichkeiten, die sich dazu bieten, werden im zweiten Teil dieses Artikels zu diskutieren sein.

Am Ende des Weges

Mit der Roadmap sind wir jetzt am Ende des Weges angelangt. Hoffentlich konnten wir Ihnen damit einen Ansatz bieten, um Ihren Delivery-Prozess zu verbessern. Auf Ihrem eigenen Weg der Automatisierung – möglicherweise hin zu Continuous Delivery – werden Sie sicherlich noch eine ganze Weile unterwegs sein. Denn Continuous Delivery bedeutet auch, dass Sie versuchen sollten, Ihren Delivery-Prozess stetig weiter zu verbessern. Überprüfen Sie also immer wieder einmal, ob der Prozess noch zu Ihren Projekten passt und ob noch Potenzial besteht, ihn weniger fehleranfällig, schneller und transparenter zu machen. Stellen Sie sich auch die Frage, ob die eingesetzten Werkzeuge ihre Aufgaben gut erfüllen oder sich die Rahmenbedingungen verändert haben. Dieses Thema schließt an eine grundlegende, wichtige Fragestellung an, die wir im zweiten Teil dieses Artikels behandeln wollen: die Frage nach der gelungenen Werkzeugauswahl. Dabei kommt es darauf an, dass sich damit genau die Build- und Deployment-Pipeline realisieren lässt, die Sie für Ihr Projekt brauchen. Sie müssen zu den Fähigkeiten des Delivery-Teams passen, sodass das Team sie gut einsetzen kann. Im nächsten Teil werden wir klären, welche die wichtigsten Fragen bei dieser Entscheidung sind. Ebenso zeigen wir Ihnen auch, welche konkreten Produkte zur Auswahl stehen und unserer Erfahrung nach empfehlenswert sind.

Thorsten Kamann leitet bei der itemis AG die Working Group „Better Software“, die die Themen Softwarequalität, agile Softwareentwicklung und Continuous Delivery abdeckt. Er ist zertifizierter Product Owner und Scrum Master. Er veröffentlicht in anerkannten Fachmagazinen und hält Vorträge auf Fachkonferenzen. Sie können ihn unter @thorque erreichen.

Hanno Wendt arbeitet als Berater und Entwickler bei der itemis AG in Bonn und hat sich auf Werkzeugketten rund um den Build- und Integrationsprozess spezialisiert. In seinen Projekten wendet er regelmäßig die aktuellen Best Practices von Continuous Delivery an.

Geschrieben von
Thorsten Kamann und Hanno Wendt
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.