Seite 2: Test Stages

Inhaltsverzeichnis

Stufenweise heranführen

Die erste Teststufe in der Continuous Delivery Pipeline ist die sogenannte Commit Stage, die das Versionskontrollsystem direkt durch die Änderung der Software ausgelöst hat. Hier werden die Komponenten der Software gebaut und die jeweiligen Unit-Tests ausgeführt. War diese Teststufe erfolgreich, kommt es in der zweiten Teststufe, der sogenannten Acceptance Test Stage, zur Ausführung der Integrations-, Akzeptanz- und Systemtests. Im Anschluss an diese Phase können dann zusätzliche manuelle Tests oder Freigabeschritte angebunden sein.

Auf dem Weg durch die Commit und Acceptance Test Stage werden die Ergebnisse der automatisierten Tests kontinuierlich als Feedback an die beteiligten Entwickler zurückgemeldet. Das kann in Form von E-Mails, Instant Messages oder "Extreme Feedback Devices" geschehen. Das erste Feedback aus der Pipeline signalisiert den Entwicklern innerhalb weniger Minuten, ob größere Regressionen gefunden wurden. Die schnelle Rückmeldung hilft dabei, Fehler frühzeitig zu entdecken und zu beheben. Da die Pipeline für jede Änderung an der Software gestartet wird, bezieht sich das Feedback aus der Pipeline immer genau auf eine einzelne Änderung der Software und ermöglicht somit einen direkten Rückschluss von der gefundenen Regression auf die auslösende Änderung.

Wie sieht die technische Umsetzung von Commit und Acceptance Test Stage bei der Realisierung einer Continuous Delivery Pipeline aus? Die einzelnen Stufen der Pipeline lassen sich mit einem Build-Server abbilden, auf dem die gewünschten Aufgaben in mehreren Jobs modelliert werden. In den Jobs der Commit Stage werden auf ihm die Komponenten der Software zuerst kompiliert und im Anschluss die jeweiligen Unit-Tests ausgeführt. Bei erfolgreichem Durchlauf fasst man jetzt die erzeugten Binärartefakte der Softwarekomponenten zum Paket oder Bundle zusammen. Dieses Bundle wird in einem Repository abgelegt und ab diesem Moment ausschließlich für den weiteren Durchlauf des Softwarestandes durch die Pipeline genutzt. Will man diesen Stand später auf dem Produktionssystem installieren, kommt dafür ebenfalls genau dieses Bundle zum Einsatz.

Hier werden zwei wichtige Prinzipien von Continuous Delivery deutlich:

• Das Testen jeder Änderung an der Software.
• Der Softwarestand wird nur ein einziges Mal an zentraler Stelle gebaut.

Sie gewährleisten, dass man die Testergebnisse konkret einzelnen Änderungen an der Software zuordnen kann und vor allem eine komplette Rückverfolgbarkeit von den Binärartefakten in der Produktion bis zur konkreten Sourcecode-Version gewährleistet ist.

Nach erfolgreichem Abschluss der Commit Stage wird das Bundle auf dem Build-Server in die Acceptance Test Stage übergeben. Hier führt dieser verschiedenartige Akzeptanztests aus: Integrationstests, die das Zusammenspiel mehrerer Komponenten testen, und Systemtests, die die Software als Ganzes aus Sicht des Benutzers prüfen. Zusätzlich kann man hier auch weitere Tests integrieren, die nichtfunktionale Anforderungen wie die Performance der Software untersuchen. Für die Ausführung dieser Akzeptanztests holt der Build-Server jeweils das in der Commit Stage erzeugte Bundle aus dem zentralen Repository, installiert die Komponenten der Software auf einer geeigneten Testumgebung und startet dann die Tests gegen oder auf dieser Umgebung. Im Anschluss spielt er die Auswertung der Testergebnisse als Feedback an die Entwickler zurück.

Hat der Softwarestand die Acceptance Test Stage erfolgreich passiert, können weitere Pipeline-Schritte mit manuellen Tests erfolgen. Auch hierfür wird der Softwarestand aus einem Bundle auf eine Testumgebung installiert. Hat er alle nötigen Teststufen passiert, lässt sich das entsprechende Bundle "auf Knopfdruck" auf dem Produktionssystem installieren.

Der Aufwand, eine solche Continuous Delivery Pipeline erfolgreich für ein Projekt umzusetzen, ist nicht unerheblich. Was gewinnt man dadurch?

Wo gewinnen Projekte mit Continuous Delivery?

Die meisten können sicherlich spontan eine ganze Reihe von Softwareprojekten anführen, die mit Pauken und Trompeten gescheitert sind: LKW-Maut, ObamaCare et cetera, um nur einige Beispiele zu nennen. Ohne bei den genannten Projekten die wirklichen Gründe zu kennen, lässt sich sagen, dass je größer der Umfang eines einzelnes Software-Releases ist, desto höher leider auch das Risiko ist, dass hierbei etwas schiefläuft. Es kommt zum Beispiel häufig vor, dass der Funktionsumfang sich nur schlecht manuell testen lässt, die Auswirkung von Änderungen auf die Performance nicht früh genug beachtet wurden oder das Zusammenspiel verschiedener Komponenten und deren Lastverhalten zu wenig Berücksichtigung beim Testen gefunden haben.

Continuous Delivery entschärft diese Situation erheblich, indem der gesamte Release-Prozess automatisiert und damit drastisch verschlankt wird. Durch den Wegfall der vielen manuell auszuführenden Aufgaben lassen sich bereits kleine Gruppen von Änderungen produktiv einsetzen. So sinkt das Risiko, dass etwas schiefgeht. Und sollte das doch einmal passieren, stellt auch ein Rollback kein großes Problem mehr dar. Firmen mit Continuous-Delivery-Erfahrung tendieren in einem solchen Fall sogar dazu, eher den in Produktion aufgetretenen Bug zu fixen und sofort eine korrigierte Version der Software auszurollen, statt auf eine ältere Version zurückzugehen (Rollforward statt Rollback).

Die Entwicklung einer Software stellt außerdem immer auch eine Vorleistung dar: Zuerst wird ein Konzept entwickelt, dann die eigentliche Software erstellt, getestet und vielleicht ein halbes Jahr nach dem Projektstart produktiv gesetzt. Erst in dem Moment zeigt sich in den meisten Fällen, ob sich mit der Software wirklich das gewünschte Ziel erreichen lässt. Wird die Software so vom Kunden angenommen oder hat man ein halbes Jahr lang an den Wünschen des Kunden vorbei entwickelt?

Da man kleine Features innerhalb von Tagen bis zum Kunden bekommt, lässt sich auch experimentieren: Zeigen die Benutzer Interesse am Feature? Lohnt es sich, hier weiter zu investieren? Wird das Feature besser in dieser oder besser in jener Variante angenommen? Die Durchlaufzeit von der Idee bis zur Produktivsetzung neuer Features lässt sich mit Continuous Delivery von mehreren Monaten zu Tagen oder gar Stunden reduzieren. Die Software bringt deutlich eher Geld als früher, und man kann endlich schnell auf Änderungen am Markt reagieren.

Für die Entwickler entsteht durch den Einsatz von Continuous Delivery eine neue Kategorie von Feedback. Innerhalb von Minuten gibt es eine Rückmeldung darüber, ob durch die letzte Änderung womöglich an ganz anderer Stelle im Code etwas kaputt gegangen ist. Das gibt ein Gefühl von Sicherheit beim Entwickeln und erlaubt, auch ohne Angst kontinuierlich zu refaktorisieren und so die Codequalität auf einem konstanten Niveau zu halten. Das Feedback über die Softwarequalität steht dabei nicht nur den Entwicklern zur Verfügung. Auch die Product Owner können so schnell im Blick haben, ob alle Akzeptanztests noch erfolgreich durchlaufen.

Wenn in der Entwicklung konsequent verschiedenartige Tests zu jedem neuen Feature dazugehören und diese im Sinn von Continuous Delivery mit jeder Änderung an der Software ausgeführt werden, fallen viele Fehler und Regressionen früh auf. Hier kann Continuous Delivery also Sparpotenzial bescheren: Denn in Produktion entdeckte Fehler kosten häufig ein Vielfaches. Test und Testbarkeit rücken mehr in den Fokus. Das heißt, beim Schreiben von Tests fällt auf, ob der Code testbar ist oder nicht. Ist er es nicht, findet gleich eine Qualitätsverbesserung statt, zum Beispiel durch höhere Entkopplung oder Verringerung von Abhängigkeiten.