Eberhard Wolff innoQ

Wie bei sehr vielen Änderungsinitiativen geht es auch bei Continuous Delivery am Ende um eine organisatorische Änderung.

Continuous Delivery steht für die ständige Auslieferung von Software in Produktion. Ein Konzept, das mittlerweile mehr als fünf Jahre alt ist. Zeit, ein Fazit zu ziehen und auf die Erfahrungen aus der Praxis zu schauen.
Das Ziel von Continuous Delivery ist, Software möglichst regelmäßig in Produktion zu bringen. Das Deployment von Software dauert selbst bei manuellen Vorgehen nur sehr selten länger als einen Tag. Die neuen Deployment-Werkzeuge reduzieren dies weiter. Wenn die Installation nur einen Tag dauert, ist es möglich, Software jede Woche oder noch öfter zu deployen. Die Installation selbst kann also nicht der Grund sein, warum Unternehmen dennoch Quartalsreleases machen oder noch seltener deployen. Das Problem ist nicht das Deployment. Software wird nur selten in Produktion gebracht, weil das Vertrauen in die Software fehlt. Leider ist es so, dass Fehler in der Software erst in der Produktion auffallen und Schaden verursachen oder den Gang in Produktion einfach vollkommen verhindern. Die Automatisierung des Deployments ist also eigentlich die falsche Maßnahme, um Software öfter und mit einer höheren Qualität in Produktion zu bringen. Wirklich wichtig ist die Optimierung der Tests.

Die Tests müssen wesentlicher schneller durchlaufen. Wenn ein Testteam Wochen benötigt, um die Software zu testen, sind schnelle Releasezyklen kaum umzusetzen. Nur eine Automatisierung kann die notwendige Geschwindigkeit bieten. Wenn ein Kunde die Anwendung noch manuell testet, wird das Release ebenfalls verzögert. Außerdem können gerade bei diesem Schritt unklare Fehlerbeschreibungen entstehen, sodass offen bleibt, wie die Fehler reproduziert werden können und ob die Fehler tatsächlich behoben werden. Gerade Akzeptanztests sollten automatisiert sein. Denn sie überprüfen, ob die Software die Anforderungen der Kunden erfüllt. Erst so sind schnelle Releasezyklen möglich. Außerdem sollten die Kunden so viel Vertrauen in die Tests haben, dass sie die Anwendung nicht mehr selbst manuell testen. Dazu ist es notwendig, dass Kunden automatisierte Tests verstehen.

Technische Lösungen dazu gibt es einige. Beispielsweise Behaviour-driven Design (BDD), bei dem Anforderungen als natürlichsprachlicher Text formuliert und dann automatisiert ausgeführt werden. Wesentlicher Vorteil: Kunden sollten dazu in der Lage sein, den natürlichsprachlichen Text und damit den Test zu verstehen. Technisch steht dahinter eine Art Lückentext. Der Code liest aus dem Lückentext entsprechende Variablen aus und führt dann den Code aus.

Natürlich können auch automatisierte UI-Tests eine Option sein. Schließlich testen Kunden oft die Anwendung von der Oberfläche her, so wie normale Benutzer die Anwendung auch verwenden würden. Allerdings sind Tests über die Benutzeroberfläche fragil, weil kosmetische Änderungen an der Benutzeroberfläche die Tests brechen können – selbst wenn die Logik unverändert bleibt. Außerdem sind die Tests oft langsam und unzuverlässig.

Um es noch einmal klar zu sagen: Die Anforderung an die automatisierten Akzeptanztests ist, dass der Kunde die Software akzeptiert, wenn der Test erfolgreich ist. Der Kunde muss daher an der Gestaltung des Tests mitarbeiten. Nur so kann er sicher sein, dass der Test wirklich das testet, was für ihn relevant ist. Natürlich muss der Kunde den Test nicht selbst schreiben, aber er muss den Test verstehen und ihm vertrauen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 6.17 - "Continuous Delivery"

Alle Infos zum Heft
5797964815 Jahre Continuous Delivery: Ein Fazit
X
- Gib Deinen Standort ein -
- or -