© best_vector/Shutterstock.com
Windows Developer
Teil 4: Bessere Qualität durch häufige Releases

Einer geht noch

Fans von Hollywoodfilmen kennen die Dramaturgie jeder guten Story: Am Anfang läuft alles prima, aber dann tauchen Konflikte auf. Wird der Held es schaffen, sie zu überwinden, und wartet am Schluss das Happy End? Nach drei Folgen unserer DevOps-Serie sind wir nun an diesem Punkt angelangt - nachdem die Sonne die gewinnbringende DevOps-Welt erhellte, ziehen nun Wolken des Zweifels auf, z. B.: Warum führen häufige Releases letztendlich zu einer besseren Qualität? Und wie sieht eine dazu passende Qualitätssicherungsstrategie aus?

Thomas Schissler, Uwe Baumann


Wie sollen wir es schaffen, bei häufigen Releases die Qualität der Software sicherzustellen? Jedes Release ist schließlich ein potenzielles Risiko, dass etwas schiefgehen könnte. Warum sollte man diese Unwägbarkeit also möglichst oft eingehen wollen?

ArtikelserieTeil 1: DevOps und Business AgilityTeil 2: DevOps und Agilität 2.0Teil 3: Echtes Continuous Delivery realisierenTeil 4: Bessere Qualität durch häufige ReleasesTeil 5: DevOps setzt robuste Architekturen vorausTeil 6: Wissen wie’s läuft – Schnell reagieren können mit TelemetrieTeil 7: DevOps – ein Erfahrungsbericht

Eine fast reflexartige Antwort bei vielen Teams lautet: Wir müssen möglichst viel testen und so die Qualität absichern. Allerdings gibt es dabei einen Haken: Manuelles Testen ist bei einer so hohen Releaserate nicht mehr praktikabel; die Tests müssen automatisiert werden. Durch Automatisierung können umfangreiche Testszenarien problemlos, häufig und schnell ausgeführt werden. Und sind alle diese Tests erfolgreich durchlaufen, sollte es auch nicht zu Problemen im Produktivbetrieb kommen – so zumindest die Hoffnung. Auf diese Erkenntnis folgt nun sehr oft die gründliche Ernüchterung.

Denn: Damit ist das Thema DevOps und häufige Releases zunächst einmal für viele Entwicklungsteams unrealistisch. Wer hat heute schon eine umfangreiche Bibliothek automatisierter Tests, auf die er sich wirklich verlassen kann? Die Strategie lautet also, zunächst einmal in Testautomatisierung zu investieren, danach können wir uns mit dem Thema DevOps wieder beschäftigen.

Kurios ist an dieser Situation, dass die Lösung, die nach unserer Auffassung eine bessere Qualität verspricht, ausgerechnet durch Qualitätsbedenken verhindert wird. In diesem Artikel wollen wir begründen, warum häufige Releases letztendlich zu einer besseren Qualität führen. Und wir wollen skizzieren, wie eine dazu passende Qualitätssicherungsstrategie aussehen könnte.

Zugegebenermaßen sind die dafür erforderlichen Veränderungen für die meisten Organisationen alles andere als trivial und benötigen auch entsprechend Zeit. Aber es lohnt sich. DevOps ist hier eher ein Katalysator, diese Veränderungen anzustoßen und zu beschleunigen. Die hier vorgeschlagenen Strategien sind somit nicht ausschließlich in einem DevOps-Kontext sinnvoll.

Zunächst möchten wir einen Zusammenhang in Frage stellen, der häufig hergestellt wird. Oftmals wird hohe Qualität als Ergebnis vieler Tests gesehen. Die Anzahl an Tests oder auch die Code Coverage bei Unit-Tests wird dann al...

Windows Developer
Teil 4: Bessere Qualität durch häufige Releases

Einer geht noch

Fans von Hollywoodfilmen kennen die Dramaturgie jeder guten Story: Am Anfang läuft alles prima, aber dann tauchen Konflikte auf. Wird der Held es schaffen, sie zu überwinden, und wartet am Schluss das Happy End? Nach drei Folgen unserer DevOps-Serie sind wir nun an diesem Punkt angelangt - nachdem die Sonne die gewinnbringende DevOps-Welt erhellte, ziehen nun Wolken des Zweifels auf, z. B.: Warum führen häufige Releases letztendlich zu einer besseren Qualität? Und wie sieht eine dazu passende Qualitätssicherungsstrategie aus?

Thomas Schissler, Uwe Baumann


Wie sollen wir es schaffen, bei häufigen Releases die Qualität der Software sicherzustellen? Jedes Release ist schließlich ein potenzielles Risiko, dass etwas schiefgehen könnte. Warum sollte man diese Unwägbarkeit also möglichst oft eingehen wollen?

ArtikelserieTeil 1: DevOps und Business AgilityTeil 2: DevOps und Agilität 2.0Teil 3: Echtes Continuous Delivery realisierenTeil 4: Bessere Qualität durch häufige ReleasesTeil 5: DevOps setzt robuste Architekturen vorausTeil 6: Wissen wie’s läuft – Schnell reagieren können mit TelemetrieTeil 7: DevOps – ein Erfahrungsbericht

Eine fast reflexartige Antwort bei vielen Teams lautet: Wir müssen möglichst viel testen und so die Qualität absichern. Allerdings gibt es dabei einen Haken: Manuelles Testen ist bei einer so hohen Releaserate nicht mehr praktikabel; die Tests müssen automatisiert werden. Durch Automatisierung können umfangreiche Testszenarien problemlos, häufig und schnell ausgeführt werden. Und sind alle diese Tests erfolgreich durchlaufen, sollte es auch nicht zu Problemen im Produktivbetrieb kommen – so zumindest die Hoffnung. Auf diese Erkenntnis folgt nun sehr oft die gründliche Ernüchterung.

Denn: Damit ist das Thema DevOps und häufige Releases zunächst einmal für viele Entwicklungsteams unrealistisch. Wer hat heute schon eine umfangreiche Bibliothek automatisierter Tests, auf die er sich wirklich verlassen kann? Die Strategie lautet also, zunächst einmal in Testautomatisierung zu investieren, danach können wir uns mit dem Thema DevOps wieder beschäftigen.

Kurios ist an dieser Situation, dass die Lösung, die nach unserer Auffassung eine bessere Qualität verspricht, ausgerechnet durch Qualitätsbedenken verhindert wird. In diesem Artikel wollen wir begründen, warum häufige Releases letztendlich zu einer besseren Qualität führen. Und wir wollen skizzieren, wie eine dazu passende Qualitätssicherungsstrategie aussehen könnte.

Zugegebenermaßen sind die dafür erforderlichen Veränderungen für die meisten Organisationen alles andere als trivial und benötigen auch entsprechend Zeit. Aber es lohnt sich. DevOps ist hier eher ein Katalysator, diese Veränderungen anzustoßen und zu beschleunigen. Die hier vorgeschlagenen Strategien sind somit nicht ausschließlich in einem DevOps-Kontext sinnvoll.

Zunächst möchten wir einen Zusammenhang in Frage stellen, der häufig hergestellt wird. Oftmals wird hohe Qualität als Ergebnis vieler Tests gesehen. Die Anzahl an Tests oder auch die Code Coverage bei Unit-Tests wird dann al...

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