© best_vector/Shutterstock.com
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?

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?

Artikelserie

Teil 1: DevOps und Business Agility

Teil 2: DevOps und Agilität 2.0

Teil 3: Echtes Continuous Delivery realisieren

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

Teil 5: DevOps setzt robuste Architekturen voraus

Teil 6: Wissen wie’s läuft – Schnell reagieren können mit Telemetrie

Teil 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 ...

Neugierig geworden?

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