Eine Einführung in Continuous Delivery, Teil 4: Bereitstellen der Infrastruktur

Inhaltsverzeichnis

Eine Continuous Delivery Pipeline soll stetig Feedback über den Qualitätsstand der Software liefern. Das automatische Bereitstellen der zugehörigen Testinfrastruktur wird dabei Pflicht und beeinflusst den Aufbau der Pipeline.

In den beiden vorangegangenen Artikeln wurde der konkrete Aufbau der zwei wichtigsten Teststufen einer Continuous Delivery Pipeline beschrieben. In der Commit Stage kompiliert der Build-Server den aktuellen Softwarestand und führt die Unit-Tests aus. War diese Teststufe erfolgreich, startet man im Anschluss die Acceptance Test Stage, in der mit unterschiedlichen Testtypen die funktionalen und nichtfunktionalen Anforderungen an die Software überprüft werden. Um kurze Durchlaufzeiten durch
die Pipeline und damit schnelles Feedback für die Entwickler zu gewährleisten, führt man die unterschiedlichen Testtypen in der letzten Phase parallel aus.

Mehr Infos

Eine Einführung in Continuous Delivery

• Teil 1: Grundlagen
• Teil 2: Commit Stage
• Teil 3: Acceptance Test Stage
• Teil 4: Bereitstellen der Infrastruktur
  

Um außerdem die von den Tests entdeckten Regressionen möglichst einfach und exakt einer einzigen Änderung an der Software zuordnen zu können, startet das System für jede einzelne dieser Änderungen einen Lauf durch die Pipeline.

Damit ergeben sich hohe Anforderungen an die Skalierung der Testausführung. Sowohl die notwendige Parallelisierung der unterschiedlichen Testtypen auf der einen als auch die Ausführung der Pipeline für jede Änderung auf der anderen Seite machen dabei die Verfügbarkeit einer Vielzahl von Testumgebungen nötig. Führt man in der Acceptance Test Stage beispielsweise Integrations-, API- und Performancetests parallel aus und möchte die Änderungen von drei Commits parallel durch die Pipeline laufen lassen, benötigt man in diesem einfachen Beispiel allein neun (3 x 3) Testumgebungen. In realen Projekten kommen hier schnell Umgebungen im mittleren zweistelligen Bereich zusammen.

Die Testumgebungen unterliegen hohen Anforderungen an ihre Qualität: Sie müssen sich in einem einheitlichen, genau definierten Zustand befinden, damit die darauf durchgeführten Testläufe zuverlässiges Feedback über die Qualität der Software und nicht über die Qualität der Testumgebung liefern. Ist beispielsweise auf einigen der Testumgebungen versehentlich eine zu alte Java-Version installiert, kann es dazu führen, dass einige der Tests genau dort immer wieder fehlschlagen, wohingegen sie auf allen übrigen Testumgebungen erfolgreich sind.

Fehlschläge in Tests sind in dem Fall also nicht auf die Software zurückzuführen, sondern entstehen aus Fehlern in Testumgebungen. Diese False Negatives zerstören innerhalb kürzester Zeit das Vertrauen der Entwickler in das Feedback aus der Pipeline. Sie führen erfahrungsgemäß schon nach kurzer Zeit dazu, dass Testfehlschläge überhaupt keine wirkliche Beachtung mehr finden, da man im Zweifel einen Fehler der Testumgebung vermutet.

Will man diesem Umstand begegnen, sind alle Testumgebungen mit einer genau definierten Anleitung auf immer die gleiche Weise herzustellen. Damit kann man garantieren, dass sie sich immer im gewünschten Zustand befinden.

Könnte man an der Stelle noch für eine schriftliche Schritt-für-Schritt-Anleitung auf einer Wiki-Seite plädieren, kommen in der Realität aber schnell weitere Anforderungen hinzu: Was, wenn das Team gerne drei weitere Testumgebungen für die Demo eines Prototypen hätte? Oder wenn die Warteschlange auf dem Build-Server so lang ist, dass spontan fünf weitere Testumgebungen gut wären? Und wie begegnet man der Tatsache, dass Menschen beim Abarbeiten einer schrittweisen Anleitung immer wieder Flüchtigkeitsfehler unterlaufen?

Spätestens hier wird klar, dass an einer konsequenten Automatisierung für das Erstellen der Infrastruktur kein Weg vorbeigeht. Nur wenn man die Anleitung zum Aufsetzen der Testumgebungen konsequent unter Versionskontrolle stellt und sie vollständig automatisiert ausführt, lassen sich neue Testumgebungen in der benötigten Qualität in kurzer Zeit zur Verfügung stellen.

Den Dreisprung meistern

Das Bereitstellen einer Testumgebung geschieht in der Regel auf Basis virtueller Maschinen. Bis eine solche in der Lage ist, Tests für eine Continuous Delivery Pipeline auszuführen, ist eine Vielzahl von Komponenten einzurichten und zu konfigurieren: Auf der virtuellen Maschine müssen Anwender zuerst das Betriebssystem installieren und einrichten. Im Anschluss lassen sich die benötigten Middleware-Komponenten wie Webserver, Applikationscontainer, Datenbank oder Ähnliches installieren und konfigurieren. Nachdem das geschehen ist, kann dann die eigentlich zu testende Anwendung installiert und ebenfalls konfiguriert werden. Erst danach steht die Umgebung für das Ausführen von Tests aus der Continuous Delivery Pipeline bereit.

Für die drei Bereiche Betriebssystem, Middleware und Anwendung, die bei der Bereitstellung einer Testumgebung für die Verwendung in der Pipeline eine Rolle spielen, gelten ganz unterschiedliche Zyklen. Die Installation und Konfiguration des Betriebssystems geschieht lediglich einmalig im Lebenszyklus einer solchen Umgebung. Die Installation und Konfiguration von Middleware-Komponenten hingegen kann durch geänderte Anforderungen von Seiten der Anwendung durchaus mehrmals am Tag passieren, während die Installation des aktuellen Standes der Anwendung vor jedem Start der Tests von Neuem nötig ist. Folglich sind in den drei unterschiedlichen Bereichen unterschiedliche Werkzeuge zur Bewältigung der entsprechenden Aufgabe entstanden.