Continuous Delivery (eBook)

Der pragmatische Einstieg

Eberhard Wolff (Autor)

eBook Download: PDF | EPUB

2016 | 2. Auflage
282 Seiten
dpunkt (Verlag)
978-3-86491-931-2 (ISBN)

Infos

Continuous Delivery ermöglicht es, Software viel schneller und mit wesentlich höherer Zuverlässigkeit in Produktion zu bringen, als es bisher möglich war. Grundlage dafür ist eine Continuous-Delivery-Pipeline, die das Ausrollen der Software weitgehend automatisiert und so einen reproduzierbaren, risikoarmen Prozess für die Bereitstellung neuer Releases bietet. Dieses Buch macht Sie mit dem Aufbau einer Continuous-Delivery-Pipeline vertraut und erklärt, welche Technologien Sie dazu einsetzen können. Dabei lernen Sie u.a. folgende Themen kennen: • Infrastruktur-Automatisierung mit Chef, Docker und Vagrant • Automatisierung von Builds und Continuous Integration • Akzeptanztests, Kapazitätstests, exploratives Testen • Einführung von Continuous Delivery im Unternehmen • Continuous Delivery und DevOps • Auswirkungen auf die Softwarearchitektur Als praktisches Beispiel wird ein konkreter Technologie- Stack vorgestellt. Zahlreiche Aufgaben und Vorschläge für weitergehende Experimente laden Sie darüber hinaus zur praktischen Vertiefung des Themas ein. Nach der Lektüre können Sie abschätzen, welche Vorteile Continuous Delivery konkret bietet, und Sie verfügen über das nötige Handwerkszeug, um Continuous Delivery in Ihrem eigenen Arbeitsumfeld zu etablieren. Die Neuauflage wurde in Bezug auf Werkzeuge wie Docker, Jenkins, Graphite und den ELK-Stack aktualisiert. An neuen Themen sind Docker Compose, Docker Machine, Immutable Server, Microservices und die Einführung von Continuous Delivery ohne DevOps hinzugekommen.

Eberhard Wolff beschäftigt sich seit vielen Jahren mit Softwareentwicklung und -architektur. Er ist Autor zahlreicher Fachartikel sowie Bücher und regelmäßiger Sprecher auf internationalen Konferenzen. Außerdem ist er im Programmkomitee verschiedener Konferenzen vertreten. Er ist Fellow bei der innoQ. Continuous Delivery und die Auswirkungen hat er in verschiedenen Projekten in unterschiedlichen Rollen kennen gelernt. Der Ansatz verspricht, die Produktivität der IT-Projekte erheblich zu erhöhen, und hat Auswirkungen auf das Vorgehen, aber auch auf die Architektur und die Technologien. Daher lag es für ihn auf der Hand, dieses Buch zu schreiben.

Inhalt

Inhaltsverzeichnis 5
1 Einleitung 11
1.1 Überblick über Continuous Delivery und das Buch 11
1.2 Warum überhaupt Continuous Delivery? 12
1.3 Für wen ist das Buch? 15
1.4 Neu in der 2. Auflage 15
1.5 Übersicht über die Kapitel 17
1.6 Pfade durch das Buch 18
1.7 Danksagung 20
2 Continuous Delivery: Was und wie? 23
2.1 Was ist Continuous Delivery? 23
2.2 Warum Software-Releases so kompliziert sind 23
2.3 Werte von Continuous Delivery 24
2.4 Vorteile von Continuous Delivery 27
2.4.1 Continuous Delivery für Time-to-Market 27
2.4.2 Continuous Delivery zur Risikominimierung 30
2.4.3 Schnelleres Feedback und Lean 33
2.5 Aufbau und Struktur einer Continuous-Delivery- Pipeline 34
2.6 Links & Literatur
3 Infrastruktur bereitstellen 39
3.1 Einleitung 39
3.2 Installationsskripte 41
3.3 Chef 44
3.3.1 Technische Grundlagen 47
3.3.2 Chef Solo 54
3.3.3 Chef Solo: Fazit 56
3.3.4 Knife und Chef Server 56
3.3.5 Chef Server: Fazit 61
3.4 Vagrant 61
3.4.1 Ein Beispiel mit Chef und Vagrant 63
3.4.2 Vagrant: Fazit 65
3.5 Docker 65
3.5.1 Dockers Lösung 66
3.5.2 Docker-Container erstellen 69
3.5.3 Beispielanwendung mit Docker betreiben 71
3.5.4 Docker und Vagrant 73
3.5.5 Docker Machine 76
3.5.6 Komplexe Konfigurationen mit Docker 78
3.5.7 Docker Compose 80
3.6 Immutable Server 83
3.7 Infrastructure as Code 84
3.8 Platform as a Service (PaaS) 87
3.9 Umgang mit Daten und Datenbanken 89
3.10 Fazit 92
3.11 Links & Literatur
4 Build-Automatisierung und Continuous Integration 97
4.1 Überblick 97
4.2 Build-Automatisierung und Build-Tools 98
4.2.1 Ant 100
4.2.2 Maven 100
4.2.3 Gradle 105
4.2.4 Weitere Build-Tools 108
4.2.5 Das geeignete Tool auswählen 109
4.2.6 Links und Literatur 110
4.2.7 Experimente und selber ausprobieren 110
4.3 Unit-Tests 111
4.3.1 »Gute« Unit-Tests schreiben 113
4.3.2 TDD – Test-driven Development 115
4.3.3 Clean Code und Software Craftsmanship 116
4.3.4 Links und Literatur 116
4.3.5 Experimente und selber ausprobieren 117
4.4 Continuous Integration 117
4.4.1 Jenkins 118
4.4.2 Continuous-Integration-Infrastruktur 124
4.4.3 Fazit 125
4.4.4 Links und Literatur 126
4.4.5 Experimente und selber ausprobieren 126
4.5 Codequalität messen 128
4.5.1 SonarQube 130
4.5.2 Links und Literatur 132
4.5.3 Experimente und selber ausprobieren 132
4.6 Artefakte managen 133
4.6.1 Integration in den Build 135
4.6.2 Weiterreichende Funktionen von Repositories 137
4.6.3 Links und Literatur 137
4.6.4 Experimente und selber ausprobieren 137
4.7 Fazit 138
5 Akzeptanztests 141
5.1 Einführung 141
5.2 Die Test-Pyramide 141
5.3 Was sind Akzeptanztests? 145
5.4 GUI-basierte Akzeptanztests 149
5.5 Alternative Werkzeuge für GUI-Tests 155
5.6 Textuelle Akzeptanztests 157
5.7 Alternative Frameworks 160
5.8 Strategien für Akzeptanztests 162
5.9 Fazit 164
5.10 Links & Literatur
6 Kapazitätstests 167
6.1 Einführung 167
6.2 Kapazitätstests – wie? 168
6.3 Kapazitätstests implementieren 173
6.4 Kapazitätstests mit Gatling 174
6.5 Alternativen zu Gatling 179
6.6 Fazit 181
6.7 Links & Literatur
7 Exploratives Testen 183
7.1 Einleitung 183
7.2 Warum explorative Tests? 183
7.3 Wie vorgehen? 185
7.4 Fazit 189
7.5 Links & Literatur
8 Deploy – der Rollout in Produktion 191
8.1 Einleitung 191
8.2 Rollout und Rollback 192
8.3 Roll Forward 193
8.4 Blue/Green Deployment 195
8.5 Canary Releasing 196
8.6 Continuous Deployment 198
8.7 Virtualisierung 200
8.8 Jenseits der Webanwendungen 202
8.9 Fazit 203
8.10 Links und Literatur 204
9 Operate – Produktionsbetrieb der Anwendungen 205
9.1 Einleitung 205
9.2 Herausforderungen im Betrieb 206
9.3 Log-Dateien 208
9.3.1 Werkzeuge zum Verarbeiten von Log-Dateien 210
9.3.2 Logging in der Beispielanwendung 212
9.4 Logs der Beispielanwendung analysieren 213
9.4.1 Experimente und selber ausprobieren 218
9.5 Andere Technologien für Logs 221
9.6 Fortgeschrittene Log-Techniken 222
9.7 Monitoring 223
9.8 Metriken mit Graphite 224
9.9 Metriken in der Beispielanwendung 226
9.9.1 Experimente und selber ausprobieren 227
9.10 Andere Monitoring-Lösungen 229
9.11 Weitere Herausforderungen beim Betrieb der Anwendung 230
9.12 Fazit 231
9.13 Links & Literatur
10 Continuous Delivery im Unternehmen einführen 235
10.1 Einleitung 235
10.2 Continuous Delivery von Anfang an 235
10.3 Value Stream Mapping 236
10.4 Weitere Optimierungsmaßnahmen 239
10.5 Zusammenfassung 243
10.6 Links & Literatur
11 Continuous Delivery und DevOps 245
11.1 Einführung 245
11.2 Was ist DevOps? 245
11.3 Continuous Delivery und DevOps 249
11.4 Continuous Delivery ohne DevOps? 253
11.5 Fazit 255
11.6 Links & Literatur
12 Continuous Delivery, DevOps und Softwarearchitektur 257
12.1 Einleitung 257
12.2 Softwarearchitektur 257
12.3 Komponentenaufteilung für Continuous Delivery optimieren 260
12.4 Schnittstellen 262
12.5 Datenbanken 265
12.6 Microservices 268
12.7 Umgang mit neuen Features 271
12.8 Fazit 274
12.9 Links & Literatur
13 Fazit: Was bringt’s? 277
13.1 Links & Literatur
Index 279
www.dpunkt.de 0

Textauszug

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 bisher. Grundlage dafür ist eine Continuous-Delivery-Pipeline, die das Ausrollen der Software weitgehend automatisiert und so einen reproduzierbaren, 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 continuous 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 kontinuierliche 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önnen. 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 Delivery 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 Erfahrungen sammeln kann. Das Buch bietet einen Einstieg in den Technologie-Stack und zeigt außerdem auf, wie man sich mit den Themen tiefergehend beschäftigen kann.

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

Unter http://continuous-delivery-buch.de steht die Website zum Buch bereit mit Informationen, Errata und Links zu dem Beispiel.

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 Registrierungsprozess 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 aufwendigen Prozess eine Testumgebung aufgebaut, auf der die Software manuell getestet wurde. Und es wurden tatsächlich Fehler gefunden. Mittlerweile 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 einigen »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 komplex. 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 System am nächsten Morgen nicht zur Verfügung stand. Zu diesem Zeitpunkt waren die Mitarbeiter übernächtigt und standen unter großem Stress – jede Minute Ausfall kostete bares Geld. Und zurück zur alten 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 Testumgebung vorgenommen, aber bei der Produktionseinführung vergessen 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 eigentlich 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 Informationen über die Nutzung der Website. Wie schnell die optimierte Registrierung 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ächsten 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 Features und Code-Änderungen schneller. Die Entwickler müssen sich nicht erst wieder darauf besinnen, was sie vor einem Monat implementiert haben.

• 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 Testumgebung erfolgreich aufgebaut werden kann, dann lässt sich mit demselben Automatismus auch die Produktion aufbauen – und zwar mit derselben Konfiguration. Das Problem durch die Fehlkonfiguration der Produktionsumgebung wäre also nicht aufgetreten.

• Außerdem führt die Automatisierung zu mehr Flexibilität. Testumgebungen 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 Lasttests 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 ausgeführt werden, gibt es auch keine Fehler bei der Testdurchführung.

• Wenn Tests automatisiert sind, können sie öfter ausgeführt werden. 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 Verfügbarkeit neuer Features und eine zuverlässigere IT. Die Zuverlässigkeit 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.

Um Continuous...

Produkt-Details

• Erscheint lt. Verlag: 31.3.2016
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Naturwissenschaften ► Physik / Astronomie ► Astronomie / Astrophysik
• Themenwelt: Technik
• Schlagworte: Ansible • Aplication Lifecycle Management • build • Chef • Configuration Management • Continuous Integration • Deployment • DevOps • Docker • Git • Gradle • Konfigurationsmanagement • Test • Testen • Vagrant • Versionsmanagement
• ISBN-10: 3-86491-931-2 / 3864919312
• ISBN-13: 978-3-86491-931-2 / 9783864919312