Warum du deine Mobile App nicht auf einmal an alle ausrollen solltest

Dein App-Release wurde gerade vom Store freigegeben. Dein Team hat auf diesen Moment gewartet. Der natürliche Impuls ist, auf "Für alle Benutzer veröffentlichen" zu klicken und zur nächsten Funktion überzugehen. Aber hier ist, was passiert, wenn du das tust: Ein Absturz, der nur auf Geräten mit Android 12 und 4 GB RAM auftritt, trifft jeden einzelnen dieser Benutzer gleichzeitig. Du erfährst es erst, wenn dein Crash-Monitoring-Dashboard rot aufleuchtet, und bis dahin haben bereits Hunderte oder Tausende von Benutzern eine miserable Erfahrung gemacht.

Dies ist kein hypothetisches Szenario. Es passiert regelmäßig. Die Lösung ist nicht einfach besseres Testen. Die Lösung ist, die Art und Weise zu ändern, wie du veröffentlichst: Statt einem großen Push veröffentlichst du zuerst für eine kleine Gruppe, beobachtest, was passiert, und erweiterst dann schrittweise.

Das Problem mit der Veröffentlichung für alle

Wenn du für alle Benutzer auf einmal veröffentlichst, gibst du dein Sicherheitsnetz auf. Der App-Store-Review-Prozess fängt offensichtliche Probleme ab, aber er kann nicht alles abfangen. Gerätespezifische Abstürze, Inkompatibilitäten mit Betriebssystemversionen, Probleme mit Netzwerkbedingungen und subtile Performance-Regressionen schlüpfen oft durch. Diese Probleme treten erst auf, wenn echte Benutzer die App auf echten Geräten unter realen Bedingungen ausführen.

Das Risiko sind nicht nur Abstürze. Eine Funktion, die im Staging einwandfrei funktioniert, kann sich anders verhalten, wenn Tausende von Benutzern gleichzeitig darauf zugreifen. Eine Datenbankabfrage, die mit Testdaten schnell war, kann mit Produktionsdatenmengen extrem langsam werden. Ein API-Aufruf, der während der Entwicklung einwandfrei funktionierte, kann unter realer Netzwerklatenz fehlschlagen.

Für alle zu veröffentlichen bedeutet, diese Probleme auf die harte Tour zu finden: alle auf einmal, ohne die Möglichkeit, den Schaden zu stoppen.

Staged Rollout und Phased Release

Hier kommen Staged Rollout und Phased Release ins Spiel. Beides sind Mechanismen, um eine neue Version zuerst für eine Teilmenge der Benutzer freizugeben, die Auswirkungen zu überwachen und dann schrittweise auf den Rest auszuweiten. Android nennt es Staged Rollout. iOS nennt es Phased Release. Das Konzept ist dasselbe, aber die Implementierung unterscheidet sich.

Die Kernidee ist einfach: Reduziere den Schadensradius. Wenn etwas schiefgeht, ist nur ein kleiner Prozentsatz der Benutzer betroffen. Du hast Zeit, das Problem zu erkennen, das Release zurückzuziehen und es zu beheben, bevor sich der Schaden ausbreitet.

Das folgende Flussdiagramm veranschaulicht den typischen Staged-Rollout-Prozess mit Überwachungs-Checkpoints und Rollback-Entscheidungen:

flowchart TD A[Release an 1% der Nutzer] --> B[Überwache Absturzrate & Fehler] B --> C{Stabil?} C -->|Ja| D[Ausweiten auf 5%] C -->|Nein| E[Rollout stoppen & Team benachrichtigen] D --> F[Überwache Absturzrate & Fehler] F --> G{Stabil?} G -->|Ja| H[Ausweiten auf 20%] G -->|Nein| E H --> I[Überwache Absturzrate & Fehler] I --> J{Stabil?} J -->|Ja| K[Ausweiten auf 100%] J -->|Nein| E

Wie Staged Rollout auf Android funktioniert

In der Google Play Console kannst du mit dem Staged Rollout den Prozentsatz der Benutzer wählen, die das Update erhalten. Du könntest mit 10 Prozent beginnen. Deine CI/CD-Pipeline kann dies automatisieren, indem sie die neue Version über die Google Play Console API an einen bestimmten Track sendet.

So sieht ein typischer Staged Rollout in der Praxis aus:

  1. Die Pipeline erstellt die Release-Version und führt automatisierte Tests aus.
  2. Die Pipeline lädt den Build in den Staged-Rollout-Track mit 10 Prozent hoch.
  3. Die Pipeline wartet 48 Stunden, während sie Absturzraten und Fehlerberichte überwacht.
  4. Wenn alles normal aussieht, weitet die Pipeline auf 25 Prozent aus.
  5. Nach einem weiteren Überwachungszeitraum auf 50 Prozent ausweiten.
  6. Schließlich auf 100 Prozent ausweiten.

Wenn die Absturzrate zu irgendeinem Zeitpunkt ansteigt oder die Fehlerberichte signifikant zunehmen, kann die Pipeline den Rollout anhalten und das Team benachrichtigen. Du kannst den Rollout auch manuell über die Play Console stoppen, wenn du ein Problem bemerkst, bevor die automatischen Prüfungen es erkennen.

Der Hauptvorteil bei Android ist die Kontrolle. Du bestimmst die Prozentsätze und den Zeitplan. Du kannst schnell vorankommen, wenn alles gut aussieht, und pausieren oder stoppen, wenn nicht.

Wie Phased Release auf iOS funktioniert

Apple verfolgt einen anderen Ansatz. Beim Phased Release kontrolliert Apple den Zeitplan. Du aktivierst die Option in App Store Connect, wenn du die neue Version einreichst. Nach der Freigabe veröffentlicht Apple das Update am ersten Tag für einen kleinen Prozentsatz der Benutzer und weitet es dann schrittweise über sieben Tage aus.

Du kannst die Prozentsätze nicht manuell festlegen wie bei Android. Du kannst den Rollout nicht beschleunigen, wenn alles sauber aussieht. Aber du kannst die Auswirkungen dennoch über App Store Connect Analytics oder Drittanbieter-Tools wie Firebase Crashlytics überwachen.

Wenn du während des Phased Release ein Problem entdeckst, kannst du die Version aus App Store Connect zurückziehen, bevor alle Benutzer sie erhalten. Dies ist das kritische Sicherheitsnetz. Auch wenn du weniger Kontrolle über die Rollout-Geschwindigkeit hast, hast du dennoch die Möglichkeit, den Schaden zu stoppen.

Das Sieben-Tage-Fenster mag sich langsam anfühlen, besonders wenn du darauf brennst, eine Funktion auszuliefern. Aber bedenke die Alternative: Für alle veröffentlichen und einen kritischen Fehler entdecken, nachdem bereits 100.000 Benutzer das Update heruntergeladen haben.

Automatisierung des Staged Rollout in deiner Pipeline

Deine CI/CD-Pipeline kann den gesamten Staged-Rollout-Prozess automatisch abwickeln. Hier ist ein praktischer Ansatz für Android:

  1. Erstelle und signiere das Release-APK oder AAB.
  2. Lade es über die API in die Google Play Console hoch und ziele auf den Staged-Rollout-Track.
  3. Setze den anfänglichen Prozentsatz auf 10 Prozent.
  4. Warte auf einen definierten Überwachungszeitraum, typischerweise 24 bis 48 Stunden.
  5. Überprüfe Metriken von Firebase Crashlytics oder deinem Crash-Reporting-Tool.
  6. Entscheide: Wenn die Absturzrate unter dem Schwellenwert liegt, auf den nächsten Prozentsatz ausweiten. Wenn darüber, anhalten und benachrichtigen.
  7. Wiederhole den Vorgang, bis 100 Prozent erreicht sind.

Für iOS ist die Automatisierung einfacher, da du keine Prozentsätze steuern kannst. Deine Pipeline kann:

Hier ist ein YAML-Ausschnitt für einen GitHub Actions-Job, der einen Android-Build hochlädt und einen 10%igen Staged Rollout einrichtet:

- name: Upload to Google Play (10% staged rollout)
  uses: r0adkll/upload-google-play@v1
  with:
    serviceAccountJsonPlainText: ${{ secrets.PLAY_SERVICE_ACCOUNT_JSON }}
    packageName: com.example.app
    releaseFiles: app/build/outputs/bundle/release/app-release.aab
    track: production
    userFraction: 0.1
    releaseStatus: completed

Dieser Schritt verwendet den Parameter userFraction, um den Rollout auf 10% der Benutzer zu beschränken. Die Pipeline kann diesen Anteil nach der Überwachung später erweitern.

  1. Erstelle und signiere das IPA.
  2. Lade es in App Store Connect hoch.
  3. Aktiviere Phased Release bei der Einreichung.
  4. Überwache Absturzraten und Analysen während des Sieben-Tage-Fensters.
  5. Ziehe das Release zurück, wenn Probleme auftreten.

Die Pipeline ersetzt nicht das menschliche Urteilsvermögen. Sie übernimmt die mechanischen Teile: Hochladen, Warten, Überprüfen von Metriken und Ausweiten. Das Team muss dennoch Absturzberichte prüfen, Anomalien untersuchen und die endgültige Entscheidung treffen, ob fortgefahren oder angehalten wird.

Was Staged Rollout nicht ist

Staged Rollout ist kein Ersatz für ordentliches Testen. Du brauchst weiterhin Unit-Tests, Integrationstests und manuelles QA, bevor du die App im Store einreichst. Staged Rollout ist die letzte Verteidigungslinie, nicht die erste.

Staged Rollout ist auch kein Weg, um kaputten Code auszuliefern und auf das Beste zu hoffen. Das Ziel ist es, die Probleme zu fangen, die trotz deiner besten Testbemühungen durchrutschen. Wenn du dich darauf verlässt, dass der Staged Rollout grundlegende Fehler abfängt, muss dein Testprozess verbessert werden.

Praktische Checkliste für dein nächstes Release

  • Richte Crash-Monitoring mit Alarmen vor dem Release ein.
  • Definiere deinen Schwellenwert für die Absturzrate, um den Rollout zu stoppen.
  • Konfiguriere deine Pipeline so, dass sie in den Staged-Rollout-Track hochlädt.
  • Setze den anfänglichen Prozentsatz auf 10 Prozent oder niedriger.
  • Definiere den Überwachungszeitraum zwischen den Ausweitungen.
  • Teste den Stopp-Mechanismus: Kannst du den Rollout schnell anhalten?
  • Weise jemanden zu, der die Absturzberichte während des Rollout-Fensters überwacht.
  • Dokumentiere den Rollback-Prozess für den Fall, dass du das Release zurückziehen musst.

Die Erkenntnis

Eine Mobile App für alle Benutzer auf einmal zu veröffentlichen, ist ein Glücksspiel, das du nicht eingehen musst. Staged Rollout und Phased Release geben dir einen kontrollierten, beobachtbaren Weg von null bis zur vollständigen Bereitstellung. Du tauschst ein paar zusätzliche Tage Rollout-Zeit gegen die Fähigkeit, Probleme zu erkennen, bevor sie alle betreffen. Dieser Tausch ist fast immer wert.

Wenn deine App das nächste Mal freigegeben wird, widerstehe dem Drang, sie für alle zu veröffentlichen. Fang klein an, beobachte die Metriken und weite nur aus, wenn du sicher bist. Deine Benutzer werden nie erfahren, dass du zurückgehalten hast, aber sie werden es bemerken, wenn die App am Starttag nicht abstürzt.