Weniger Fehler beim Deployment

Frühjahrsputz: Tipps und Tricks für mehr Struktur im Deployment-Prozess

Jan Wolter

© Shutterstock / Olivier Le Moal

Veröffentlichen oder nicht veröffentlichen? Das ist die Frage. Leider wird die Entscheidung oftmals aus dem Bauch heraus und nicht aufgrund konkreter Daten getroffen. Dabei kann der Zugang zu Daten zusammen mit einem strukturierten Deployment-Prozess entscheidend zur Vermeidung von fehlerhaften Releases beitragen.

Hand aufs Herz: Nach welchen Kriterien entscheidet Ihr Unternehmen, wann ein Software-Update veröffentlicht werden kann? Falls Sie darauf keine Antwort parat haben, sind Sie nicht alleine. In allzu vielen Teams gelten keine klaren Kriterien, die definieren, wann ein Update bereit für die Veröffentlichung ist. Doch in Zeiten von DevOps und CI/CD sollten Entwickler und Projektverantwortliche klare Entscheidungsprozesse definieren und sich auf einheitliche Standards für die Freigabe einigen. Wenn es keine klaren Prozesse gibt um zu entscheiden, wann ein Software-Build zur Veröffentlichung bereit ist, können Unternehmen unter kritischen Fehlern in der Produktion leiden.

Die Prozesse unterscheiden sich je nach Unternehmenstyp

Das Vorgehen bei einem Software-Release unterscheidet sich von Unternehmen zu Unternehmen stark. Unternehmen mit einer großen Nutzerbasis, nahezu unbegrenzten Ressourcen und Infrastruktur sind in der Lage, Releases schnell freizugeben und gegebenenfalls zurückzuziehen. So werden Updates in höherer Frequenz einem kleinen Teil der Nutzerbasis zugänglich gemacht und die Systeme erkennen automatisch, wenn etwas schief gelaufen ist, sodass auf die vorherige Version zurückgegriffen werden kann. Solche Unternehmen können aufgrund dieses Ansatzes mehr Risiko eingehen, doch sie benötigen auch eine unglaubliche Menge an Infrastruktur sowie DevOps-Hosting und eine sehr große Anzahl von Kunden. Traditionell organisierte Unternehmen agieren dagegen meist sehr risikoavers und folgen einem strukturierten, kleinteiligen Prozess zur Qualitätssicherung. Tendenziell erfolgen wenige, umfassende und vorab gut durchgetestete Releases, die mit klassischen Entwicklermethoden aufgebaut wurden. Hier leidet jedoch die Agilität, die benötigt wird, um in kompetitiven Märkten mithalten zu können.

Weder die risikoaverse noch die risikofreudige Methode ist also für sämtliche Firmen anwendbar. Somit gilt es für die Softwareentwicklung flächendeckend strukturierte Deployment-Prozesse zu etablieren und den Veröffentlichungsprozess zu optimieren.

Der Testumfang variiert

Mit Blick auf diese Optimierung steht vor allem der Testumfang im Fokus. Dabei gilt es abzuwägen: Welche Voraussetzungen müssen gegeben sein, damit das Produkt oder der Service möglichst fehlerfrei ist. Natürlich müssen vor allem kritische Funktionen der Software weiterhin reibungslos funktionieren und dürfen durch ein Update nicht negativ tangiert werden. Gleichzeitig müssen mit Blick auf Zeit und Geld die jeweils benötigten Ressourcen für Tests evaluiert werden. Unit-Tests beispielsweise prüfen in der Regel lediglich einige Code-Zeilen separat, wie etwa die korrekte Implementierung von Vorgaben für Texteingaben. Eine Ebene darüber setzen Integrationstests an, die multiple Komponenten im Verbund testen. Diese sind wichtig, um das Risiko von Seiteneffekten zu minimieren. Und noch komplexer sowie aufwändiger wird das Testen auf Systemebene.

Neben diesen Standardtests kann es jedoch auch sinnvoll sein, weitere Tests einfließen zu lassen. Exemplarisch stehen dafür explorative Tests, bei denen Funktionen nicht nach einem Skript getestet werden, sondern von einem Tester, der das digitale Erlebnis „unterbrechen“ will.

Es empfiehlt sich generell, früh im Prozess so umfangreich wie möglich zu testen. Damit verringert sich die Laufzeit des einzelnen Tests und die Frequenz kann erhöht werden. Um Tests jedoch nicht nur aus Sicht der Entwickler, sondern aus unterschiedlichen Blickwinkeln durchzuführen, sollten explorative Tests mit Testern durchgeführt werden, die tatsächliche Nutzer repräsentieren.

Tipps zur Strukturierung von Deployment-Prozessen

Diese Mischung aus automatisierten und manuellen Tests macht es für Produktverantwortliche schwieriger, den richtigen Zeitpunkt für das Release zu bestimmen. Eine Strukturierung des Prozesses kann hier helfen, Zeit und Geld zu sparen. Dabei unterstützen folgende Maßnahmen:
Quality-Gate-Prozesse (QGPs): Projekte werden hierbei in Phasen eingeteilt, wobei am Ende jeder Phase ein Quality-Gate gesetzt wird. Im Unterschied zu Meilensteinen sind diese Quality-Gates stets einheitlich gesetzt, um im Verlauf des Projekts immer gleiche formale Qualitätssicherungsprozesse festzuhalten. Die zu prüfenden Aspekte werden dabei in einer klar definierten Checkliste festgehalten, um Konsistenz zu wahren. Auf Basis der Bewertung entstehen die Entscheidungen zum weiteren Vorgehen: “Go” – Übergang zur nächsten Phase; “Hold” – Verbesserungen innerhalb der Phase sind erforderlich, da nicht alle Aspekte erfüllt sind; und “Stop” – wobei hier geklärt werden muss, ob das Projekt abgebrochen werden muss oder eine umfangreiche Nachbesserung den Erhalt ermöglicht.

Timeboxing für nicht-automatisierte Tests: Explorative Tests sind von entscheidender Bedeutung: Wenn der Fehler von Kunden nach der Veröffentlichung entdeckt wird, ist es zu spät. Um das Ausmaß solcher Tests jedoch in Grenzen zu halten, können sich Unternehmen bei Methoden aus dem Projektmanagement bedienen. Beim Timeboxing wird ein Zeitraum definiert, innerhalb dessen solche explorativen Tests durchgeführt werden. Ziel ist es, in der vorgegeben Zeit möglichst viel zu testen und den Test dann auch strikt zu beenden – egal wie weit man gekommen ist. Bleiben offensichtliche Aspekte offen, müssen diese in die Timebox der nächsten Phase verschoben werden.

Bug-Triage: Auch bei noch so guter Vorbereitung sind Fehler bis zu einem gewissen Grad unvermeidbar. Daher sollte ein Prozess definiert werden, in dem Fehler-Assessment betrieben werden kann. Bei der Triage geht es darum zu entscheiden, welche Bugs am kritischsten sind, um diese dann unverzüglich – sprich als Hotfix – zu beheben. Bei Bugs mit niedrigerer Dringlichkeit sollte je nachdem, wie kritisch sie für die Gesamterfahrung sind, abgewogen werden. Allerdings sollten Teams stets darauf bedacht sein, den Backlog minimal zu halten, um spätere Regressionsfehler zu vermeiden.

Datenbasierte Entscheidungshilfen

Entwickler-Teams stehen unter enormem Druck, denn das Management sowie externe Stakeholder drängen oft auf agile und schnellere Softwareentwicklung mit zufriedenstellenden Resultaten. Um die Entscheidung des Projektverantwortlichen für das “Go” zur Veröffentlichung nachvollziehbarer zu machen, kann der Einsatz von Qualitäts-Scores, wie der Applause Quality Score (AQS), hilfreich ein. Basierend auf historischen Daten und aktuellen Metriken kann die Softwarequalität messbar gemacht werden. Solche Metriken umfassen beispielsweise den Testumfang und die Testabdeckung, Fehlerhäufigkeit sowie den Schweregrad der Bugs. Einheitliche Scores bieten zudem eine weniger subjektive Entscheidungshilfe und erlauben Benchmarking, was den Teams die „Go“ oder „No-Go“ Entscheidungen wesentlich erleichtert.

Geschrieben von
Jan Wolter

Jan Wolter ist General Manager EU bei Applause.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: