Strukturiertes Deployment: Kontrollierte Releaseprozesse senken das Bug-Risiko

Die Entscheidung, ein Release zu ver?ffentlichen, folgt h?ufig dem Bauchgefühl. Strukturierte Bereitstellungsprozesse schützen vor fehlerhaften Releases.

Lesezeit: 6 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 15 Beitr?ge
Von
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.

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.

汤姆叔叔影院