Android-Update schrittweise veröffentlichen: Was ein gestaffelter Google-Play-Rollout wirklich stoppt

Ein gestaffelter Rollout kann die Verteilung eines Android-Updates zunächst auf einen Teil der Nutzer begrenzen. Er holt eine bereits installierte fehlerhafte Version aber nicht zurück. Wenn Sie eine Kunden-App entwickeln oder weiterbetreuen lassen, brauchen Sie deshalb zwei getrennte Vereinbarungen: Wer darf die Verteilung erweitern oder anhalten, und wie werden bereits betroffene Kunden unterstützt?

Dieser Artikel betrifft Updates einer vorhandenen App über Google Play. Er beschreibt weder eine Garantie für fehlerfreie Veröffentlichungen noch einen Ersatz für Tests vor der Freigabe.

Erstveröffentlichung und Update unterscheiden

Die offizielle Google-Play-Anleitung zu gestaffelten Rollouts beschreibt die Funktion für App-Updates in Produktions- und Test-Tracks. Für die erstmalige Veröffentlichung einer App steht dieser gestaffelte Ablauf laut Anleitung nicht zur Verfügung.

Fragen Sie beim Projektstart daher nicht nur nach einem kleinen Veröffentlichungsanteil, sondern nach dem konkreten Ausgangspunkt. Wird eine bestehende Kunden-App aktualisiert oder eine neue App erstmals angeboten? Ein Plan für das eine ist nicht automatisch ein ausführbarer Plan für das andere.

Lassen Sie im Übergabedokument App, Version, Track und verantwortliche Person eindeutig benennen. Eine erfolgreiche Paketübergabe an den Auftraggeber ist noch keine Aussage darüber, welcher Kundenkreis die Version erhalten kann.

Der Prozentsatz wählt keine bestimmten Kundenfirmen aus

Google beschreibt eine zufällige Auswahl neuer und bestehender Nutzer für jeden neuen Release-Rollout. Die Bereitstellung für den gewählten Anteil bedeutet außerdem nicht, dass die gesamte Gruppe das Update sofort erhält. Es kann dauern, bis die Gruppe erreicht wird.

Für eine gemeinsam genutzte Geschäfts-App ist das wichtig: Eine kleine Verteilungsquote ist keine Zusage, dass ausschließlich Ihre Pilotfirma oder Ihr eigenes Team aktualisiert wird. Vereinbaren Sie eine geeignete separate Testverteilung, wenn namentlich bestimmte Personen vorab prüfen sollen. Versprechen Sie diese Zielgruppe nicht allein aufgrund eines Produktionsprozentsatzes.

Auch eine Funktionsfreigabe im laufenden Programm ist etwas anderes. Ein serverseitiger Schalter kann etwa einen neuen Ablauf für bestimmte Firmenkonten steuern. Der Play-Rollout verteilt dagegen eine App-Version. Klären Sie beide Ebenen getrennt, wenn Ihr Projekt sie kombiniert.

Google hält außerdem fest, dass Nutzer nicht darüber benachrichtigt werden, dass sie eine Version im Rahmen eines gestaffelten Rollouts erhalten. Planen Sie nötige Hinweise für betroffene Kunden daher bewusst, statt eine solche Information vom Rollout zu erwarten.

Erweiterung braucht eine bewusste Entscheidung

Der Anteil steigt laut Google nicht automatisch. Legen Sie fest, wer ihn nach welchen Beobachtungen erhöhen darf und wer die Entscheidung bei Abwesenheit übernimmt. Eine geringe Quote ohne zuständige Person kann sonst ebenso liegen bleiben wie eine unbemerkt problematische Veröffentlichung.

Google empfiehlt, während des Rollouts Absturzberichte und Nutzerfeedback eng zu beobachten. Ergänzen Sie für Ihr Projekt eine kleine Liste geschäftlich wichtiger Aufgaben: Kann ein Kunde seine Bestellung abschließen, kann ein Teammitglied einen Auftrag öffnen, bleibt ein begonnener Entwurf erhalten? Das sind vorgeschlagene Prüfpunkte für Ihren eigenen Ablauf, keine durch die Store-Funktion garantierten Kontrollen.

Halten Sie Version und Beobachtungszeitraum bei einer Freigabeentscheidung fest. Eine unauffällige Meldung zur vorherigen Version beantwortet nicht, ob das neue Update funktioniert. Ebenso beweist das Fehlen von Beschwerden bei wenigen erreichten Nutzern nicht, dass alle Arbeitswege geprüft wurden.

Anhalten begrenzt die weitere Verteilung, nicht den vorhandenen Schaden

Hier liegt die wichtigste Grenze: Nach der Google-Anleitung erhalten beim Anhalten keine zusätzlichen Nutzer die Version aus dem bestehenden Rollout. Wer sie bereits erhalten hat, bleibt jedoch auf dieser Version.

Ein Stoppknopf ist damit kein Rücksetzknopf für installierte Apps und erst recht keine Rücknahme bereits gespeicherter Bestellungen. Fragen Sie vor der Veröffentlichung, wie Kunden mit der problematischen Version weiterarbeiten können. Braucht es einen korrigierten Build, eine kompatible Serveranpassung, eine vorübergehend verfügbare Alternative oder eine ausdrücklich geplante Funktionsabschaltung? Die geeignete Maßnahme hängt vom Fehler ab und muss technisch geprüft werden.

Google unterscheidet das Fortsetzen eines angehaltenen Rollouts, wenn das vorhandene App Bundle keine Probleme aufweist, vom Erstellen und Veröffentlichen eines neuen Releases mit einem korrigierten Bundle, wenn ein Problem vorliegt. Vereinbaren Sie deshalb keine pauschale Regel „nach kurzer Wartezeit wieder starten“. Die Entscheidung braucht einen geklärten Befund.

Länderwahl und fortgesetzte Gruppen nicht falsch verstehen

Wenn bestimmte Länder ausgewählt werden, bezieht Google die Einschränkung auf die Standorte der Google-Play-Konten. Das ist keine zugesicherte Auswahl nach dem aktuellen Aufenthaltsort oder nach dem Sitz der Kundenfirma. Nach Beginn lassen sich laut Anleitung keine Länder aus dem gestaffelten Rollout entfernen.

Beim Anhalten und anschließenden Fortsetzen bleibt die betroffene Nutzergruppe dieselbe. Beginnt ein neuer gestaffelter Release vor Abschluss des vorigen, beschreibt Google ebenfalls eine Verwendung derselben Gruppe, abhängig vom Verteilungsanteil. Erwarten Sie deshalb nicht bei jeder solchen Aktion eine frisch ausgeloste, unabhängige Testgruppe.

Was in die Abnahme der Betreuung gehört

Lassen Sie den Ablauf ohne ungeplante Änderung an der produktiven Kunden-App erklären und, soweit geeignet, in einem vorbereiteten Test-Track vorführen. Der Nachweis sollte zeigen, wer die nötige Berechtigung besitzt, welche Version gemeint ist, wie der aktuelle Anteil abgelesen wird und wer über eine Erweiterung entscheidet.

Ergänzen Sie einen besprochenen Fehlerfall: Der Rollout wird angehalten, bereits aktualisierte Geräte bleiben betroffen, und das Team benennt den nächsten verantworteten Schritt. Niemand sollte „gestoppt“ mit „alle wieder auf der alten Version“ gleichsetzen.

Nehmen Sie diese Zuständigkeiten in Ihr Briefing für Entwicklung und laufende Betreuung auf. Ein brauchbarer Updateplan endet nicht bei der Veröffentlichung, sondern erklärt auch die Grenze des Stopps und die Versorgung der bereits erreichten Nutzer.

Quellenabgrenzung

Die Google-Anleitung belegt Einsatzbereich, zufällige Auswahl, verzögerte Bereitstellung, manuelle Erweiterung, Verhalten beim Anhalten und Fortsetzen sowie die genannten Länderregeln. Geschäftsbezogene Prüfwege, dokumentierte Entscheidungsbefugnisse und ein Wiederherstellungsplan sind hier vorgeschlagene Projektanforderungen. Ein echter Produktionsrollout oder eine Fehlerbehebung an einer Kunden-App wurde für diesen Artikel nicht durchgeführt.