© Excellent backgrounds/Shutterstock.com
Java Magazin
Continuous Delivery: ein Blick auf den Stand der Dinge

Unendliches Vertrauen

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.

Eberhard Wolff


Video: Digitale Transformation benötigt mehr als Technologie

Das Ziel von Continuous Delivery [1] 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 Ob...

Java Magazin
Continuous Delivery: ein Blick auf den Stand der Dinge

Unendliches Vertrauen

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.

Eberhard Wolff


Video: Digitale Transformation benötigt mehr als Technologie

Das Ziel von Continuous Delivery [1] 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 Ob...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang