JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile

On the Road to Continuous Delivery

X

Fußball Weltmeister dank Big Data?

Ihr Fahrplan für Releases am laufenden Band

On the Road to Continuous Delivery

Thorsten Kamann und Hanno Wendt

"How long would it take your organization to deploy a change that involves just one single line of code?" Kennen Sie dieses Zitat von Mary und Tom Poppendieck aus dem Jahr 2003? Wenn Sie sich diese Frage, die das Konzept der Continuous Delivery auf den Punkt bringt, in Bezug auf Ihr Projekt stellen - wie lautet dann Ihre Antwort? "Eine Woche", "ein Monat", "drei Monate" oder gar "ein halbes Jahr"? In diesem zweiteiligen Beitrag zeigen wir Ihnen, was zu tun ist, um eine zufriedenstellende Antwort auf diese Frage geben zu können.

Bei der Continuous Delivery dreht sich der gesamte Prozess der Produktion und Inbetriebnahme von Software um die oben zitierte Frage der Poppendiecks [1]. Software soll so produziert werden, dass kontinuierlich neue Funktionen erfolgreich in Betrieb genommen werden, um so schnell wie möglich genutzt werden zu können. Den Entwicklern gibt das ein schnelles Feedback. Außerdem ändern sich Anforderungen schnell, und wer flexibler darauf reagieren und die Wünsche des Kunden zügig erfüllen kann, hat die Nase vorn. Anstatt die entwickelten Features einer Software zu sammeln und in einer großangelegten Aktion - dem gefürchteten Release-Tag - mit ungewissem Erfolg zu veröffentlichen, wird bei Continuous Delivery nach der Fertigstellung eines Features dieses sofort im Rahmen der fortlaufenden Auslieferung genutzt. Auch qualitativ kann Ihr Projekt durch Continuous Delivery gewinnen. Häufige Releases mit kleinen Änderungen bergen weniger die Gefahr, schwere Fehler unbemerkt in das System zu bringen. Es gibt natürlich Typen von Software, die einfacher auszuliefern und zu verteilen sind als andere. Arbeiten Sie an einer Webanwendung, reicht es, den Server zu aktualisieren. Bei einer Desktopanwendung müssen Sie da schon mehr Aufwand investieren. Dieser hält sich allerdings in Grenzen, da moderne Anwendungen meistens einen Mechanismus haben, mit dem sie sich selbst aktualisieren können. Continuous Delivery kann auch bei Einschränkungen funktionieren. In größeren Unternehmen ist eine automatische Auslieferung aus organisatorischen oder sogar rechtlichen Gründen nicht realisierbar. In solchen Fällen ist es aber kein Problem, Continuous Delivery etwas kleiner zu fassen und beispielsweise Qualitätssicherung als Endstation zu definieren.

Automatisierung als Schlüssel zum Erfolg

Wenn Sie häufig releasen, geht das nicht mehr manuell. Manuelle Releases sind ein Anti-Pattern, das fatale Auswirkungen haben kann. Im schlimmsten Fall endet dies in einem Produktionsausfall. Aber auch schon ein kleinerer Fehler kostet extrem viel Geld und Zeit, da der Vorgang entweder wiederholt oder aber durch weitere, nicht geplante Maßnahmen ergänzt werden muss. Die Automatisierung bietet hier einen guten Ausweg. Ein einmal etablierter automatisierter Prozess funktioniert immer und ist wiederholbar. Nicht nur das Deployment sollte automatisiert werden, auch alle anderen notwendigen Schritte auf dem Weg zum Release sind einzubeziehen. Dabei muss man sich aber auch darüber im Klaren sein, dass es nicht immer möglich und sinnvoll ist, eine hundertprozentige Automatisierung umzusetzen. Auch manuelle Schritte sind erlaubt.

Agile Verwandtschaft

Die Idee zu diesem Vorgehen tauchte zum ersten Mal 1999 in Kent Becks "Extreme Programming" [2] auf. Auch in den Prinzipien des Agilen Manifests von 2001 [3] ist sie an erster Stelle zu finden: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." An der Herkunft der Idee können wir ihre Nähe zu agilen Methoden sehen. Daher verwundert es auch nicht weiter, dass die Konzepte in der Praxis hervorragend zusammenpassen. Die gute Nachricht für alle, die es gern etwas weniger agil mögen: Continuous Delivery verträgt sich auch prima mit konventionellen Projekten und kann auch hier die Geschwindigkeit und Flexibilität erhöhen, mit der Features in Betrieb genommen werden.

In der Praxis

Das Delivery-Team und seine Aufgaben: Es gibt ein einziges Projektteam, in dem Mitarbeiter aus verschiedenen Bereichen wie Entwicklung, Test und Betrieb versammelt sind, die in konventionellen Projekten getrennt arbeiten. Sie bilden das Delivery-Team und sind gemeinsam dafür verantwortlich, ein Feature von der Anforderung über die Entwicklung und den Test in den Betrieb zu bringen. Das Delivery-Team funktioniert nach dem DevOps-Konzept [4]: Alle arbeiten während der gesamten Projektdurchführung eng zusammen, um sicherzustellen, dass die Inbetriebnahme neuer Features ein stabiler und zuverlässiger Prozess ist.

Die Commit-Strategie: Die kontinuierliche Entwicklung soll durch die Arbeit aller auf der Hauptentwicklungslinie und durch häufige Commits sichergestellt werden. Branches über einen längeren Zeitraum würden gegen das Prinzip der frühen Integration verstoßen. Für umfangreichere Aufgaben kann auf Techniken wie Feature-Toggles [5] oder Branch by Abstraction [6] zurückgegriffen werden. So ist der Code des zu entwickelnden Features ständig integriert, aber die Funktion ist noch inaktiv. Entwickler dürfen am Ende des Arbeitstages keine fehlerhaften Commits hinterlassen. Letztere müssen generell sofort in Ordnung gebracht oder zurückgenommen werden. Das gesamte Team versucht das Problem zu lösen, bevor weitere Commits folgen.

Tests: Der Erfolg der Entwicklung steht und fällt mit den Tests. Nur wenn für die Codebasis eine gute Abdeckung mit Unit und Integrationstests gegeben ist, kann man die Kontrolle darüber bewahren, ob sich neuer Code ohne Regression (ungewollte Auswirkungen auf bestehende Funktionalität) integrieren lässt.

Releases: Frühe Integration, Arbeiten auf der Hauptentwicklungslinie und eine hohe Testabdeckung haben ein Ziel. Jeder Build soll funktionierende und getestete Software ausliefern. Potenziell ist jeder Build ein Release Candidate. Kandidaten durchlaufen nach ihrer Fertigstellung das Staging auf produktionsnahen Umgebungen, wo sie automatisiert und manuell intensiv getestet werden. Bestellt die Fachabteilung ein Release, soll die angeforderte Version per Knopfdruck automatisch installiert werden können.

Werkzeuge: In der Continuous Delivery spielen zahlreiche Werkzeuge im Konzert. Sie müssen das jeweilige Problem lösen können und vom Delivery-Team gut verwendbar sein. Die Erfahrungen und Fähigkeiten des Teams sind also bei der Auswahl sehr wichtig.

Roadmap: Von Stages, Clustern und Jobs

Der konkrete Fahrplan zur Einführung ist genauso wichtig wie die Inhalte der Continuous Delivery. Zu berücksichtigen sind die aktuelle Situation und die bestehende Infrastruktur: Gibt es bereits automatisierte Schritte? Welche Anforderungen gibt es an den Delivery-Prozess? Für die Einführung der Continuous Delivery stellen wir eine Roadmap auf, die Sie in Ihrem Projekt sicher ans Ziel bringt. In Abbildung 1 sehen Sie die Schritte der Roadmap in einer Übersicht. Es gibt zwei Arten von Einträgen: Stages (blau) und Cluster (gelb). Stages sind die typischen Entwicklungsphasen. Zu jeder Stage gibt es mehrere Cluster. Letzterer gruppiert eine Menge zusammengehöriger Jobs - auf die kommen wir später noch zu sprechen. Die Cluster sind sequentiell geordnet. Es ist also wenig sinnvoll, mit Unit Tests zu beginnen, wenn Ihre Software noch nicht automatisch gebaut werden kann.



Abb. 1: Vereinfachte Roadmap
Wo bin ich? Wo will ich hin?

Um einen sinnvollen Weg einschlagen zu können, muss zunächst die Position bestimmt werden. Daher sollte man kurz innehalten und in Ruhe analysieren, wo in dieser Roadmap das eigene Projekt aktuell steht und wohin die Reise gehen soll. Mit den gewonnenen Koordinaten können die nächsten Schritte ermittelt werden. Dazu gibt es für jede Stage und jedes Cluster einige Fragen, die in die auszuführenden Jobs münden. Diese Fragen führen Sie in Ihrem individuellen Zeitplan durch alle Stages. Die Roadmap ist so angelegt, dass eine stufenweise Umstrukturierung des bestehenden Prozesses, basierend auf dem aktuellen Stand der Projektinfrastruktur, möglich ist. Jeder Schritt entlang dieser Roadmap stellt einen eigenständigen, wertvollen Baustein bei der Verbesserung Ihres Delivery-Prozesses dar. Sobald Sie ein Cluster oder eine Stage vollendet haben, profitieren Sie auch von den Synergien der einzelnen Jobs. Um nun festzustellen, wie weit Sie mit Ihrem Projekt sind, sollten Sie diese Fragen beantworten:

  • Gibt es schon automatisierte Build-Skripte?
  • Funktionieren diese zuverlässig?
  • Gibt es einen zentralen Build-Server?
  • Gibt es Unit Tests?
  • Sind diese ausreichend oder muss Aufwand in eine Verbesserung gesteckt werden?
  • Gibt es Integrationstests?
  • Wo werden die Artefakte (erzeugte Bibliotheken, Archive, Installer, Dokumente, Skripte) abgelegt?
  • Wie funktioniert die Qualitätssicherung? Was benötigt diese, um schnell und effektiv arbeiten zu können?
  • Wie kann die Software automatisiert auf die Zielinfrastruktur installiert werden?

Diese Fragen adressieren völlig unterschiedliche Rollen. Es reicht also nicht, nur mit dem Teamleiter und ein paar Entwicklern zu sprechen. Sie brauchen alle Rollen, die irgendwie mit dem Projekt zu tun haben und müssen also auch die Qualitätssicherung und den Betrieb einbeziehen. Wenn Sie sich bereits mit dem Thema Agilität beschäftigt haben, wird Ihnen dabei der Begriff Cross-Cutting Teams einfallen. Es geht darum, ein Team so autonom zu machen, dass es alle Aufgaben selbständig erledigen kann, die für die Realisierung eines Projekts notwendig sind. Für solche Teams hat sich der Begriff DevOps herausgebildet, der die enge Verzahnung zwischen Development und Operation bezeichnet - also die Zusammenarbeit von Entwicklung und Betrieb.

Gleich zu Beginn den Betrieb mit ins Boot zu holen, vereinfacht das Thema Deployment ungemein, da dort viel Wissen über die bestehende Infrastruktur vorhanden ist. Für viele Dinge gibt es Skripte, und es ist schnell möglich, gemeinsam ein automatisiertes Deployment auf die Beine zu stellen. Manchmal ist es unmöglich, Continuous Delivery in seiner Reinform zu realisieren, da es organisatorische oder auch rechtliche Hemmnisse gibt. In diesem Fall entscheidet man sich, die Software bis zu einem anderen Cluster automatisiert auszuliefern, z. B. bis zum Staging QA. Auch solche Einschränkungen können Sie bei einer frühen Beteiligung des Betriebs rechtzeitig feststellen.
Nach der Bestimmung von Position und Ziel können Sie in der Roadmap die notwendigen Schritte ablesen. Diese ergeben sich aus den Clustern und den darin enthaltenen Jobs, die zwischen diesen beiden Markierungen liegen.

 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).