Eine Pause verhindert, dass ein Rollout weitere Geräte erreicht. Ein Rollback bringt betroffene Geräte zurück auf eine bekannte, stabile Version. Capgo unterstützt beides, sodass du ein Problem erst eindämmen und dann über das weitere Vorgehen entscheiden kannst.
Nutze diese Schritte, um die richtige Aktion zu wählen, deren Wirkung zu prüfen und das Risiko von Folgefehlern zu minimieren.
Wir haben 6 öffentliche Leitfäden zu Staged Rollouts und Rollbacks analysiert, die von Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform und Digia veröffentlicht wurden. Vier von sechs unterscheiden zwischen Pausieren und Zurückrollen als separate Aktionen, während zwei den Rollback überspringen oder die Pause als einziges Mittel betrachten. Keiner der sechs Leitfäden erklärt, wie man die Wiederherstellung mittels Analytics oder Device-Checks verifiziert, und keiner beschreibt einen Workflow zur Vermeidung von Folgefehlern. Die richtige Entscheidung zwischen Pause und Rollback zu treffen und deren Erfolg zu bestätigen, schließt eine Lücke, die in der öffentlichen Release-Dokumentation besteht.
Inhaltsverzeichnis
- Schritt 1: Release-Kontrollen in Capgo einrichten
- Schritt 2: Pause oder Rollback auswählen
- Schritt 3: Weitere Verbreitung pausieren, während du untersuchst
- Schritt 4: Rollback durchführen, wenn Nutzer eine stabile Version brauchen
- Schritt 5: Wiederherstellung mit Analytics und Device-Checks verifizieren
- Schritt 6: Wiederholte Vorfälle mit sichereren Release-Workflows verhindern
- FAQ
- Fazit
Schritt 1: Release-Kontrollen in Capgo einrichten
Stelle vor einem Incident sicher, dass dein Team weiß, welcher Channel das Release ausliefert und welches Bundle stabil ist. Ein Channel ist eine benannte Spur, die App-Geräte zu einem Update leitet. Ein Bundle ist der aktualisierbare Web-code, der über diese Spur gesendet wird.
In Capgo kann ein Progressive Rollout ein stabiles Bundle beibehalten, während ein separates Rollout-Target an eine ausgewählte Gruppe gesendet wird. Das gibt dir einen Kontrollpunkt, bevor das neue Bundle die breite Nutzerbasis erreicht. Überprüfe die Progressive-Rollout-Kontrollen bevor Sie eines in der Produktion aktivieren.
Notieren Sie den Release-Owner und die Signale, die den Rollout stoppen sollen. Legen Sie zum Beispiel fest, was Ihr Team tut, wenn die Update-Fehler steigen, ein wichtiger Screen nicht mehr funktioniert oder der Support meldet, dass User Aufgaben nicht abschließen können. Setzen Sie Limits basierend auf dem normalen Verhalten Ihrer App, anstatt einen Schwellenwert nur zu wählen, weil er streng klingt.
Ein OTA-Update ändert die aktualisierbaren code der App via Over-the-Air. Es ersetzt nicht die im App Store installierte native App-Binary. Der Begriff Over-the-Air-Update beschreibt diesen Delivery-Ansatz. Behalten Sie diese Grenze im Hinterkopf: Wenn ein Fix ein neues natives Plugin oder eine Änderung am nativen Setup der App erfordert, kann ein Bundle-Rollback dies nicht bereitstellen.
Bestätigen Sie vor dem Release, dass das stabile Bundle auch das erwartete ist. Prüfen Sie den Channel-Namen, das Target-Bundle und den Rollout-Status. Ein Tippfehler im Channel-Namen oder ein veraltetes Target kann dazu führen, dass man bei kritischen Entscheidungen die falschen Maßnahmen ergreift.
Bis zu diesem Punkt sollten Sie einen Release-Owner, ein bekanntes, gutes Bundle und eine schriftliche Abbruchbedingung haben. Diese Vorbereitung macht die nächste Entscheidung zu einer operativen Wahl statt zu einer hektischen Suche im Dashboard.
Das Wichtigste in Kürze: Ein Pause-Rollout begrenzt die Reichweite neuer Nutzer. Ein Rollback ändert die Version, die Nutzer erhalten sollen.
Schritt 2: Pause oder Rollback auswählen
Bei der Entscheidung zwischen Capgo Pause und Rollback stellt sich zuerst eine Frage: Willst du verhindern, dass weitere Geräte das Target erhalten, oder Geräte von einem Target entfernen, das bereits Probleme verursacht? Eine Pause begrenzt die neue Exposure. Ein Rollback entfernt das Target und bringt die Geräte beim nächsten Update-Check auf den stabilen Fallback zurück.
Wähle Pause, wenn die Beweislage unklar ist oder das Problem begrenzt scheint. Du hast vielleicht ein paar Reports, weißt aber nicht, ob der Bug nur einen Gerätetyp, einen bestimmten User-Flow oder jedes aktualisierte Gerät betrifft. Eine Pause gibt dem Team Zeit, das Signal zu analysieren, ohne weitere Geräte der Rollout-Gruppe hinzuzufügen.
Wähle Rollback, wenn das Target eindeutig unsicher für die User ist oder das Team genug Beweise hat, dass das bekannte gute Bundle sicherer ist. Eine Pause allein entfernt das fehlerhafte Target nicht von den Geräten, die bereits in der Rollout-Kohorte sind. Wenn diese User zur stabilen Version zurückkehren müssen, ist Rollback die Aktion, die ihren Update-Pfad ändert.
Die Capgo Channel CLI Referenz listet separate Pause- und Rollback-Steuerungen auf. Betrachte sie als unterschiedliche Aktionen und nicht als zwei Namen für denselben Notstopp.
| Was du siehst | Erste Aktion | Nächste Schritte |
|---|---|---|
| Frühe Fehler, unklarer Scope | Rollout pausieren | Betroffene vs. nicht betroffene Geräte vergleichen |
| Bekannter Bug betrifft die Zielgruppe | Rollback für die Zielgruppe | Prüfen, ob das stabile Bundle aktiv ist |
| Problem liegt bei nativem code oder einem Service | App-Änderung pausieren oder begrenzen, dann betroffene Ebene fixen | Prüfen, ob ein Native Build oder Service-Fix nötig ist |
| Nur eine kleine Gruppe ist betroffen, ohne dass Auswirkungen auf Nutzer bestätigt wurden | Während der Untersuchung pausieren | Erst nach Freigabe durch den Release-Owner fortsetzen |
Ein Rollback behebt keinen Backend-Ausfall und kann fehlende native Features nicht hinzufügen. Identifiziere zuerst die fehlerhafte Ebene. Wenn das Web-Bundle schuld ist, entscheide zwischen Pausieren und Revertieren, je nachdem, wie viele User sofortige Entlastung benötigen.
Schritt 3: Weitere Verbreitung pausieren, während du untersuchst
Pause, wenn du verhindern willst, dass neue Geräte der Rollout-Gruppe beitreten, aber noch nicht bereit bist, das Target für bereits enthaltene Geräte zurückzusetzen. Dies ist ein Containment-Schritt. Er verschafft dir Zeit für die Analyse, während das Problem nicht auf weitere Nutzer übergreift.
Öffne den Production-Channel und verifiziere, dass du den betroffenen Rollout bearbeitest. Pausiere ihn über das Dashboard, CLI oder das API deines Teams. Lies den Channel-Status anschließend aus. Verlasse dich nicht nur auf eine erfolgreiche Command-Ausführung; bestätige, dass der Rollout nun als pausiert angezeigt wird.
Im Progressive-Rollout-Modell von Capgo können Geräte, die bereits in der Cohort sind, nach einer Pause auf dem Rollout-Target bleiben. Neue berechtigte Geräte erhalten beim nächsten Check den stabilen Fallback. Dieser Unterschied ist wichtig: Eine Pause verhindert den Neueintritt, verschiebt die bestehende Cohort aber nicht automatisch zurück auf stable.
Erfasse als Nächstes die Release-Details, bevor du weitere Änderungen vornimmst. Notiere das Target-Bundle, den Channel, den Zeitpunkt der Pause und den ersten bekannten Fehlerbericht. Speichere Geräte- oder Session-Details, die dein Team sammeln darf. Eine klare Timeline hilft dir, die Rollout-Cohort mit Geräten auf dem stabilen Bundle zu vergleichen.
Prüfe das Problem über einen reproduzierbaren Pfad. Wenn Nutzer einen fehlgeschlagenen Login melden, teste genau diesen Flow auf einem betroffenen Gerät. Wenn die App beim Start abstürzt, prüfe, ob der Crash mit dem neuen Bundle und der Native Build-Version korreliert. Behandle Support-Meldungen nicht vorschnell als Beweis, dass das Update die Ursache ist.
Set an owner and a decision time for the investigation. A paused rollout can sit in limbo if no one owns the next move. The owner should either resume after evidence clears the release or choose rollback when the target remains unsafe.
Pro-Tipp: Informiere den Support und das Release-Team darüber, dass der Rollout pausiert ist. Andernfalls eskaliert eine Gruppe weiterhin Meldungen, während eine andere davon ausgeht, dass der Rollout bereits zurückgerollt wurde.
Inzwischen sollten keine neuen Geräte mehr in die Rollout-Kohorte aufgenommen werden. Prüfe den Channel-Status und das Verhalten eines Geräts, das vorher nicht in der Kohorte war, bevor du zum Rollback oder zur Fortsetzung übergehst.
Schritt 4: Rollback durchführen, wenn Nutzer eine stabile Version brauchen
Führe einen Rollback durch, wenn Nutzer, die bereits auf der Zielversion sind, auf ein bekannt funktionierendes Bundle zurückkehren müssen. Das ist die stärkere Reaktion als das Pausieren. Da sich dadurch ändert, was der Channel ausliefert, prüfe den ausgewählten stabilen Build, bevor du die Aktion bestätigst.
Öffne in Capgo den betroffenen Channel und prüfe die Build-Historie. Wähle die Version aus, die du wiederherstellen möchtest, und bestätige, dass es das richtige stabile Bundle für diese App und diesen Channel ist. Die Capgo- Rollback-Dokumentation beschreibt den Pfad im Dashboard und weist darauf hin, dass Geräte den ausgewählten Build beim nächsten Update-Check erhalten.
Gehe nach einem Rollback nicht davon aus, dass sich jedes Gerät sofort geändert hat. Ein Gerät muss erst nach einem Update suchen, und ein Offline-Nutzer tut das eventuell erst später. Halte den Incident offen, bis du die aktive Version des Channels geprüft und den Recovery-Pfad auf einem Gerät in der betroffenen Kohorte getestet hast.
Nutze das integrierte Bundle nur, wenn dies das beabsichtigte Recovery-Ziel ist. Es leitet Geräte auf den Web-Build zurück, der in der Native Build enthalten ist und vom letzten OTA-Bundle abweichen kann. Prüfe Kompatibilität und User-Impact, bevor du es als Recovery-Schritt wählst.
Behalte das Bundle, das den Incident verursacht hat, zur Analyse bereit, sofern dein Retention-Prozess nichts anderes vorgibt. Die Release-ID und der Commit helfen Engineers, die Änderung mit der stabilen Version zu vergleichen. Sichere relevante Logs vor dem Cleanup, besonders wenn du verstehen musst, warum der Fehler im Testing durchgerutscht ist.
Ein Rollback ist nicht für jedes Problem die richtige Lösung. Liegt die Ursache bei einer serverseitigen Dependency, repariere diesen Service. Hängt die Änderung von nativem code ab, das in den installierten Binaries fehlt, erstelle einen Native Build und nutze den App Store Release-Pfad für diese Änderung.
Schritt 5: Wiederherstellung mit Analytics und Device-Checks verifizieren
Überprüfe nach einem Pause oder Rollback das Verhalten der Geräte, anstatt die Änderung der Steuerung als Beweis für die Recovery zu werten. Prüfe zuerst den Status des aktiven Channels. Vergleiche dann die Update-Adoption, Fehler und Device-Reports zwischen dem betroffenen Release und der stabilen Version.
Die live update Analytics von Capgo helfen dir dabei, Adoptionsraten, Fehlerraten und Logs auf Geräteebene zu prüfen. Nutze diese Signale für gezielte Fragen: Erhalten neue Geräte das Target noch? Prüfen betroffene Geräte nach dem stabilen Bundle? Hat der gemeldete Fehler nach der Wiederherstellung aufgehört?
Teste den Pfad, der zum Fehler geführt hat. Ein erfolgreicher Download beweist nicht, dass die App funktioniert. Öffne den entsprechenden Screen, wiederhole die Aktion, die den Fehler ausgelöst hat, und prüfe, ob die App den erwarteten Zustand erreicht. Falls der Vorfall einen kritischen Flow betrifft, sollte eine zweite Person das Ergebnis bestätigen.
Vergleiche Äpfel mit Äpfeln. Ein allgemeiner Anstieg der Fehlerrate kann auch andere Ursachen haben, wie Service-Probleme oder Traffic-Änderungen. Filtere nach Bundle, Channel, App-Version und Gerät, sofern verfügbar. Suche nach Unterschieden, die direkt mit dem Release zusammenhängen, anstatt das neueste Update pauschal zu beschuldigen.
Prüfe auch Nutzer, die noch nicht aktualisiert haben. Diese können die Gesamtmetriken gesund erscheinen lassen, während die betroffene Gruppe weiterhin den Bug sieht. Vergleiche den Anteil der Geräte auf dem Target mit dem Anteil auf der stabilen Version und verknüpfe Support-Meldungen immer mit der tatsächlich genutzten Version.
Notiere das Ergebnis der Wiederherstellung und verbleibende Unsicherheiten. Wenn die Fehler sinken, aber einige Nutzer weiterhin dasselbe Problem melden, schließe den Incident erst, wenn klar ist, ob sie offline sind, eine ältere Native Build nutzen oder immer noch das betroffene Bundle verwenden.
Die Wiederherstellung gilt als bestätigt, wenn der Channel auf die gewünschte Version zeigt und der fehlerhafte User Path auf einem Gerät, das das Problem reproduzieren konnte, funktioniert. Metriken helfen, das Ausmaß des Problems zu verstehen; ein Device-Check bestätigt, was der Nutzer tatsächlich erlebt.
Schritt 6: Wiederholte Vorfälle mit sichereren Release-Workflows verhindern
Integrieren Sie Pause und Rollback bereits vor dem Publishing in Ihren Release-Plan. Ein Release Owner sollte wissen, wer die Ausrollung stoppen und wer die Rückkehr zum Stable-Status freigeben kann. Das vermeidet typische Verzögerungen: das Warten auf ein Meeting, während immer mehr Geräte in den Rollout laufen.
Halten Sie einen stabilen Fallback bereit, während das Rollout-Target getestet wird. Nutzen Sie zuerst eine kleine, definierte Kohorte und erweitern Sie diese erst, wenn die vereinbarten Health Signals innerhalb Ihrer Limits bleiben. Capgo unterstützt die kanalbasierte Release-Steuerung, sodass Teams Testing und breiten Production-Rollout trennen können.
Integrieren Sie Release-Checks in die CI/CD-Pipeline, den automatisierten Prozess für Tests und Deployments. Eine Pipeline kann das Bundle nach erfolgreichen Tests in den richtigen Channel pushen. Sie sollte zudem sicher fehlschlagen, falls der Channel falsch ist oder das Release noch nicht bereit für das Promotion ist.
Ein Continuous-Delivery-Workflow hält Software durch Automatisierung jederzeit bereit. Achten Sie bei einem OTA-Workflow darauf, dass der menschliche Freigabepunkt klar definiert bleibt, auch wenn das Publishing automatisiert ist. Automatisierung sollte die gewählte Aktion wiederholbar machen, nicht die Entscheidung für eine nicht geprüfte Änderung übernehmen.
Mit Capgo kann ein Deployment mit einem Befehl ein Bundle in einen Channel veröffentlichen. Halte den Befehl im selben Release-Prozess wie deine Checks und mach den Ziel-Channel im Deployment-Eintrag sichtbar. So sieht der On-Call-Engineer genau, was ausgeliefert wurde, ohne raten zu müssen, welche Lane es bekommen hat.
Bevor du automatische Safeguards aktivierst, definiere, welches Signal sie auslöst und welche Aktion sie ausführen. Eine Pause kann neue Exposition stoppen, während Geräte der aktuellen Kohorte auf dem Ziel bleiben. Ein Rollback kann Geräte in Richtung stable lenken. Diese Ergebnisse unterscheiden sich, also konfiguriere nicht das eine, als wäre es das andere.
Nutze einen Test-Channel, um die komplette Reaktion zu üben. Veröffentliche eine harmlose Änderung, prüfe die Pause-Steuerung und teste dann den Rollback auf das vorherige Bundle. Bestätige nach jeder Aktion das App-Verhalten auf einem Gerät. Ein schriftliches Runbook sollte den Channel, den Befehl bzw. Dashboard-Pfad, den erwarteten Zustand und die Person, die den Erfolg bestätigt, enthalten.
Release-Notes sollten das Bundle und seinen Zweck benennen. Halte eine Verbindung zwischen dem Deployment-Eintrag und der Code-Änderung, damit Engineers die Suche bei Fehlern eingrenzen können. Wenn dein Team Incidents über Zeitzonen hinweg übergibt, nimm die letzte durchgeführte Aktion und den nächsten Entscheider auf.
Wenn der Incident auf einen breiteren Engpass in der Frontend-Implementierung hindeutet, könnte ein Web-Entwickler wie Amir Arezoo für die Website-Entwicklung relevant sein. Das ist unabhängig von den Rollout-Controls von Capgo, die Auslieferung und Recovery für kompatible App-Updates übernehmen.
Mittlerweile sollte dein Release-Prozess einen stabilen Fallback, einen Verantwortlichen, eine Abbruchregel und eine getestete Recovery-Aktion enthalten. Halte den Workflow kurz genug, dass der On-Call-Engineer ihn auch unter Druck nutzen kann.
FAQ
Rollt das Pausieren eines Capgo Rollouts bereits aktualisierte Geräte zurück?
Nein. Das Pausieren verhindert, dass neue berechtigte Geräte in den Rollout kommen, aber Geräte, die bereits in der Cohort sind, können auf dem Ziel-Bundle bleiben. Um diese Nutzer zurück auf stable zu bringen, nutze ein Rollback oder eine andere gezielte Channel-Aktion. Prüfe nach der jeweiligen Änderung den Channel-Status und bestätige das Ergebnis auf einem Gerät, das das Ziel-Bundle erhalten hat.
Wann sollte ich pausieren statt ein Rollback durchzuführen?
Pausiere, wenn das Problem noch untersucht wird und du die weitere Reichweite stoppen musst. Rolle zurück, wenn bekannt ist, dass das Ziel-Bundle Nutzern schadet oder betroffene Geräte ein stabiles Bundle brauchen. Die Wahl zwischen Pause und Rollback bei einem Capgo Rollout hängt davon ab, ob du zuerst Containment brauchst oder Recovery für die bestehende Cohort.
Aktualisiert ein Rollback jedes Gerät sofort?
Nein. Ein Rollback ändert das Bundle, auf das der Channel zeigt, aber die Geräte erhalten es erst beim nächsten Update-Check. Ein Offline-Gerät bleibt auf seinem aktuellen Bundle, bis es wieder eine Verbindung hat. Prüfe das Channel-Ziel und dann die betroffenen Geräte samt Update-Status, bevor du den Incident als gelöst markierst.
Kann ein OTA-Rollback ein Problem der nativen App beheben?
Nein. Ein OTA-Rollback kann ein früheres updatefähiges Web-Bundle wiederherstellen, aber er kann keine nativen code innerhalb einer installierten App-Binary hinzufügen oder entfernen. Wenn das Problem von einem nativen Plugin oder einer Änderung am App-Shell kommt, prüfe, ob ein neuer Native Build nötig ist. Identifiziere zuerst, welche Ebene den Fehler verursacht hat.
Was sollte ich nach einem Pause oder Rollback prüfen?
Bestätige den Status des Channels und das aktive Bundle, dann prüfe die Update-Adoption und Fehler pro Release. Teste den User Journey, der fehlgeschlagen ist, auf einem Gerät der betroffenen Gruppe. Prüfe auch Geräte, die noch nicht aktualisiert haben, da Gesamtmetriken Probleme verbergen können, die nur eine Version oder Kohorte betreffen.
Fazit
Nutze Pause, um die Verbreitung zu stoppen, während du untersuchst. Nutze Rollback, wenn Nutzer im Ziel-Channel eine stabile Version benötigen. Richte beide Funktionen vorab ein und teste sie auf einem Test-Channel vor deinem nächsten Production-Release.
