Eine Einführung in Continuous Delivery, Teil 1: Grundlagen

Inhaltsverzeichnis

Continuous Delivery verspricht Produktivsetzungen der entwickelten Software auf Knopfdruck bei besserer Qualität. Was sind die zentralen Ideen dahinter und welche Voraussetzungen muss man schaffen, um damit erfolgreich zu sein? In einer mehrteiligen Artikelserie sollen zusätzlich zu Hintergrundinformationen ganz konkrete Schritte auf dem Weg zu einer Continuous Delivery Pipeline beschrieben werden.

Softwareentwicklung nach einem klassischen Phasenmodell sieht die drei Schritte Entwicklung, Qualitätssicherung und Auslieferung üblicherweise nur einmal für jedes Release vor: Nach Abschluss einer monatelangen Entwicklungsphase werden die für das nächste Release vorgesehenen Änderungen der Software an die Qualitätssicherung übergeben. In der anschließenden Testphase untersucht man diese dort auf die Erfüllung der Anforderungen hin und bessert bei Abweichungen nach. Danach lässt sich der Softwarestand auf dem Produktionssystem installieren.

In den letzten Jahren sind viele Unternehmen zu einem inkrementell-iterativen Vorgehen übergegangen, bei dem auch Zwischenstände der entwickelten Software schon qualitätsgesichert und an den Kunden ausgeliefert werden. Die Kette aus Entwicklung, Qualitätssicherung und Lieferung wird also bereits mehrfach im Entwicklungsprozess der Software durchlaufen.

Was aber, wenn die Software mit agilen Methoden entwickelt wird, bei denen eine Lieferung lauffähiger Software im Rhythmus von nur wenigen Wochen zum Fundament der Methode gehört? Ein manueller Test des gesamten Funktionsumfangs alle zwei Wochen und eine anschließende Lieferung werden hier schnell zum Showstopper: Testumgebungen stehen nicht in genügender Anzahl zur Verfügung, die Installation der Software ist vom Betriebsteam durchzuführen, die Konfiguration der Anwendung auf der Testumgebung passt nicht und erfordert mühsame Abstimmungen zwischen Entwicklung und Betriebsteam. Erst danach kann das eigentliche Testen beginnen. Wie passt das in einen Zeitrahmen von nur zwei Wochen?

Continuous Delivery versucht, genau diese Probleme durch radikale Automatisierung zu beheben. Die Schritte Entwicklung, Qualitätssicherung und Auslieferung der Software werden in viel kleineren Einheiten abgebildet: Bei Änderungen oder Erweiterungen an der Software wird dieser Softwarestand direkt im Anschluss automatisiert getestet. Die Tests liefern schnelles Feedback über Seiteneffekte und Regressionen. Sind sie erfolgreich, lässt sich der Softwarestand auf Knopfdruck und innerhalb von Minuten auf dem Produktionssystem installieren. Die Kette aus Entwicklung, Qualitätssicherung und Produktivsetzung erfolgt kontinuierlich mit jeder Änderung an der Software und führt zu einer automatisierten Pipeline: Auf der einen Seite kommt jeweils ein neuer Softwarestand hinein, auf der anderen ein qualitätsgesichertes, produktionsreifes und installierbares Softwarepaket heraus.

Erste Ideen, den Software-Entwicklungsprozess in diese Richtung zu verändern, haben Jez Humble, Chris Read und Dan North bereits auf der Agile 2006 in einem Vortrag vorgestellt, die bisher ausführlichste Auseinandersetzung mit dem Thema findet sich im 2010 erschienen Buch "Continuous Delivery" von Humble und David Farley.

In der Continuous Delivery Pipeline wird die Qualitätssicherung durch eine Kombination von automatischen und manuellen Tests oder Freigabeschritten realisiert. Man versucht, sowohl funktionale als auch nichtfunktionale Anforderungen durch unterschiedliche Testtypen mit hohem Automatisierungsgrad zu validieren:

• Unit-Tests prüfen einzelne Komponenten isoliert in ihren Funktionen.
• Akzeptanztests sorgen für das Einhalten der mit den Anforderungen formulierten Akzeptanzkriterien.
• Performancetests oder statische Codeanalyse überprüfen nichtfunktionale Anforderungen.

Die Tests werden in mehreren Stufen organisiert und diese nacheinander für jeden Softwarestand ausgeführt. Nur wenn die eine Teststufe erfolgreich war, starten die Tests der nächsten Stufe überhaupt. Der Ablauf folgt hier dem als "Stop the Line" bekannten Prinzip des Lean Manufacturing. Je weiter es ein Softwarestand erfolgreich durch die Pipeline geschafft hat, desto mehr kann man darauf vertrauen, dass die Änderung keine Regressionen erzeugt hat und die Software nach wie vor die Anforderungen erfüllt.