Die fehlerhafte Version ist bereits installiert
Der Rollout ist angehalten, trotzdem kann ein Kunde keine Bestellung abschicken. Die fehlerhafte Version liegt schon auf seinem Telefon. Weitere Installationen zu begrenzen und ein benutzbares Produkt wiederherzustellen sind verschiedene Aufgaben. Ein mobiler Releaseplan muss beide beantworten.
Apple erlaubt, eine gestaffelte Veröffentlichung zu pausieren. Nutzer können das Update währenddessen weiterhin manuell herunterladen. Die Funktion begrenzt also die Verteilung, ersetzt aber keine bereits installierte Software. Apple beschreibt diese Steuerung in der Dokumentation.
Wir würden den Rückweg zusammen mit der Funktion planen. Lautet die einzige Antwort, einen neuen Build einzureichen, akzeptiert das Team eine Zeitspanne mit beschädigter Nutzung. Bei einem Darstellungsfehler kann das vertretbar sein. Für Bestellungen, Anmeldung oder offline erfasste Arbeit verlangt es eine eigene Entscheidung.
Installation ist noch keine Aktivierung
Eine Funktion kann in der App enthalten sein, ohne bereits für alle freigeschaltet zu werden. Ihre Aktivierung sollte eine bewusste Produktentscheidung sein. Dazu gehört jemand, der sie bei veränderter Lage wieder deaktivieren darf. Der Schalter muss einen zusammenhängenden Ablauf steuern, nicht wahllos einzelne Bedienelemente verstecken.
Ein hypothetischer Dokumentenscanner macht das deutlich. Wird der neue Scanner abgeschaltet, muss ein bestehender Uploadweg erreichbar bleiben. Angefangene Dokumente dürfen nicht verschwinden. Ein Flag, das lediglich die Schaltfläche zum Absenden entfernt, lässt den Kunden genauso feststecken wie der ursprüngliche Fehler.
Für eine nicht erreichbare Konfiguration braucht es einen sicheren Standard. In relevante Fehlermeldungen gehört neben der Appversion auch die verwendete Konfigurationsrevision. Der Support kann dann zwischen installiertem Code und aktivem Verhalten unterscheiden. Ein Rettungsmechanismus, der zwingend den ausgefallenen Dienst benötigt, hat seinen Ausfall bereits eingebaut.
Der Server trägt mehrere Generationen
Kunden aktualisieren ihre Apps nicht gemeinsam mit dem nächsten Deployment. Unterstützte ältere Versionen sind aktive Clients des Dienstes. Eine Backendänderung muss deshalb benennen, welche Anfragen weiterhin verstanden werden und welche Antwortfelder ein älterer Client sehen kann.
Für einen neuen Checkout lässt sich beispielsweise mit dem alten Client ein Warenkorb anlegen und mit dem neuen öffnen. Danach wird die Richtung getauscht. Unvollständige Vorgänge gehören ebenfalls in diese Probe. Daten, die vor einem Fehler entstanden sind, überleben häufig die Funktion, die sie erzeugt hat.
Eine zerstörende Datenänderung kann einen ansonsten vernünftigen Funktionsschalter nutzlos machen. Kann der bisherige Ablauf neue Datensätze nicht mehr lesen, stellt Abschalten ihn nicht wieder her. Informationen für den Rückweg sollten erhalten bleiben. Wann alte Darstellungen entfallen dürfen, ist eine getrennte Entscheidung.
Die Entscheidung für den Störungsfall gehört ins Release
Release Notes ersetzen keinen Ablauf für den Ernstfall. Feststehen sollten das Stoppsignal, die verantwortliche Person, die Kundeninformation und der Nachweis, dass die Wiederherstellung gelungen ist. Eine sinkende Absturzkurve beweist noch keinen korrekt abgeschlossenen Geschäftsvorgang.
Abgeschlossene Aufgaben und Supportmeldungen liefern zusätzliche Hinweise. Version und Konfiguration müssen sich den betroffenen Fällen zuordnen lassen. Verschwindet der Fehler nur deshalb, weil die gesamte Funktion entfernt wurde, ist noch nichts gewonnen. Kunden müssen ihre eigentliche Aufgabe weiterhin erledigen können.
Der unbequeme Aufwand liegt im Ersatzweg. Auch er braucht Tests, Verantwortung und einen geplanten Rückbau. Ein ungepflegter alter Ablauf ist keine Absicherung, sondern eine weitere ungeprüfte Veröffentlichung für den Notfall.
Diese Woche den Rückweg ausprobieren
Für die nächste Funktion lässt sich die Wiederherstellung vor der Verteilung aufschreiben. Den vorgesehenen Build installieren, Arbeit beginnen, die Verbindung unterbrechen und die Funktion deaktivieren. Anschliessend prüfen, welche Daten erhalten bleiben, welche Meldung erscheint und woran der Support den Zustand erkennt.
In dieselbe Probe gehört ein unterstützter älterer Client gegen das neue Backend. Jede unumkehrbare Zustandsänderung bekommt eine benannte Entscheidung. Der Plan ist belastbar, wenn ein Teammitglied ohne Beteiligung an der Implementierung damit einen benutzbaren Ablauf wiederherstellen kann, ohne Annahmen erfinden zu müssen.