Softwareentwicklung mit klaren Betriebsgrenzen

Eine neue Version kann alle Abnahmetests bestehen und trotzdem noch nicht reif für den Betrieb sein. Im Produktivsystem treffen reale Daten, externe Dienste, Berechtigungen, Wartungsfenster und unerwartete Last aufeinander. Spätestens dort reicht es nicht mehr, dass „das Team“ zuständig ist. Es muss feststehen, wer eine Freigabe erteilt, wer bei einer Störung entscheidet und woran erkannt wird, dass der Dienst seinen Zweck nicht mehr erfüllt.

Ein Release braucht eine Herkunft

Kontrollierte Auslieferung beginnt mit der schlichten Frage, was genau veröffentlicht wird. Der Stand des Quellcodes allein genügt nicht. Abhängigkeiten, Build-Umgebung, Konfiguration und Datenbankänderungen bestimmen ebenso, welches Verhalten im Zielsystem ankommt. Das Secure Software Development Framework des NIST empfiehlt unter anderem, die Integrität einer Veröffentlichung prüfbar zu machen und die zugehörigen Artefakte geschützt aufzubewahren. So lässt sich eine Version später eindeutig zuordnen.

Tempo und Stabilität gemeinsam lesen

Die DORA-Forschung betrachtet Softwareauslieferung aus zwei Richtungen. Zur einen gehören Änderungsdurchlaufzeit, Deployment-Häufigkeit und die Dauer bis zur Wiederherstellung. Auf der anderen stehen fehlgeschlagene Änderungen und ungeplante Nacharbeiten. Der Zusammenhang ist wichtiger als ein einzelner Wert. Eine hohe Release-Frequenz sagt wenig aus, wenn Änderungen regelmäßig einen manuellen Eingriff auslösen. Ein seltenes Release ist umgekehrt nicht automatisch sorgfältiger.

Solche Kennzahlen eignen sich vor allem für denselben Dienst über einen längeren Zeitraum. Dann führen Veränderungen zu konkreten Fragen: Warum dauern Freigaben länger? Weshalb steigt der Anteil der Nacharbeit? Welche Änderung hat die Wiederherstellung erleichtert?

Der Rückweg wird vor der Freigabe geprüft

Ein Rollback ist selten nur die Rückkehr zu einem älteren Programmstand. Daten können bereits verändert, Nachrichten versendet oder Schnittstellenpartner informiert worden sein. Der Rückweg muss diese Folgen einbeziehen. Bei riskanten Änderungen kann eine schrittweise Freigabe an einen begrenzten Teil des Datenverkehrs helfen. Das im Google SRE Workbook beschriebene Canarying verbindet diese Begrenzung mit vorher festgelegten Signalen und einer automatisierbaren Reaktion.

Vor dem Start sollte daher geklärt sein, wer ausliefert, stoppt oder zurückrollt, welche Beobachtungen eine Entscheidung auslösen und wo Prüfungen sowie bekannte Einschränkungen dokumentiert sind. Dazu gehören auch Signale am Ergebnis: CPU, Speicher und HTTP-Status zeigen nicht, ob Bestellungen verarbeitet oder Datensätze vollständig übertragen wurden. Erst ein praktischer Test zeigt, ob diese Vereinbarung unter Zeitdruck trägt.

Ein Release ist in diesem Verständnis abgeschlossen, wenn seine Herkunft feststeht, der neue Zustand beurteilt werden kann und ein fehlerhafter Stand einen erprobten Rückweg hat. Fehlt einer dieser Nachweise, wurde Software verteilt. Über ihre Betriebsreife ist damit noch nichts entschieden.