LeseprobenContinuous Delivery

Kapitel 1-2

Continuous Delivery

Eberhard Wolff beschäftigt sich seit vielen Jahren mit Softwareentwicklung und -architek-tur. Er ist Autor zahlreicher Fachartikel sowie Bücher und regelmäßiger Sprecher auf interna-tionalen Konferenzen. Außerdem ist er im Programmkomitee verschiedener Konferenzen vertreten. Er arbeitet als selbstständiger Berater und Trainer. Daneben ist er der Leiter des Technologiebeirats der adesso AG, einem großen IT-Dienstleister.

Continuous Delivery und die Auswirkungen hat er in verschiedenen Projekten in unter-schiedlichen Rollen kennengelernt. Der Ansatz verspricht, die Produktivität der IT-Projekte erheblich zu erhöhen, und hat Auswirkungen auf das Vorgehen, aber auch die Architektur und die Technologien. Daher lag es für ihn auf der Hand, dieses Buch zu schreiben.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Eberhard Wolff

Continuous �Delivery

Der pragmatische Einstieg

Eberhard Wolff�eberhard.wolff@gmail.com

Lektorat: René Schönfeldt�Copy-Editing: Petra Kienle, Fürstenfeldbruck�Herstellung: Frank Heidt�Umschlaggestaltung: Helmut Kraus, www.exclam.de �Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

978-3-86490-208-6

1. Auflage �Copyright © 201 dpunkt.verlag GmbHWieblinger Weg 17�69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen. 5 4 3 2 1 0

v

Inhaltsverzeichnis

1 Einleitung 1

1.1 Überblick über Continuous Delivery und das Buch . . . . . . . 11.2 Warum überhaupt Continuous Delivery? . . . . . . . . . . . . . . 21.3 Für wen ist das Buch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Übersicht über die Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Pfade durch das Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Continuous Delivery: Was und wie? 13

2.1 Was ist Continuous Delivery? . . . . . . . . . . . . . . . . . . . . . . 132.2 Warum Software-Releases so kompliziert sind . . . . . . . . . 132.3 Werte von Continuous Delivery . . . . . . . . . . . . . . . . . . . . 142.4 Vorteile von Continuous Delivery . . . . . . . . . . . . . . . . . . . 17

2.4.1 Continuous Delivery für Time-to-Market . . . . . . 172.4.2 Continuous Delivery zur Risikominimierung . . . . 202.4.3 Schnelleres Feedback und Lean . . . . . . . . . . . . . . 23

2.5 Aufbau und Struktur einer Continuous-Delivery-Pipeline . 242.6 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Infrastruktur bereitstellen 29

3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Installationsskripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Chef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1 Technische Grundlagen . . . . . . . . . . . . . . . . . . . . 373.3.2 Chef Solo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3.3 Chef Solo: Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Inhaltsverzeichnisvi

3.3.4 Knife und Chef Server . . . . . . . . . . . . . . . . . . . . . 453.3.5 Chef Server: Fazit . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4 Vagrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.1 Ein Beispiel mit Chef und Vagrant . . . . . . . . . . . . 513.4.2 Vagrant: Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.5.1 Dockers Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . 543.5.2 Docker-Container erstellen . . . . . . . . . . . . . . . . . 563.5.3 Beispielanwendung mit Docker betreiben . . . . . . 593.5.4 Docker und Vagrant . . . . . . . . . . . . . . . . . . . . . . 613.5.5 Komplexe Konfigurationen mit Docker . . . . . . . . 63

3.6 Infrastructure as Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.7 Platform as a Service (PaaS) . . . . . . . . . . . . . . . . . . . . . . . 663.8 Umgang mit Daten und Datenbanken . . . . . . . . . . . . . . . . 693.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.10 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4 Build-Automatisierung und Continuous Integration 77

4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2 Build-Automatisierung und Build-Tools . . . . . . . . . . . . . . 78

4.2.1 Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.2 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.3 Gradle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.2.4 Weitere Build-Tools . . . . . . . . . . . . . . . . . . . . . . . 884.2.5 Auswahl des geeigneten Tools . . . . . . . . . . . . . . . 884.2.6 Links und Literatur . . . . . . . . . . . . . . . . . . . . . . . 89

4.3 Unit-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3.1 »Gute« Unit-Tests schreiben . . . . . . . . . . . . . . . . 924.3.2 TDD – Test Driven Development . . . . . . . . . . . . . 944.3.3 Clean Code und Software Craftsmanship . . . . . . 954.3.4 Links und Literatur . . . . . . . . . . . . . . . . . . . . . . . 96

4.4 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.4.1 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.4.2 Continuous-Integration-Infrastruktur . . . . . . . . 1014.4.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.4.4 Links und Literatur . . . . . . . . . . . . . . . . . . . . . . 103

4.5 Messung von Codequalität . . . . . . . . . . . . . . . . . . . . . . . 1054.5.1 SonarQube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.5.2 Links und Literatur . . . . . . . . . . . . . . . . . . . . . . 109

viiInhaltsverzeichnis

4.6 Management von Artefakten . . . . . . . . . . . . . . . . . . . . . 1104.6.1 Integration in den Build . . . . . . . . . . . . . . . . . . 1124.6.2 Weiterreichende Funktionen von Repositories . 1144.6.3 Links und Literatur . . . . . . . . . . . . . . . . . . . . . . 114

4.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5 Akzeptanztests 117

5.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.2 Die Test-Pyramide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.3 Was sind Akzeptanztests? . . . . . . . . . . . . . . . . . . . . . . . . 1215.4 GUI-basierte Akzeptanztests . . . . . . . . . . . . . . . . . . . . . . 1255.5 Alternative Werkzeuge für GUI-Tests . . . . . . . . . . . . . . . 1315.6 Textuelle Akzeptanztests . . . . . . . . . . . . . . . . . . . . . . . . 1335.7 Alternative Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . 1365.8 Strategien für Akzeptanztests . . . . . . . . . . . . . . . . . . . . . 1375.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.10 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6 Kapazitätstests 143

6.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.2 Kapazitätstests – wie? . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.3 Kapazitätstests implementieren . . . . . . . . . . . . . . . . . . . 1496.4 Kapazitätstests mit Gatling . . . . . . . . . . . . . . . . . . . . . . . 1506.5 Alternativen zu Gatling . . . . . . . . . . . . . . . . . . . . . . . . . 1556.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576.7 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

7 Exploratives Testen 159

7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1597.2 Warum explorative Tests? . . . . . . . . . . . . . . . . . . . . . . . 1597.3 Wie vorgehen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1617.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657.5 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

8 Deploy – der Rollout in Produktion 167

8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678.2 Rollout und Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Inhaltsverzeichnisviii

8.3 Roll Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698.4 Blue/Green Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 1718.5 Canary Releasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728.6 Continuous Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 1748.7 Virtualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768.8 Jenseits der Webanwendungen . . . . . . . . . . . . . . . . . . . . 1788.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1798.10 Links und Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

9 Operate – Produktionsbetrieb der Anwendungen 181

9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1819.2 Herausforderungen im Betrieb . . . . . . . . . . . . . . . . . . . . 1829.3 Log-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

9.3.1 Werkzeuge zum Verarbeiten von Log-Dateien . . 1869.3.2 Logging in der Beispielanwendung . . . . . . . . . . . 188

9.4 Logs der Beispielanwendung analysieren . . . . . . . . . . . . . 1899.5 Andere Technologien für Logs . . . . . . . . . . . . . . . . . . . . 1959.6 Fortgeschrittene Log-Techniken . . . . . . . . . . . . . . . . . . . 1969.7 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1979.8 Metriken mit Graphite . . . . . . . . . . . . . . . . . . . . . . . . . . 1989.9 Metriken in der Beispielanwendung . . . . . . . . . . . . . . . . 2009.10 Andere Monitoring-Lösungen . . . . . . . . . . . . . . . . . . . . . 2029.11 Weitere Herausforderungen beim Betrieb der �

Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2039.12 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2059.13 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

10 Einführen von Continuous Delivery in Unternehmen 209

10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20910.2 Continuous Delivery von Anfang an . . . . . . . . . . . . . . . . 20910.3 Value Stream Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 21010.4 Weitere Optimierungsmaßnahmen . . . . . . . . . . . . . . . . . 21310.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21710.6 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

ixInhaltsverzeichnis

11 Continuous Delivery und DevOps 219

11.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21911.2 Was ist DevOps? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21911.3 Continuous Delivery und DevOps . . . . . . . . . . . . . . . . . 22311.4 Wohin geht die Reise? . . . . . . . . . . . . . . . . . . . . . . . . . . 22711.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22911.6 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

12 Continuous Delivery, DevOps und Softwarearchitektur 231

12.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23112.2 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23112.3 Komponentenaufteilung für Continuous Delivery �

optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23412.4 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23612.5 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23912.6 Umgang mit neuen Features . . . . . . . . . . . . . . . . . . . . . . 24212.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24612.8 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

13 Fazit: Was bringt’s? 249

13.1 Links & Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Index 251

1

1 Einleitung

1.1 Überblick über Continuous Delivery und das Buch

Continuous Delivery ermöglicht es, Software schneller und mit wesentlich höherer Zuverlässigkeit in Produktion zu bringen als bis-her. Grundlage dafür ist eine Continuous-Delivery-Pipeline, die das Ausrollen der Software weitgehend automatisiert und so einen repro-duzierbaren, risikoarmen Prozess für die Bereitstellung neuer Releases darstellt.

Woher kommt der Begriff Continuous Delivery?

Das agile Manifest (http://agilemanifesto.org) definiert als wichtigstes Ziel:

»Our highest priority is to satisfy the customer through early and conti-nuous delivery of valuable software.«

Die deutsche Übersetzung findet sich ebenfalls auf der Website:

»Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierli-che Auslieferung wertvoller Software zufrieden zu stellen.«

Also ist Continuous Delivery eine Technik aus dem agilen Umfeld.

Dieses Buch erläutert, wie eine solche Pipeline praktisch aufgebaut werden kann und welche Technologien dazu eingesetzt werden kön-nen. Dabei geht es nicht nur um das Kompilieren und die Installation der Software, sondern auch um verschiedene Tests, die dazu dienen, die Qualität der Software abzusichern.

Das Buch zeigt außerdem, welche Auswirkungen Continuous Deli-very auf das Zusammenspiel zwischen Entwicklung (Development) und Betrieb (Operations) im Rahmen von DevOps hat. Schließlich werden die Auswirkungen auf die Softwarearchitektur beschrieben. Neben der Theorie wird ein möglicher Technologie-Stack vorgestellt, der Build, Continuous Integration, Lasttests, Akzeptanztests und Monitoring abdeckt. Für die einzelnen Bestandteile des Technologie-Stacks gibt es jeweils ein Beispielprojekt, mit dem der Leser praktische

1 Einleitung2

Erfahrungen sammeln kann. Das Buch bietet einen Einstieg in den Technologie-Stack und zeigt außerdem auf, wie man sich mit den The-men tiefergehend beschäftigen kann.

Durch Experimente und Vorschläge zum selber Ausprobieren lädt es zur weiteren praktischen Vertiefung ein. Die Leser erhalten so Anre-gungen, wie sie sich weiter in die Themen vertiefen und eigene Erfah-rungen sammeln können. So können die Beispielprojekte Basis für eigene Experimente oder für den Aufbau einer eigenen Continuous-Deployment-Pipeline sein.

1.2 Warum überhaupt Continuous Delivery?

Warum sollte man überhaupt Continuous Delivery einsetzen? Eine kleine Geschichte soll diese Frage beantworten – ob sie wahr ist oder nicht, bleibt offen.

Eine kleine Geschichte Das Marketing eines Unternehmens – nennen wir es Raffzahn Online Commerce GmbH – hatte entschieden, den Registrierungspro-zess auf der E-Commerce-Website zu überarbeiten. Dadurch sollten mehr Kunden gewonnen und der Umsatz erhöht werden. Also machte sich ein Entwicklerteam an die Arbeit. Nach nicht allzu langer Zeit waren sie fertig.

Zunächst mussten die Änderungen getestet werden. Dazu hatte das Team der Raffzahn Online Commerce GmbH in einem aufwendi-gen Prozess eine Testumgebung aufgebaut, auf der die Software manu-ell getestet wurde. Und es wurden tatsächlich Fehler gefunden. Mittler-weile waren die Entwickler aber schon bei dem nächsten Projekt und mussten sich wieder einarbeiten, bevor sie die Fehler mit einem Fix beheben konnten. Und wegen der manuellen Tests stellte sich bei eini-gen »Fehlern« heraus, dass die Tester nicht richtig getestet hatten oder die Fehler aus irgendwelchen Gründen nicht reproduzierbar waren.

Nun galt es, den Code in Produktion zu bringen. Der Prozess dazu war aufwendig – denn die E-Commerce-Website der Raffzahn Online Commerce GmbH war über die Jahre gewachsen und daher sehr kom-plex. Nur dieses eine Feature auszuliefern, rechtfertigte den Aufwand nicht. Daher wurde nur einmal pro Monat deployt. Schließlich konnte die Änderung zusammen mit den anderen Änderungen aus dem letzten Monat in Produktion gehen. Dazu war eine Nacht reserviert. Leider gab es beim Rollout einen Fehler. Das Team machte sich an die Arbeit, das Problem zu analysieren. Aber das war so schwierig, dass das Sys-tem am nächsten Morgen nicht zur Verfügung stand. Zu diesem Zeit-punkt waren die Mitarbeiter übernächtigt und standen unter großem Stress – jede Minute Ausfall kostete bares Geld. Und zurück zur alten

31.2 Warum überhaupt Continuous Delivery?

Version ging es nicht, weil einige Änderungen im Deployment nicht ohne Weiteres rückgängig gemacht werden konnten. Erst im Laufe des Tages, nach einer ausführlichen Fehleranalyse, konnte eine Task Force das Problem beheben und die Website stand wieder zur Verfügung. Der Fehler war eine Konfigurationsänderung gewesen, die in der Test-umgebung vorgenommen, aber bei der Produktionseinführung verges-sen worden war.

Also schien alles in Ordnung zu sein – aber es gab einen weiteren Fehler, der zunächst nicht entdeckt wurde. Dieser Fehler hätte eigent-lich durch die manuellen Tests gefunden werden sollen. Der Test, der den Fehler gefunden hätte, wurde auch erfolgreich durchgeführt. Aber in der Testphase wurden auch einige Fehler gefixt und dieser Test wurde nur vor den Fixes durchgeführt. Der Fehler wurde erst durch einen der Fixes eingeführt. Nach den Fixes wurde der Test nicht noch einmal durchgeführt – daher konnte der Fehler es bis in die Produktion schaffen.

Am nächsten Tag stellte sich also mehr zufällig heraus, dass die Registrierung für die Website der Raffzahn Online Commerce GmbH gar nicht mehr funktionierte. Das war niemandem aufgefallen und erst, nachdem der erste potenzielle Kunde sich bei der Hotline meldete, wurde das Problem erkannt. Wie viele Registrierungen dieser Ausfall gekostet hatte, konnte leider niemand sagen – dazu fehlten Informati-onen über die Nutzung der Website. Wie schnell die optimierte Regist-rierung diesen Nachteil ausgleichen konnte, ist fraglich. So konnte es gut sein, dass die Änderung nicht wie ursprünglich geplant zu mehr Registrierungen, sondern zu weniger geführt hatte. Und außerdem war das neue Release wesentlich langsamer – ein Umstand, mit dem vorher auch niemand gerechnet hatte.

Und so begann die Raffzahn Online Commerce GmbH, die nächs-ten Features zu implementieren, um in einem Monat wiederum ein Update der Website auszurollen. Was wohl dieses Mal passieren würde?

Continuous Delivery hilft.Continuous Delivery löst solche Probleme durch verschiedene Maßnahmen:

■ Es wird öfter deployt – bis hin zu mehreren Malen pro Tag. Dadurch wird die Zeit, bis ein neues Feature genutzt werden kann, verringert.

■ Durch häufige Deployments ist auch das Feedback auf neue Featu-res und Code-Änderungen schneller. Die Entwickler müssen sich nicht erst wieder darauf besinnen, was sie vor einem Monat imple-mentiert haben.

1 Einleitung4

■ Um schneller zu deployen, müssen der Aufbau von Umgebungen und die Tests weitgehend automatisiert werden, da der Aufwand sonst zu hoch ist.

■ Die Automatisierung führt zu Reproduzierbarkeit: Wenn die Test-umgebung erfolgreich aufgebaut werden kann, dann lässt sich mit demselben Automatismus auch die Produktion aufbauen – und zwar mit derselben Konfiguration. Das Problem durch die Fehl-konfiguration der Produktionsumgebung wäre also nicht aufgetre-ten.

■ Außerdem führt die Automatisierung zu mehr Flexibilität. Testum-gebungen können On-Demand aufgesetzt werden. So kann es z.B. bei einem Redesign der Oberflächen zeitlich begrenzt eine separate Testumgebung für Marketing geben. Oder für großangelegte Last-tests können zusätzliche Umgebungen aufgesetzt werden, um eine produktionsnahe Umgebung zu haben, die nach den Tests wieder abgerissen werden, so dass keine dauerhaften Investitionen in Hardware notwendig sind – wenn beispielsweise eine Cloud genutzt wird.

■ Automatisierte Tests führen dazu, dass Fehler leichter reproduziert werden können. Da die exakt gleichen Schritte bei jedem Test aus-geführt werden, gibt es auch keine Fehler bei der Testdurchfüh-rung.

■ Wenn Tests automatisiert sind, können sie öfter ausgeführt wer-den. Also wäre der Fix durch den gesamten Testprozess gegangen und dieser Fehler nicht erst in Produktion aufgefallen.

■ Das Risiko eines neuen Release wird weiter reduziert, indem das Deployment in Produktion so aufgesetzt wird, dass es einen Weg zurück zur alten Version gibt. So wird der Produktionsausfall aus dem Beispiel verhindert.

■ Und schließlich sollten die Anwendungen auch ein fachliches Monitoring haben, so dass die Registrierung nicht ausfallen kann, ohne dass es jemand merkt.

Durch Continuous Delivery gewinnt das Business eine schnellere Ver-fügbarkeit neuer Features und eine zuverlässigere IT. Die Zuverlässig-keit ist auch für die IT nützlich. Nachts oder an Wochenenden unter hohem Stress neue Releases auszurollen und Fehler zu beheben, macht eben keinen Spaß. Und es ist sicher auch für die IT besser, wenn Fehler durch Tests auffallen und nicht erst in Produktion.

51.3 Für wen ist das Buch?

Um Continuous Delivery umzusetzen, gibt es eine Vielzahl an Technologien und Techniken. Continuous Delivery hat Auswirkungen bis hin zur Architektur der Anwendung. Genau um diese Themen geht es in diesem Buch. Am Ende steht ein schnellerer und zuverlässigerer Prozess, um Software in Produktion zu bringen.

1.3 Für wen ist das Buch?Das Buch wendet sich an Manager, Architekten, Entwickler und Administratoren, die Continuous Delivery als Methodik und/oder DevOps als Organisationsform einführen wollen:

■ Manager lernen durch den theoretischen Teil Prozess, Erforder-nisse und Vorteile von Continuous Delivery für ihr Unternehmen kennen. Außerdem können sie die technischen Konsequenzen von Continuous Delivery abschätzen.

■ Entwickler und Administratoren erhalten eine umfassende Einlei-tung in die technischen Aspekte und können damit die notwendi-gen Fähigkeiten erlernen, um Continuous Delivery umzusetzen und eine entsprechende Pipeline aufzubauen.

■ Architekten können neben den technischen Aspekten auch die Aus-wirkung auf die Softwarearchitektur kennenlernen – siehe dazu Kapitel 12.

Das Buch stellt verschiedene Technologien für die Umsetzung von Continuous Delivery vor. Als Beispiel dient ein Java-Projekt. Für einige technologische Bereiche – zum Beispiel für die Umsetzung von Akzep-tanztests – sind für andere Programmiersprachen andere Technologien etabliert. Das Buch zeigt an den jeweiligen Stellen Alternativen auf, fokussiert aber auf Java. Technologien zur automatisierten Bereitstel-lung von Infrastrukturen sind unabhängig von der genutzten Program-miersprache. Das Buch ist besonders gut für Leser geeignet, die im Java-Umfeld aktiv sind – für andere Technologien müssen die Ansätze teilweise vom Leser selber transferiert werden.����

1 Einleitung6

1.4 Übersicht über die Kapitel

Das Buch umfasst drei Teile. Der erste Teil legt die Grundlagen für ein Verständnis von Continuous Delivery:

■ Kapitel 2 führt den Begriff Continuous Delivery ein und zeigt auf, welche Probleme Continuous Delivery wie löst. Dabei wird eine Einführung in die Continuous-Delivery-Pipeline gegeben.

■ Für Continuous Delivery muss Infrastruktur automatisiert bereit-gestellt werden – es muss Software auf Servern installiert werden. Kapitel 3 stellt dazu einige Ansätze vor. Chef dient zur Automati-sierung von Installationen. Mit Vagrant können Testumgebungen auf Entwicklerrechnern eingerichtet werden. Docker ist nicht nur eine sehr effiziente Virtualisierungslösung, sondern kann auch zur automatisierten Installation von Software dienen. Schließlich wird noch ein Überblick über die Nutzung von PaaS-Cloud-Lösungen (Platform as a Service) für Continuous Delivery gegeben.

Es schließen sich im zweiten Teil Kapitel an, die einzelne Bestandteile einer Continuous-Delivery-Pipeline konkret beschreiben. Neben einer konzeptionellen Erläuterung werden jeweils beispielhaft konkrete Technologien dargestellt, mit denen dieser Teil der Pipeline umgesetzt werden kann:

■ Im Mittelpunkt von Kapitel 4 von Bastian Spannberg steht alles, was beim Commit einer neuer Softwareversion geschieht. Build-Werkzeuge wie Gradle oder Maven werden vorgestellt, ein Über-blick über Unit-Tests wird gegeben und Continuous Integration mit Jenkins wird beleuchtet. Daran schließen sich statische Code Reviews mit SonarQube und Repositories wie Nexus oder Artifac-tory an.

■ Kapitel 5 zeigt mit JBehave und Selenium einen Ansatz für automa-tisierte GUI-basierte Akzeptanztests und für textuelle Akzeptanz-tests.

■ Performance deckt das Kapitel 6 durch Kapazitätstests ab. Als Bei-spieltechnologie wird Gatling genutzt.

■ Das explorative Testen (Kap. 7) dient dazu, manuell neue Features und generell Probleme in der Anwendung zu überprüfen.

Diese Kapitel betrachten den Anfang der Continuous-Delivery-Pipe-line. Diese Phasen beeinflussen hauptsächlich die Softwareentwick-lung. Die weiteren Kapitel stellen vor allem Techniken und Technolo-

71.5 Pfade durch das Buch

gien vor, die bei den betriebsnahen Bereichen von Continuous Delivery nützlich sind:

■ Kapitel 8 zeigt Vorgehensweisen, die beim Rollout der Software in Produktion nützlich sind, um Risiken zu reduzieren.

■ Aus dem Betrieb der Anwendung können zahlreiche Daten erho-ben werden, um so Feedback zu bekommen. Kapitel 9 stellt dazu Technologien vor: den ELK-Stack (Elasticsearch – Logstash – Kibana) für Log-Dateien-Analyse und Graphite für Monitoring.

Zu den Technologien aus diesen Kapiteln gibt es jeweils Beispiele zum selber Experimentieren und Nachvollziehen am eigenen Rechner. Dadurch können Leser sehr einfach eigene Erfahrungen sammeln. Dank Infrastrukturautomatisierung sind diese Beispiele auch auf dem eigenen Rechner recht einfach zum Laufen zu bringen.

Schließlich stellt sich die Frage, wie Continuous Delivery einge-führt werden kann und welche Auswirkungen Continuous Delivery hat. Das zeigt der dritte Teil des Buchs:

■ Kapitel 10 zeigt, wie Continuous Delivery in einer Organisation eingeführt werden kann.

■ DevOps beschreibt das Zusammenwachsen von Betrieb (Dev) und Entwicklung (Ops) zu einer Organisationseinheit (Kap. 11). Das ist im Zusammenhang mit Continuous Delivery nützlich, hat aber noch viele weitere Vorteile.

■ Continuous Delivery hat auch Auswirkungen auf die Architektur der Anwendungen. Diese Herausforderungen diskutiert Kapitel 12.

■ Am Ende steht das Fazit in Kapitel 13.

1.5 Pfade durch das Buch

Dieser Abschnitt erläutert die möglichen Lesepfade durch das Buch für die verschiedenen Zielgruppen – also welche Kapitel in welcher Rei-henfolge gelesen werden sollten. Die Einführung in Kapitel 2 ist für alle Leser interessant – das Kapitel klärt grundlegende Begriffe und zeigt die Motivation für Continuous Delivery auf.

Die weiteren Kapitel haben unterschiedliche Ausrichtungen:

■ Für Techniker, die sich vor allem für die Entwicklung interessieren, sind die Kapitel rund um Commit und Tests interessant. In diesen Kapiteln geht es neben Entwicklung auch um Qualitätssicherung und Build. Die Kapitel zeigen, wie diese Aufgaben durch Conti-

1 Einleitung8

nuous Delivery beeinflusst werden, und geben konkrete Code- und Technologiebeispiele aus dem Java-Bereich.

■ Administratoren und Betriebsmitarbeiter sollten sich mit Themen wie dem Deployment, dem Bereitstellen von Infrastrukturen und dem Betrieb auseinandersetzen, die ebenfalls durch Continuous Delivery beeinflusst werden.

■ Aus der Managementsicht sind die Einführung von Continuous Delivery und der Zusammenhang zwischen DevOps und Conti-nuous Delivery interessant. Diese beiden Kapitel zeigen die Aus-wirkungen von Continuous Delivery auf die Organisation.

■ Schließlich ist der Architektur und dem Fazit jeweils noch ein Extra-Kapitel gewidmet.

Architekten sind eher breit aufgestellt. Sie werden sicher das Kapitel 12 über Architektur lesen, aber meistens interessieren sich Architekten auch für die technischen Details und die Management-sicht. Daher werden Architekten vermutlich mindestens ausgewählte Kapitel aus diesen Bereichen lesen.

Abb. 1–1Pfade durch das Buch

2 - Grundlagen

4 - Commit

3 - Infrastrukturen

bereitstellen

5 - Akzeptanztests

6 - Kapazitätstests

7 - Explorative Tests

8 - Deploy

9 - Operate

11 - Continuous Delivery & DevOps

10 - Einführung von Continuous

Delivery12 - Architektur

Dev

Ops Management Architektur

13 - Fazit

3 - Infrastrukturen

bereitstellen

91.6 Danksagung

1.6 Danksagung

Bedanken möchte ich mich bei Bastian Spannberg für seinen Beitrag zu diesem Buch. Außerdem gilt mein Dank den Reviewern, die mit ihren Kommentaren das Buch wesentlich beeinflusst haben: Marcel Birkner, Lars Gentsch, Halil-Cem Gürsoy, Felix Müller, Sascha Möllering und Alexander Papaspyrou. Bedanken möchte ich mich auch für die vielen Diskussionen – viele Gedanken und Ideen sind in solchen Dialogen entstanden.

Schließlich habe ich meinen Freunden, Eltern und Verwandten zu danken, die ich für das Buch oft vernachlässigt habe – insbesondere meiner Frau.

Und natürlich gilt mein Dank all jenen, die an den in diesem Buch erwähnten Technologien gearbeitet haben und so die Grundlagen für Continuous Delivery gelegt haben.

Last but not least möchte ich dem dpunkt.verlag und René Schön-feldt danken, der mich sehr professionell bei der Erstellung des Buchs unterstützt hat.

13

2 Continuous Delivery: Was und wie?

2.1 Was ist Continuous Delivery?

Diese Frage ist nicht so einfach zu beantworten. Die Erfinder des Begriffs geben in [6] keine echte Definition. Martin Fowler [7] stellt in den Mittelpunkt, dass die Software jederzeit in Produktion ausgeliefert werden kann. Dazu ist eine Automatisierung der Prozesse zur Installa-tion der Software notwendig und Feedback über die Qualität der Soft-ware. Wikipedia hingegen spricht von einer Optimierung und Auto-matisierung des Software-Release-Prozesses [8].

Letztendlich geht es bei Continuous Delivery darum, den Prozess bis zum Release der Software zu betrachten und zu optimieren. Genau dieser Prozess wird oft bei der Entwicklung ausgeblendet.

2.2 Warum Software-Releases so kompliziert sind

Software-Releases sind eine Herausforderung – jede IT-Abteilung hat wohl schon ein Wochenende in der Firma verbracht, um ein Release in Produktion zu bringen. Oft enden solche Aktionen damit, dass die Software irgendwie in Produktion gebracht wird – weil ab einem bestimmten Punkt in dem Prozess der Weg zurück zur alten Version noch gefährlicher und schwieriger ist, als der Weg nach vorne. An die Installation des Release schließt sich häufig eine lange Phase an, in der das Release stabilisiert werden muss.

Continuous Integration macht Hoffnung.

Heutzutage ist das Release in Produktion ein Problem. Vor nicht allzu langer Zeit setzten die Probleme schon wesentlich früher an: Die einzelnen Teams arbeiteten an ihren Modulen und vor dem Release mussten die verschiedenen Versionen zunächst integriert werden. Wenn die Module das erste Mal zusammen genutzt werden sollten, kompilierte das System oft noch nicht einmal. Tage oder gar Wochen später waren dann erst alle Änderungen integriert und kompilierten erfolgreich. Dann erst konnten die Deployments beginnen. Diese Prob-

2 Continuous Delivery: Was und wie?14

leme sind heute meistens gelöst: Alle Teams arbeiten an einem gemein-samen Versionsstand, der ständig automatisiert gemeinsam kompiliert und getestet wird. Dieses Vorgehen nennt man Continuous Integra-tion. Die dafür notwendige Infrastruktur wird Kapitel 4 noch detail-liert darstellen. Dass die Probleme dieser Phase gelöst sind, macht Hoffnung, dass die Probleme in den anderen Phasen hin zur Produk-tion ebenfalls lösbar sind.

Langsame und risikoreiche Prozesse

Die Prozesse in den späteren Phasen sind oft sehr komplex und aufwendig. Durch manuelle Prozesse sind sie außerdem langwierig und fehleranfällig. Das betrifft das Release in Produktion, aber auch die Phasen davor – also beispielsweise die verschiedenen Tests. Schließ-lich können gerade bei einem manuellen Prozess, der zudem nur ein paar Mal im Jahr ausgeführt wird, viele Fehler passieren – und das trägt zum Risiko bei.

Wegen des hohen Risikos und Aufwands werden Releases nicht besonders häufig in Produktion gebracht. Dadurch dauern die Pro-zesse noch länger, weil es keinen Übungseffekt gibt. Ebenso ist es schwierig, die Prozesse zu optimieren.

Schnell geht auch. Auf der anderen Seite gibt es immer Möglichkeiten, im Notfall ein Release sehr schnell in Produktion zu bringen – wenn beispielsweise dringend ein Fehler behoben werden muss. Diese Prozesse umgehen aber jegliche Tests und damit die Sicherheitsnetze, die im normalen Prozess genutzt werden. Letztendlich ist das eine Risikomaximierung – die Tests werden ja aus einem Grund durchgeführt.

Also ist der normale Weg in die Produktion langsam und risiko-reich – und im Notfall ist der Weg schnell, aber dafür noch risikorei-cher.

2.3 Werte von Continuous Delivery

Mit der Motivation und den Ansätzen aus der Continuous Integrationwollen wir den Weg für Releases in die Produktion optimieren.

Ein wesentliches Prinzip von Continuous Integration ist »If it hurts do it more often and bring the pain forward« – etwa: »Wenn es weh tut, tu es öfter und verlagere den Schmerz nach vorne.« Was sich wie Masochismus anhört, ist in Wirklichkeit ein Ansatz zur Problemlö-sung. Statt die Probleme bei den Releases zu umgehen, indem man möglichst wenig Releases in Produktion bringt, sollen die Prozesse so oft und so früh wie möglich durchgeführt werden, um sie möglichst schnell zu optimieren – in Bezug auf Geschwindigkeit und auf die Zuverlässigkeit. Continuous Delivery zwingt so die Organisation, sich zu ändern und eine andere Arbeitsweise zu adaptieren.

152.3 Werte von Continuous Delivery

Überraschend ist der Ansatz eigentlich nicht: Wie schon erwähnt, kann jede IT-Organisation in kurzer Zeit einen Fix in Produktion brin-gen – und dabei werden meistens nur ein Teil der sonst üblichen Tests und Sicherheitsvorkehrungen ausgeführt. Das ist möglich, weil die Änderung nur klein ist und daher ein geringes Risiko hat. Hier zeigt sich ein anderer Ansatz für die Risikominimierung: Statt einer Absi-cherung über komplexe Prozesse und seltene Releases, kann man auch kleine Änderungen in Produktion bringen. Dieser Ansatz ist genau der-selbe wie bei Continuous Integration (CI): Bei CI werden die Änderun-gen an der Software durch die einzelnen Entwickler und das Team ständig integriert und so häufig kleine Änderungen integriert, statt die Teams und Entwickler tage- oder wochenlang getrennt arbeiten zu las-sen und die Änderungen am Ende zusammenzuführen – was meistens zu erheblichen Problemen führt, manchmal so sehr, dass die Software noch nicht einmal kompiliert werden kann.

Continuous Delivery ist aber mehr als »schnell und klein«. Conti-nuous Delivery liegen verschiedene Werte zugrunde. Aus diesen Wer-ten lassen sich die konkreten technischen Maßnahmen ableiten.

Regelmäßigkeit

Regelmäßigkeit bedeutet, Prozesse öfter durchzuführen. Alle Prozesse, die zur Auslieferung von Software notwendig sind, sollten regelmäßig durchgeführt werden – und nicht nur, wenn ein Release in Produktion gebracht werden muss. Beispielsweise ist es notwendig, Test- und Sta-ging-Umgebungen aufzubauen. Die Testumgebungen können für fach-liche oder technische Tests genutzt werden. Die Staging-Umgebung kann vom Endkunden genutzt werden, um die Features eines neuen Release auszuprobieren und zu evaluieren. Durch die Bereitstellung dieser Umgebungen kann der Prozess für den Aufbau einer Umgebung zu einem regelmäßigen Prozess werden, der nicht erst ausgeführt wird, wenn die Produktionsumgebung aufgebaut wird. Um diese Vielzahl von Umgebungen ohne allzu großen Aufwand zu erstellen, müssen die Prozesse weitgehend automatisiert werden. Regelmäßigkeit führt meistens zur Automatisierung. Ähnliches gilt für Tests: Es ist nicht sinnvoll, die notwendigen Tests bis kurz vor das Release zu verschie-ben – sie sollten lieber regelmäßig ausgeführt werden. Auch in diesem Fall erzwingt der Ansatz praktisch eine Automatisierung, um die Auf-wände in Zaum zu halten. Regelmäßigkeit führt auch zu einer hohen Zuverlässigkeit – was ständig durchgeführt wird, kann zuverlässig wiederholt und durchgeführt werden.

2 Continuous Delivery: Was und wie?16

Nachvollziehbarkeit

Alle Änderungen an der auszuliefernden Software und der dafür not-wendigen Infrastruktur müssen nachvollziehbar sein. Es muss möglich sein, jeden Stand der Software und Infrastruktur zu rekonstruieren. Das führt zu einer Versionierung, die nicht nur die Software, sondern auch die notwendigen Umgebungen erfasst. Idealerweise ist es mög-lich, jeden Stand der Software zusammen mit der für den Betrieb not-wendigen Umgebung in der richtigen Konfiguration zu erzeugen. Dadurch können alle Änderungen an der Software und an den Umge-bungen nachvollzogen werden. Ebenso ist es einfach möglich, für die Fehleranalyse ein passendes System aufzubauen. Und schließlich kön-nen so Änderungen dokumentiert oder auditiert werden.

Eine mögliche Lösung des Problems ist es, dass Produktions- und Staging-Umgebung nur für bestimmte Personen zugänglich sind. Dadurch sollen Änderungen »kurz zwischendurch« vermieden wer-den, die nicht dokumentiert werden und nicht mehr nachvollziehbar sind. Außerdem sprechen Sicherheitsanforderungen und Datenschutz gegen den Zugriff auf Produktionsumgebungen.

Mit Continuous Delivery sind Eingriffe an einer Umgebung nur möglich, wenn ein Installationsskript geändert wird. Die Änderungen an den Skripten sind nachvollziehbar, wenn sie in einer Versionskont-rolle liegen. Die Entwickler der Skripte haben auch keinen Zugriff auf die Produktionsdaten, so dass es mit Datenschutz ebenfalls keine Pro-bleme gibt.

Regression

Um das Risiko bei der Auslieferung der Software zu minimieren, muss die Software getestet werden. Natürlich muss dabei die korrekte Funk-tion neuer Features sichergestellt werden. Aber viel Aufwand entsteht, um Regressionen zu vermeiden – also Fehler in eigentlich schon getes-teten Softwareteilen, die durch Modifikationen eingeführt worden sind. Dazu müssen eigentlich alle Tests bei jeder Modifikation noch einmal ausgeführt werden – schließlich kann eine Modifikation an einer Stelle des Systems irgendwo anders einen Fehler erzeugen. Dazu sind automatisierte Tests notwendig, da sonst der Aufwand für die Ausführung der Tests viel zu hoch wird. Sollte ein Fehler es dennoch bis in die Produktion schaffe, so kann er immer noch durch Monito-ring entdeckt werden. Idealerweise gibt es die Möglichkeit, auf dem Produktionssystem möglichst einfach eine ältere Version ohne den Fehler zu installieren (Rollback) oder einen Fix schnell in Produktion zu bringen (Roll forward). Eigentlich geht es also um eine Art

172.4 Vorteile von Continuous Delivery

Frühwarnsystem, das über verschiedene Phasen wie Test und Produk-tion Maßnahmen ergreift, um Regressionen zu entdecken und zu lösen.

2.4 Vorteile von Continuous Delivery

Continuous Delivery bietet zahlreiche Vorteile. Je nach Szenario kön-nen die Vorteile unterschiedlich wichtig sein – und damit auch die Nut-zung von Continuous Delivery beeinflussen.

2.4.1 Continuous Delivery für Time-to-Market

Continuous Delivery verringert die Zeit, die benötigt wird, um Ände-rungen in Produktion zu bringen. Dadurch ergibt sich auf der Geschäftsseite ein wesentlicher Vorteil: Es ist viel einfacher, auf Ände-rungen am Markt zu reagieren. Also verbessert Continuous Delivery das Time-to-Market.

Aber die Vorteile gehen weiter: Moderne Ansätze wie Lean Startup[1] propagieren einen Ansatz, der von der erhöhten Geschwindigkeit noch mehr profitiert. Im Wesentlichen geht es darum, am Markt Pro-dukte zu positionieren und die Marktchancen auszuwerten und dabei möglichst wenig Aufwand zu investieren. Ganz wie bei wissenschaftli-chen Experimenten wird definiert, wie der Erfolg des Produkts am Markt gemessen werden kann. Dann wird das Experiment durchge-führt und am Ende der Erfolg oder Misserfolg gemessen.

Ein Beispiel

Nehmen wir als konkretes Beispiel: In einem Webshop soll die Mög-lichkeit geschaffen werden, Bestellungen zu einem bestimmten Termin auszuliefern. Als erstes Experiment kann das Feature beworben wer-den. Als Indikator für den Erfolg dieses Experiments kann beispiels-weise die Anzahl der Klicks auf einen Link in der Werbung genutzt werden. Zu diesem Zeitpunkt ist noch keine Software entwickelt – das Feature ist also noch nicht implementiert. Wenn das Experiment zu keinem erfolgversprechenden Ergebnis geführt hat, ist das Feature wohl nicht sinnvoll und es können andere Features priorisiert werden – ohne dass viel Aufwand investiert worden ist.

Feature implementieren und ausliefern

Wenn das Experiment erfolgreich war, wird das Feature imple-mentiert und ausgeliefert. Auch dieser Schritt kann als Experiment durchgeführt werden: Metriken können helfen, um den Erfolg des Fea-

2 Continuous Delivery: Was und wie?18

tures zu kontrollieren. Beispielsweise kann die Anzahl der Bestellungen mit einem festen Liefertermin gemessen werden.

Auf zum nächsten Feature!

Bei der Analyse der Metriken stellt sich heraus, dass die Anzahl der Bestellungen hoch genug ist – und interessanterweise die meisten Bestellungen nicht direkt zum Kunden, sondern zu einer dritten Person geschickt werden. Weitere Messungen ergeben, dass es sich offensicht-lich um Geburtstagsgeschenke handelt. Basierend auf diesen Informa-tionen kann nun das Feature weiter ausgebaut werden – beispielsweise mit einem Geburtstagskalender und Empfehlungen für passende Geschenke. Auch dazu müssen natürlich entsprechende Features geplant, implementiert, ausgeliefert und schließlich der Erfolg gemes-sen werden. Oder vielleicht gibt es auch Möglichkeiten, die Markt-chancen dieser Features ganz ohne Implementierung zu evaluieren – durch Werbung, Kundeninterviews, Umfragen oder andere Ansätze.

Continuous Delivery führt zu Wettbewerbsvorteilen.

Continuous Delivery ermöglicht es, die notwendigen Änderungen an der Software schneller auszuliefern. Dadurch kann eine Firma schneller verschiedene Ideen ausprobieren und das Geschäftsmodell weiterentwickeln. Das führt zu einem Wettbewerbsvorteil: Da mehr Ideen ausgewertet werden können, ist es einfacher, die richtigen Ideen herauszufiltern – und zwar nicht aufgrund subjektiver Abschätzungen über die Markchancen, sondern anhand objektiv gemessener Daten.

Ohne Continuous Delivery Ohne Continuous Delivery wäre das Feature für die festen Liefer-termine geplant und beim nächsten Release ausgeliefert worden – das kann durchaus einige Monate dauern. Vorab hätte man wohl kaum gewagt, das Feature bereits zu bewerben – denn die lange Zeit, bis das Feature ausgeliefert wird, macht solche Werbung sinnlos. Wenn das Feature kein Erfolg geworden wäre, hätte man hohe Kosten bei der Implementierung gehabt, ohne dadurch einen Nutzen zu erzielen. Das Messen des Erfolgs wäre sicher auch in einem klassischen Modell mög-lich, aber die Reaktion würde deutlich länger dauern. Weiterentwick-lungen wie die Unterstützung für Geburtstage wären noch später am Markt, denn dafür muss die Software noch einmal ausgeliefert werden und der langwierige Release-Prozess hätte noch ein zweites Mal durch-laufen werden müssen. Außerdem ist es fraglich, ob der Erfolg des Fea-tures ausreichend detailliert gemessen wird, um das Potenzial für die Features rund um Geburtstage zu erkennen.

Continuous Delivery und Lean Startup

Dank Continuous Delivery können also die Optimierungszyklen viel schneller durchlaufen werden, weil Features praktisch jederzeit in Pro-duktion gebracht werden können. Das ermöglicht Ansätze wie Lean Startup. Das hat Auswirkungen auf die Geschäftsseite: Sie muss

192.4 Vorteile von Continuous Delivery

schneller neue Features definieren und sie muss nicht mehr langfristig planen, sondern kann auf die Ergebnisse der aktuellen Experimente reagieren. Das ist in Start-ups besonders einfach, aber auch in klassi-schen Organisationen können solche Strukturen aufgebaut werden. Der Lean-Startup-Ansatz hat leider einen irreführenden Namen: Er beschreibt einen Ansatz, bei dem neue Produkte durch eine Serie von Experimenten am Markt positioniert werden – und dieser Ansatz ist natürlich auch in klassischen Unternehmen umsetzbar, nicht nur in Start-ups. Er kann auch genutzt werden, wenn Produkte klassisch aus-geliefert werden müssen – beispielsweise auf Datenträgern, mit ande-ren komplexen Installationsprozeduren oder als Teil eines anderen Produkts wie einer Maschine. Dann muss die Installation der Software vereinfacht oder idealerweise automatisiert werden. Außerdem muss ein Kundenkreis identifiziert werden, der gerne neue Versionen der Software ausprobieren will und dazu Feedback geben kann – also klas-sische Beta-Tester oder Power-User.

Auswirkungen auf den Entwicklungsprozess

Continuous Delivery hat Auswirkungen auf den Softwareentwick-lungsprozess: Wenn einzelne Features in Produktion gebracht werden sollen, muss der Prozess das unterstützen. Einige Prozesse nutzen Itera-tionen von einem oder mehreren Wochen Länge. Am Ende jeder Itera-tion wird ein neues Release mit mehreren Features ausgeliefert. Das ist kein idealer Ansatz für Continuous Delivery, denn so können Features nicht alleine durch die Pipeline gebracht werden. Auch der Lean-Star-tup-Ansatz wird so erschwert: Wenn mehrere Features gleichzeitig aus-gerollt werden, ist es nicht offensichtlich, welche Änderung die Mess-werte beeinflusst. Nehmen wir an, dass die Auslieferung zu einem festen Liefertermin parallel mit einer Änderung der Versandpreise ein-her geht – welche der beiden Maßnahmen mehr Einfluss auf die höhe-ren Verkaufszahlen hatte, ist nicht zweifelsfrei zu klären.

Also sind Prozesse wie Scrum, XP (Extreme Programming) und natürlich der Wasserfall hinderlich, denn die Prozesse liefern immer mehrere Features gemeinsam aus. Kanban [2] hingegen fokussiert dar-auf, ein einzelnes Feature durch die verschiedenen Phasen schließlich in Produktion zu bringen. Das passt ideal zu Continuous Delivery. Natürlich kann man die anderen Prozesse auch so modifizieren, dass sie die Auslieferung einzelner Features unterstützen – dann sind die Prozesse aber abgewandelt und zumindest nicht mehr nach Lehrbuch umgesetzt. Eine weitere Möglichkeit ist es, Features zunächst zu deak-tivieren, um so zwar mehrere Features in einem Release gemeinsam auszuliefern, aber einzeln messbar zu machen.

Wettbewerbs-vorteil

Einfachere Releases

Schnellere & einfachere

Experimente

Schnelleres Time-to-Market

Abb. 2–1Gründe für

Continuous Delivery in einem Start-up-Umfeld

2 Continuous Delivery: Was und wie?20

Schließlich bedeutet dieser Ansatz auch, dass Teams mehrere unter-schiedliche Funktionen integrieren. Neben Entwicklung und Betrieb für die Features kämen noch Geschäftsrollen beispielsweise für Marke-ting in Frage. Durch die verringerten organisatorischen Hürden kann das Feedback aus dem Geschäftsbereich noch schneller in Experimente umgesetzt werden.

Selber ausprobieren und experimentieren

■ Informiere dich über Lean Startup und Kanban. Woher kommt Kanban

ursprünglich?

■ Suche dir ein bekanntes Projekt oder Feature in einem Projekt aus:

■ Was könnte ein minimales Produkt sein? Das minimale Produkt soll

einen Hinweis auf die Marktchancen des eigentlich geplanten Produkts

geben.

■ Kann man das Produkt auch ohne Software evaluieren? Kann man es

beispielsweise bewerben? Oder potenzielle Nutzer interviewen?

■ Wie misst man den Erfolg des Features? Gibt es beispielsweise einen

Umsatzeinfluss, eine Anzahl Klicks oder andere Werte, die man mes-

sen könnte?

■ Welchen Vorlauf haben Marketing und Vertrieb typischerweise für die

Planung eines Produkts oder Features? Wie passt das zum Lean-

Startup-Gedanken?

2.4.2 Continuous Delivery zur Risikominimierung

Hinter der Nutzung von Continuous Delivery, wie sie im letzten Abschnitt dargestellt worden ist, steht ein Geschäftsmodell. Bei klassi-schen Unternehmen hängt das Geschäft aber oft von langfristiger Pla-nung ab. Ein Ansatz wie Lean Startup lässt sich dann nicht umsetzen. Ebenso gibt es viele Unternehmen, bei denen Time-to-Market nicht entscheidend ist. Nicht alle Märkte sind diesbezüglich sehr kompetitiv. Das kann sich natürlich ändern, wenn solche Firmen plötzlich mit

212.4 Vorteile von Continuous Delivery

Konkurrenten konfrontiert werden, die dazu in der Lage sind, mit einem Lean-Startup-Modell an den Markt zu gehen.

In vielen Szenarien fällt Time-to-Market als Motivation für die Einführung von Continuous Delivery aus. Dennoch können die Tech-niken sinnvoll sein. Denn Continuous Delivery bietet weitere Vorteile:

■ Manuelle Release-Prozesse kosten viel Aufwand. Es ist keine Sel-tenheit, dass ganze IT-Abteilungen für jedes Release jeweils ein ganzes Wochenende blockiert werden. Und auch nach dem Release fallen meistens noch umfangreiche Nacharbeiten an.

■ Außerdem ist das Risiko hoch: Das Ausrollen der Software hängt von vielen manuellen Änderungen ab. Dabei können Fehler gesche-hen. Werden die Fehler nicht rechtzeitig analysiert und behoben, kann das für das Unternehmen weitreichende Konsequenzen haben.

Die Leittragenden sind in den IT-Abteilungen zu finden: Entwickler und Systemadministratoren, die Wochenenden und Nächte arbeiten, um Releases in Produktion zu bringen und Fehler zu beheben. Dabei sind sie wegen der hohen Risiken oft auch hohem Stress ausgesetzt. Und die Risiken sind nicht zu unterschätzen: Knight Capital beispiels-weise hat aufgrund eines fehlerhaften Software-Rollouts 440 Mio. $ verloren [4]. Die Folge war die Insolvenz der Firma. Aus solchen Sze-narien lassen sich eine Menge Fragen ableiten [5].

Continuous Delivery kann eine Lösung für solche Situationen sein: Ein wesentlicher Aspekt von Continuous Delivery sind die höhere Zuverlässigkeit und die Qualität im Release-Prozess. Dadurch können Entwickler und Systemadministratoren im wahrsten Sinne des Wortes ruhig schlafen. Dafür sind verschiedene Faktoren relevant:

■ Durch die höhere Automatisierung des Release-Prozesses werden die Ergebnisse besser reproduzierbar. Wenn also die Software in einer Test- oder Staging-Umgebung deployt und getestet worden ist, wird in der Produktion exakt dasselbe Ergebnis erzielt, weil die Umgebung vollständig identisch ist. So können Fehlerquellen weit-gehend eliminiert werden und das Risiko sinkt.

■ Es wird auch viel einfacher, Software zu testen, da die Tests weitge-hend automatisiert sind. Dadurch wird die Qualität weiter gestei-gert, da die Tests öfter durchlaufen werden können.

■ Wenn öfter deployt wird, sinkt das Risiko ebenfalls. Denn pro Deployment werden weniger Änderungen in Produktion gebracht.

2 Continuous Delivery: Was und wie?22

Weniger Änderungen bedeuten aber auch weniger Risiko, dass sich irgendwo ein Fehler eingeschlichen hat.

In gewisser Weise ist die Situation paradox: In der klassischen IT wird versucht, Releases möglichst selten in Produktion zu bringen, da sie mit einem hohen Risiko verbunden sind. Bei jedem Release kann sich ein Fehler mit potenziell desaströsen Konsequenzen einschleichen. Weniger Releases sollten also weniger Probleme zur Folge haben.

Continuous Delivery setzt hingegen auf häufige Releases. So gehen bei einem Release weniger Änderungen live und die Wahrscheinlich-keit für das Auftreten von Fehlern sinkt. Voraussetzung sind automati-sierte und zuverlässige Prozesse. Sonst führen die häufigen Releases zu einer Überlastung bei jenen, die manuelle Prozesse durchführen, und außerdem steigt das Risiko, da sich in manuelle Prozesse leicht Fehler einschleichen können. Statt einer niedrigen Release-Frequenz werden also Prozesse automatisiert, damit das Risiko eines Release sinkt. Dabei hilft natürlich, dass jedes Release wegen der höheren Release-Frequenz weniger Änderungen umfasst und so inhärent ein niedrigeres Risiko hat.

Die Motivation für Continuous Delivery unterscheidet sich also deutlich von der Lean-Startup-Idee: Es geht um die Zuverlässigkeit und bessere technische Qualität bei den Releases – nicht um Time-to-Market. Und die Nutznießer sind die IT-Abteilungen – nicht die Geschäftsbereiche.

Abb. 2–2Gründe für Continuous

Delivery in einem Enterprise-Umfeld

Risiko-minimierung

Auto-matisierung

Reproduzier-barkeit

Testen vereinfachen

Weniger Code-

änderungen pro Release

Da die Vorteile andere sind, können auch andere Kompromisse einge-gangen werden: Beispielsweise lohnt sich die Investition in eine Conti-nuous-Delivery-Pipeline oft sogar, wenn sie nicht bis in Produktion geht – also die Produktion immer noch manuell aufgebaut werden muss. Schließlich wird für jedes Release die Produktion nur einmal

232.4 Vorteile von Continuous Delivery

aufgebaut, aber es werden mehrere Umgebungen für die verschiedenen Tests benötigt. Ist Time-to-Market der Treiber für Continuous Deli-very, wäre gerade die Produktion entscheidend.

Selber ausprobieren und experimentieren

Betrachte dein aktuelles Projekt:

■ Wo tauchen typischerweise Probleme bei der Installation auf?

■ Könnten die Probleme durch Automatisierung gelöst werden?

■ Wo sollten die aktuellen Ansätze vereinfacht werden, um eine Automa-

tisierung und Optimierung zu ermöglichen? Betrachte den Aufwand und

den Nutzen.

■ Wie werden Produktionssysteme und Testsysteme aktuell aufgebaut?

Durch dasselbe Team? Wäre es denkbar, die Automatisierung auf

beide Bereiche anzuwenden oder nur für einen?

■ Für welche Systeme wäre eine Automatisierung sinnvoll? Wie oft wer-

den die Systeme aufgebaut?

2.4.3 Schnelleres Feedback und Lean

Wenn ein Entwickler eine Änderung am Code vornimmt, bekommt er Feedback durch seine eigenen Tests, Integrationstests, Performance-Tests und schließlich aus der Produktion. Wenn nur einmal im Quartal Änderungen in Produktion gebracht werden, können zwischen der Änderung und dem Feedback aus der Produktion mehrere Monate vergehen. Ähnliches kann für Akzeptanztests oder Performance-Tests gelten. Tritt ein Fehler auf, muss der Entwickler sich überlegen, was er da überhaupt damals implementiert hatte und was das Problem sein könnte.

Bei Continuous Delivery verkürzen sich die Feedback-Zyklen: Jedes Mal, wenn Code die Pipeline durchläuft, bekommen der Ent-wickler und das ganze Team Feedback. Automatisierte Akzeptanztests und automatisierte Kapazitätstests können nach jeder Änderung aus-geführt werden. So können der Entwickler und das Team schnell Prob-leme erkennen und beseitigen. Die Geschwindigkeit des Feedbacks kann weiter erhöht werden, indem schnelle Tests wie Unit-Tests bevor-zugt werden und zunächst in die Breite und dann erst in die Tiefe getes-tet wird. So wird zunächst sichergestellt, dass alle Features mindestens für einfache Fälle funktionieren – den sogenannten »Happy Path«. Grundlegende Fehler lassen sich so einfacher und schneller finden. Ebenso können Tests, die erfahrungsgemäß öfter mal fehlschlagen, am Anfang ausgeführt werden.

2 Continuous Delivery: Was und wie?24

Ebenso entspricht Continuous Delivery dem Lean-Gedanken. Bei Lean wird alles, wofür der Kunde nicht zahlen würde, als Waste ange-sehen. Eine Änderung am Code ist Waste, bis sie in Produktion gebracht worden ist, denn erst dann wird der Kunde für die Änderun-gen zahlen wollen. Außerdem setzt Continuous Delivery auf kürzere Durchlaufzeiten für schnelles Feedback – ein weiteres Lean-Konzept.

Selber ausprobieren und experimentieren

Betrachte dein aktuelles Projekt:

■ Wie viel Zeit vergeht zwischen einer Code-Änderung und• Feedback von einem Continuous Integration Server?• Feedback aus einem Akzeptanztest?• Feedback von einem Performance-/Kapazitätstest?• der Auslieferung in Produktion?

2.5 Aufbau und Struktur einer Continuous-Delivery- Pipeline

Wie schon erwähnt, erweitert Continuous Delivery das Vorgehen von Continuous Integration auf die weiteren Phasen. Einen Überblick über die Phasen bietet Abbildung 2–3.

Abb. 2–3Phasen der Continuous-

Delivery-Pipeline

Commit Produktionexplorative Tests

Akzeptanz-tests

Kapazitäts-tests

Dieser Abschnitt führt die Struktur einer Continuous-Delivery-Umge-bung ein. Sie orientiert sich an Humble et al. [6] und besteht aus den folgenden Phasen:

■ Die Commit-Phase beschreibt jene Aktivitäten, die typischerweise von einer Continuous-Integration-Infrastruktur abgedeckt werden. Dazu zählen der Build-Prozess, Unit-Tests und statische Code-Ana-lyse. Diesen Teil der Pipeline beschreibt Kapitel 4 detailliert.

■ Der nächste Schritt sind Akzeptanztests, die in Kapitel 5 im Mittel-punkt stehen. Genau genommen geht es dabei um automatisierte Tests: Entweder werden die Interaktionen mit der GUI automati-siert, um so das System zu testen, oder die Anforderungen werden in natürlicher Sprache so hinterlegt, dass sie als automatisierte Tests genutzt werden können. Spätestens ab dieser Phase ist es not-wendig, dass Umgebungen aufgebaut werden, auf denen die

252.5 Aufbau und Struktur einer Continuous-Delivery- Pipeline

Anwendungen laufen können. Daher widmet sich das Kapitel 3 der Frage, wie solche Umgebungen aufgebaut werden können.

■ Bei den Kapazitätstests (Kap. 6) wird sichergestellt, dass die Soft-ware die erwartete Last abarbeiten kann. Dazu sollte ein automati-sierter Test dienen, der eindeutig ergibt, ob die Software ausrei-chend leistungsfähig ist oder nicht. Es geht dabei nicht nur um die Performance, sondern auch um die Skalierbarkeit. Der Test kann also auch auf einer Umgebung stattfinden, die nicht der Produkti-onsumgebung entspricht – sie muss allerdings zuverlässige Aussa-gen über das Verhalten in Produktion liefern. Je nach konkretem Einsatzkontext können auch andere nichtfunktionale Anforderun-gen automatisiert getestet werden, wie beispielsweise Sicherheit.

■ Beim explorativen Test (Kap. 7) wird die Anwendung nicht nach einem strikten Testplan auf den Prüfstand gestellt, sondern Domä-nenexperten testen die Anwendung mit einem Fokus auf neue Fea-tures und unvorhergesehenes Verhalten. Es müssen also auch bei Continuous Delivery nicht alle Tests automatisiert werden. Viel-mehr wird durch die automatisierten Tests genügend Luft für das explorative Testen geschaffen, da Routinetests nicht mehr manuell abgearbeitet werden müssen.

■ Die Einführung in die Produktion (Kap. 8) umfasst nur noch die Installation der Anwendung in einer weiteren Umgebung und ist daher recht risikoarm. Es gibt verschiedene Ansätze, um die Risi-ken bei der Einführung in die Produktion weiter zu minimieren.

■ Auch während des Betriebs der Anwendung ergeben sich weitere Herausforderungen – vor allem im Bereich Monitoring und Über-wachung von Log-Dateien. Diesen Herausforderungen widmet sich Kapitel 9.

Grundsätzlich werden Releases in die einzelnen Phasen promotet: Sie durchlaufen die einzelnen Phasen nacheinander. Es ist denkbar, dass ein Release zwar noch in die Akzeptanztestphase kommt und die Tests dort erfolgreich besteht. Bei den Kapazitätstests stellt sich aber heraus, dass die Software den Anforderungen bezüglich des Lastverhaltens nicht gerecht wird. Dann wird das Release nie in die weiteren Phasen wie den explorativen Test oder gar die Produktion promotet. So wer-den zunehmend mehr Anforderungen an die Software erfüllt, bis sie schließlich in Produktion geht.

Nehmen wie beispielsweise an, dass die Software einen fachlichen Fehler enthält. Der würde spätestens beim Akzeptanztest auffallen, denn dort wird die fachliche Funktionalität der Anwendung getestet.

2 Continuous Delivery: Was und wie?26

Also würde die Pipeline abgebrochen – siehe Abbildung 2–4. Weitere Tests sind dann nicht mehr sinnvoll.

Abb. 2–4Pipeline bricht beim

Akzeptanztest ab. Commit Akzeptanz-tests

Die Entwickler beheben diesen Fehler und die Software wird erneut gebaut. Dieses Mal übersteht sie auch den Akzeptanztest. Aber in einer neuen Funktionalität, für die es keinen automatisierten Akzeptanztest gibt, ist ein Fehler. Dieser Fehler kann nur bei den explorativen Tests auffallen. Also bricht die Pipeline diesmal bei den explorativen Tests ab und auch diese Software geht nicht in Produktion – siehe Abbil-dung 2–5. So wird aber auf jeden Fall nicht die Zeit der Tester mit Software verschwendet, die Fehler enthält, die schon automatisierte Tests finden können, oder die den Kapazitätsanforderungen nicht gerecht wird.

Abb. 2–5Pipeline bricht bei den

manuellen Tests ab. Commit Produktionexplorative Tests

Akzeptanz-tests

Kapazitäts-tests

Prinzipiell können mehrere Releases parallel in der Pipeline bearbeitet werden. Dazu ist es natürlich notwendig, dass die Pipeline mehrere Releases parallel zulässt – wenn die Tests jeweils in festen Umgebun-gen laufen, ist das nicht möglich, da die Umgebung dann von einem Test belegt wird und ein paralleler Test eines zweiten Release nicht möglich ist.

Allerdings werden bei Continuous Delivery kaum Releases parallel bearbeitet. Ein Projekt sollte genau einen Stand in der Versionsverwal-tung haben, der jeweils durch die Pipeline promotet wird. Es kann höchstens passieren, dass so schnell Änderungen an der Software vor-genommen werden, dass ein neues Release schon in die Pipeline geschickt wird, bevor das vorherige Release die Pipeline verlassen hat. Vielleicht gibt es noch Ausnahmen für Hotfixes – aber ein Ziel von Continuous Delivery ist gerade, alle Releases gleich zu behandeln.����

Das Beispiel

Im Buch wird eine Beispielanwendung genutzt. Es handelt sich dabei um eine Kundenregistrierung – inspiriert durch das Beispiel der Raffzahn Online Commerce GmbH (siehe Abschnitt 1.2). Fachlich ist dieses Bei-spiel bewusst sehr einfach gehalten. Im Wesentlichen werden von einem Kunden Vorname, Name und E-Mail-Adresse erfasst. Die Registrierungen werden validiert: Die E-Mail-Adresse muss syntaktisch korrekt sein und für eine E-Mail-Adresse ist nur eine Registrierung erlaubt. Außerdem lässt sich eine Registrierung anhand der E-Mail-Adresse suchen und kann schließlich gelöscht werden.

Da die Anwendung nicht sonderlich komplex ist, ist sie auch recht leicht zu verstehen, so dass sich der Leser auf die verschiedenen Aspekte von Continuous Delivery konzentrieren kann, die mit der Anwendung verdeut-licht werden.

Technisch ist die Anwendung mit Java und dem Framework Spring Boot [5] implementiert. Dadurch ist es möglich, die Anwendung einschließ-lich Weboberfläche ohne Installation eines Web- oder Application-Servers zu starten. Das macht gerade das Testen einfacher, da keine Infrastruktur installiert werden muss. Die Anwendung kann aber auch in einem Applica-tion- oder Webserver wie Apache Tomcat betrieben werden, wenn das notwendig sein soll. Die Daten werden in HSQLDB abgelegt. Das ist eine In-Memory-Datenbank, die innerhalb des Java-Prozesses läuft. Auch diese Maßnahme reduziert die technische Komplexität der Anwendung.

Der Quellcode des Beispiels kann unter http://github.com/ewolff/user-registration heruntergeladen werden. Ein wichtiger Hinweis: Der Beispiel-code enthält Dienste, die unter root-Rechten laufen und auf die durch das Netz zugegriffen werden kann. Das ist für Produktionsumgebungen wegen der sich daraus ergebenden Sicherheitsprobleme nicht tragbar. Allerdings soll der Beispielcode auch nur zum Experimentieren dienen. Dafür ist der einfache Aufbau der Beispiele nützlich.

272.5 Aufbau und Struktur einer Continuous-Delivery- Pipeline

2 Continuous Delivery: Was und wie?28

2.6 Links & Literatur[1] Eric Ries: The Lean Startup: How Today's Entrepreneurs Use Continuous

Innovation to Create Radically Successful Businesses, Crown Business, 2011, ISBN 978-0-67092-160-7

[2] David J. Anderson: Kanban: Evolutionäres Change Management für IT-Organisationen, dpunkt.verlag, 2011, ISBN 978-3-89864-730-4

[3] http://de.wikipedia.org/wiki/5-Why-Methode

[4] http://www.sec.gov/litigation/admin/2013/34-70694.pdf

[5] http://www.kitchensoap.com/2013/10/29/counterfactuals-knight-capital/

[6] Jez Humble, David Farley: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010, ISBN 978-0-32160-191-9

[7] http://martinfowler.com/bliki/ContinuousDelivery.html

[8] http://en.wikipedia.org/wiki/Continuous_delivery