Trotz aller Tests im Vorfeld lassen sich Fehler im Release einer neuen Softwareversion nicht immer vermeiden. Zum Glück werden sie meist schnell entdeckt und lassen sich durch ein einfaches “Fix Forward” beheben. Leider gibt es aber Fälle, bei denen die Fehleranalyse sehr aufwändig und gleichzeitig ihre Auswirkung auf die Nutzbarkeit des Produktes gravierend ist. Man denke nur an Memory Leaks oder Dead Locks, die nicht nur durch klassische Tests vorm Deployment schwer zu erkennen sind, sondern in der Regel auch eine zeitaufwändige Ursachenforschung erforderlich machen.

Um in solchen Fällen die Einschränkungen für den Nutzer gering zu halten, liegt es nah, einfach wieder auf die vorherige Softwareversion zurückzugehen. Doch was so einfach klingt, ist in der Praxis oft mit Schwierigkeiten verbunden. Es gilt einmal mehr: “Everything comes with a price tag.”

Damit ein Rollback nicht zu weiteren Problemen im Produkt führt, müssen insbesondere drei Aspekte bei der Releaseplanung berücksichtigt werden.

  • Schnittstellen
    Beinhaltet die neue Softwareversion Änderung an Schnittstellen, muss sichergestellt werden, dass bei einem Rollback auch weiterhin die Kommunikation mit den externen Systemen über die alte Protokollversion möglich ist. Das gilt sowohl für die konsumierten Schnittstellen, als auch die, die man selbst anbietet.

  • Geschäftsregeln
    Wenn durch das Rollback neue Geschäftsregeln wieder wegfallen, muss sichergestellt sein, dass auch mit der vorherigen Geschäftslogik die Anwendungsfälle fachlich korrekt abgebildet sind. Führt man beispielsweise einen neuen Genehmigungsschritt in einem Arbeitsablauf ein, müssen die Daten, die sich in diesem neuen Zustand befinden, auch mit dem alten Softwarestand weiterhin zugreifbar sein.

  • Persistierte Daten
    Werden durch das Release Änderungen an der persistierten Datenstruktur vorgenommen, müssen diese abwärtskompatibel sein, damit nach einem Rollback keine Fehler beim Lesen und Schreiben der Daten entstehen.

klein, abwärtskompatibel und entkoppelt

Aus diesen Herausforderungen ergeben sich Konsequenzen für die Planung und Durchführung der Softwarereleases. Zunächst sollte der Versionsumfang möglichst klein sein, damit sich die möglichen Auswirkungen bei einem Rollback (siehe oben) besser überschauen lassen und entsprechende Vorkehrungen getroffen und Tests durchgeführt werden können. Featurebasierte Rollouts sind daher Bundle Releases am Ende eines Sprints vorzuziehen.

Darüberhinaus müssen alle im Release enthaltenen Änderungen abwärtskompatibel sein. Ein bewährtes Mittel dafür ist der konsequente Einsatz einer Expand&Contract-Policy.

Last but not least muss eine rollbackfähige Releasestrategie durch ein automatisiertes, inkrementelles Lieferverfahren unterstützt werden, dass Deployment und Release voneinander entkoppelt. Hier kommen Techniken der Progressive Delivery wie Canary Releases, Blue-Green-Deployments und Feature Toggles ins Spiel.

Fazit

Software Rollbacks helfen bei Fehlern mit umfangreicher Analyse- und Behebungszeit, die Auswirkungen für die Nutzer zu minimieren. Sie haben aber Auswirkungen auf Aufwand und Geschwindigkeit der Softwareentwicklung. Daher muss man diese Strategie vor dem Kosten-Risiko-Hintergrund individuell bewerten und entscheiden, ob und wann sie zum Einsatz kommt.