Strukturiertes Deployment: Kontrollierte Releaseprozesse senken das Bug-Risiko

Inhaltsverzeichnis

Wann ist ein neuer Software-Build fertig und kann veröffentlicht werden? Diese Frage ist nur scheinbar einfach, denn es gibt bei jedem Release ein gewisses Risiko. So können trotz aller Tests noch versteckte Fehler existieren. Auch Seiteneffekte oder Inkompatibilitäten sind beim Einsatz in bestimmten Umgebungen oder bei besonderen Randbedingungen ein nicht zu unterschätzendes Problem. Und schließlich gilt auch die alte Ingenieursweisheit: Kein Produkt kann narrensicher gemacht werden. Es gibt immer einen kreativen Narren, der neue Wege zu Fehlern findet.

In der Praxis führt das häufig dazu, dass über den vermeintlich richtigen Zeitpunkt für ein Release oft aus dem Bauch heraus entschieden wird. Das ist jedoch ein risikoreiches Vorgehen, und führt dazu, dass viele Unternehmen ihre Software zu früh freigeben. Das Consortium for IT Software Quality (CISQ) schätzte noch Ende 2018 die allein in den USA selbstverschuldeten Kosten für qualitativ minderwertige Versionen auf 2,84 Billionen Dollar pro Jahr. Laut einer aktuellen Studie des Project Management Institute (PMI) scheitern selbst in erfahrenen IT-Unternehmen elf Prozent der Projekte.

Releasequalität: Risiken vermeiden oder eingehen?

Wichtig für Softwareanbieter, aber auch andere Unternehmen mit Entwicklungsabteilung ist ein methodisches Vorgehen, um die Releasequalität zu verbessern. Über die Frage, wie sich die Qualität sicherstellen lässt, herrscht unter den meisten Entwicklern jedoch kein Konsens. Der Zeitpunkt der Freigabe ist stark von der Unternehmenskultur abhängig. So sind große, traditionell organisierte Unternehmen meist nicht besonders risikofreudig und verfolgen einen stärker strukturierten und vorsichtigen Ansatz für die Qualitätssicherung. Gleichzeitig nutzen sie klassische Entwicklungsmethoden und setzen eher auf wenige, umfangreiche und umfassend getestete Releases.

Digitale Unternehmen der nächsten Generation sind im Vergleich deutlich agiler. Sie verfolgen häufig die Politik, jeweils kleine Änderungen in kurz aufeinanderfolgenden Releases bereitzustellen. Dabei stellen sie die neue Softwareversion in der Regel zunächst nur einem Teil ihrer Kunden zur Verfügung. Sollte etwas schief gehen, wird das Release zurückgezogen und die Nutzer erhalten wieder die alte Version. Treten nach einer festgelegten Zeit keine Probleme mehr auf, rollen sie das Release an alle Kunden aus.

Wer auf diese Weise Software bereitstellt, kann ein höheres Risiko eingehen. Die geschilderte Bereitstellung auf Probe ist im Grunde eine Erweiterung der Testphase auf Pilotnutzer. Dabei eröffnet sich sogar die Möglichkeit, unterschiedlichen Nutzergruppen jeweils andere Funktionen bereitzustellen, um sie in der Praxis zu erproben. Erst danach fällt die Entscheidung, welche Variante allen Nutzern zugänglich sein soll. Diese Vorgehensweise verschafft Digitalunternehmen eine überdurchschnittliche Dynamik. Doch die Methode ist nicht bedingungslos, es gibt zwei wichtige Voraussetzungen:

• Erstens erfordert diese Form der Agilität eine stark ausgebaute Infrastruktur mit großen Reserven und ausgefeilte, hoch automatisierte DevOps-Prozesse. Nur damit lässt sich die Bereitstellung an Benutzergruppen bewältigen. Auch der umgekehrte Weg muss fix gehen, denn es sollten möglichst wenige Nutzer von Fehlern betroffen sein.
• Zweitens erfordert dieser Ansatz eine sehr große Nutzerzahl, sodass für die einzelnen Anwendungsbereiche im Bereitstellungsprozess hinreichend große Testgruppen zur Verfügung stehen. Denn je mehr Kunden ein neues Release testen, desto größer ist die Wahrscheinlichkeit, dass sich ein übersehener Bug bemerkbar macht.

Die anspruchsvollen Voraussetzungen machen deutlich: Diese agile Form der Bereitstellung ist kein Königsweg zu hoher Releasequalität. Während einige Vorreiter aus dem Silicon Valley und China die erforderlichen Nutzerzahlen und Ressourcen vorweisen, hapert es in vielen Unternehmen genau daran. Doch die traditionelle, risikoaverse Methode ist kaum erfolgreicher, auch hier scheitern Entwicklungsprojekte aus altbekannten Gründen: Viele Releases sind zu umfangreich geplant und werden durch häufige, späte Änderungen aufgrund von Kundenwünschen oder technischen Neuerungen ausgebremst.