Eine Pause verhindert, dass der Rollout weitere Geräte erreicht. Ein Rollback bringt betroffene Geräte auf eine bekannt funktionierende Version. Capgo unterstützt beides, sodass du ein Problem erst eindämmen und dann das weitere Vorgehen entscheiden kannst.
Nutze diese Schritte, um die richtige Maßnahme zu wählen, deren Wirkung zu prüfen und das Risiko eines erneuten Vorfalls zu minimieren.
Wir haben 6 öffentliche Leitfäden zu Staged Rollouts und Rollbacks gelesen, veröffentlicht von Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform und Digia. Vier von sechs unterscheiden Pausieren und Rollback als separate Aktionen, während zwei Rollback überspringen oder Pausieren als einzigen Hebel sehen. Keiner der 6 erklärt, wie man die Wiederherstellung mit Analytics oder Device-Checks verifiziert, und keiner beschreibt einen Workflow, um wiederkehrende Vorfälle zu verhindern. Die Wahl zwischen Pausieren und Rollback richtig zu treffen und dann zu bestätigen, dass sie funktioniert hat, schließt eine Lücke, die öffentliche Release-Leitfäden offen lassen.
Inhaltsverzeichnis
- Schritt 1: Release-Kontrollen in Capgo einrichten
- Schritt 2: Pause oder Rollback wählen
- Schritt 3: Weitere Verbreitung stoppen, während du untersuchst
- Schritt 4: Rollback, wenn Nutzer eine stabile Version benötigen
- Schritt 5: Recovery mit Analytics und Device-Checks verifizieren
- Schritt 6: Wiederholte Incidents durch sicherere Release-Workflows verhindern
- FAQ
- Fazit
Schritt 1: Release-Kontrollen in Capgo einrichten
Bevor ein Vorfall eintritt, stellt sicher, dass euer 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 das aktualisierbare Web-code, das über diese Spur gesendet wird.
In Capgo kann ein progressiver Rollout ein stabiles Bundle unverändert lassen, während ein separates Rollout-Ziel an eine ausgewählte Gruppe geht. Das gibt euch einen Kontrollpunkt, bevor das neue Bundle die breitere Nutzerbasis erreicht. Prüft die Kontrollen für progressive Rollouts bevor ihr sie in Produktion aktiviert.
Haltet den Release-Owner und die Signale fest, die eine Ausweitung stoppen sollten. Entscheidet zum Beispiel, was euer Team tut, wenn Update-Fehler zunehmen, ein wichtiger Screen nicht mehr funktioniert oder der Support meldet, dass Nutzer eine Aufgabe nicht abschließen können. Setzt Grenzen basierend auf dem normalen Verhalten eurer App, statt einen Schwellenwert nur zu wählen, weil er streng klingt.
Ein OTA-Update ändert den aktualisierbaren code der App over the air. Es ersetzt nicht das native App-Binary, das aus einem App Store installiert wurde. Der Begriff Over-the-Air-Update beschreibt diese Auslieferungsart. Behaltet diese Grenze im Hinterkopf: Wenn ein Fix ein neues natives Plugin oder eine Änderung an der nativen App-Konfiguration braucht, liefert ein Bundle-Rollback das nicht.
Stellt vor dem Release sicher, dass das stabile Bundle das erwartete ist. Prüft Channel-Namen, Ziel-Bundle und Rollout-Status. Ein Tippfehler im Channel-Namen oder ein veraltetes Ziel kann dazu führen, dass das Team im Ernstfall an der falschen Stelle eingreift, wenn es auf Minuten ankommt.
Zu diesem Zeitpunkt sollten Sie einen benannten Release-Owner, ein bekanntes, funktionierendes Bundle und eine schriftliche Stoppbedingung haben. Diese Vorbereitung macht die nächste Entscheidung zu einer operativen Wahl und nicht zu einem hektischen Suchen im Dashboard.
Das Wichtigste in Kürze: Ein Pause begrenzt die neue Exposition. Ein Rollback ändert die Version, die den Nutzern zugewiesen wird.
Schritt 2: Pause oder Rollback wählen
Für die Entscheidung zwischen Pause und Rollback bei Capgo stellen Sie zuerst eine Frage: Möchten Sie verhindern, dass weitere Geräte das Ziel erhalten, oder Geräte von einem Ziel entfernen, das bereits Schaden verursacht? Ein Pause begrenzt die neue Exposition. Ein Rollback entfernt das Ziel und leitet Geräte beim nächsten Update-Check an das stabile Fallback zurück.
Wählen Sie Pause, wenn die Beweislage unvollständig ist oder das Problem begrenzt erscheint. Möglicherweise haben Sie nur wenige Berichte, wissen aber nicht, ob der Bug einen Gerätetyp, einen bestimmten Nutzerfluss oder jedes aktualisierte Gerät betrifft. Eine Pause gibt dem Team Zeit, das Signal zu untersuchen, ohne neue Geräte zur Rollout-Gruppe hinzuzufügen.
Wählen Sie Rollback, wenn das Ziel für Nutzer eindeutig unsicher ist oder das Team genug Belege dafür hat, dass der bekannte stabile Bundle sicherer ist. Ein Pause entfernt das fehlerhafte Ziel nicht von Geräten, die bereits in der Rollout-Gruppe sind. Wenn diese Nutzer zu einer stabilen Version zurückkehren müssen, ist Rollback die Aktion, die ihren Update-Pfad ändert.
Der Capgo Kanal CLI Referenz listet separate Steuerelemente für Pause und Rollback auf. Behandeln Sie sie als unterschiedliche Aktionen, nicht als zwei Namen für denselben Notstopp.
| Was Sie sehen | Erste Aktion | Was als Nächstes zu prüfen ist |
|---|---|---|
| Frühe Fehler, unklarer Umfang | Rollout pausieren | Betroffene und unbetroffene Geräte vergleichen |
| Bekannter Bug, der die Zielgruppe betrifft | Rollback für die Zielgruppe | Prüfen, ob das stabile Bundle aktiv ist |
| Problem mit nativem code oder einem Dienst | App-Änderung pausieren oder begrenzen, dann die betroffene Ebene fixen | Prüfen, ob ein Native Build oder Service-Fix nötig ist |
| Nur eine kleine Gruppe hat das Target, keine User-Auswirkungen bestätigt | Während der Untersuchung pausieren | Erst nach Freigabe durch den Release-Owner fortsetzen |
Ein Rollback behebt keinen Backend-Ausfall und kann fehlende native Funktionen nicht hinzufügen. Identifiziere zuerst die fehlerhafte Ebene. Wenn das Web-Bundle schuld ist, entscheide zwischen Pausieren und Revertieren – je nachdem, wie viele User Entlastung brauchen.
Schritt 3: Weitere Verbreitung stoppen, während du untersuchst
Pause, wenn du verhindern musst, dass neue Geräte in die Rollout-Gruppe einsteigen, aber noch nicht bereit bist, das Ziel für Geräte, die bereits darin sind, zurückzusetzen. Dies ist eine Eindämmungsmaßnahme. Sie verschafft dir Zeit, die Fakten zu prüfen, während das Problem nicht auf weitere Nutzer ausweitet.
Öffne den Produktionskanal und stelle sicher, dass du den betroffenen Rollout bearbeitest. Pausiere ihn über das Dashboard, CLI oder die API-Steuerung, die dein Team nutzt. Lies anschließend den Kanalstatus zurück. Verlasse dich nicht nur darauf, dass ein Befehl erfolgreich abgeschlossen wurde; bestätige, dass der Rollout nun als pausiert angezeigt wird.
Im progressiven Rollout-Modell von Capgo können Geräte, die bereits in der Kohorte sind, nach einer Pause beim Rollout-Ziel bleiben. Neue berechtigte Geräte erhalten beim nächsten Check das stabile Fallback. Dieser Unterschied ist wichtig: Eine Pause stoppt nur den neuen Zustrom, verschiebt die bestehende Kohorte aber nicht automatisch zurück auf stabil.
Erfasse als Nächstes die Release-Details, bevor du weitere Änderungen vornimmst. Notiere das Ziel-Bundle, den Channel, die Pausezeit und den ersten bekannten Bericht. Halte dich an die Geräte- oder Session-Details, die dein Team erfassen darf. Eine klare Timeline hilft dir, die Rollout-Kohorte mit Geräten zu vergleichen, die noch auf dem stabilen Bundle laufen.
Prüfe das Problem über einen reproduzierbaren Pfad. Wenn Nutzer einen fehlgeschlagenen Login melden, teste genau diese Journey auf einem betroffenen Gerät. Wenn die App beim Start abstürzt, prüfe, ob der Crash mit dem neuen Bundle und der nativen App-Version übereinstimmt. Behandle nicht jeden Support-Bericht als Beweis, dass das Update das Problem verursacht hat.
Bestimme einen Verantwortlichen und einen Entscheidungszeitpunkt für die Untersuchung. Ein pausierter Rollout kann in der Schwebe bleiben, wenn niemand den nächsten Schritt verantwortet. Der Verantwortliche sollte entweder nach klärenden Beweisen fortsetzen oder einen Rollback wählen, wenn das Ziel weiterhin unsicher ist.
Pro-Tipp: Informiere Support und Release-Team, dass der Rollout pausiert ist. Sonst eskaliert eine Gruppe weiter Meldungen, während die andere annimmt, der Rollout sei bereits zurückgerollt.
Mittlerweile 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 zurückrollst oder fortsetzt.
Schritt 4: Rollback, wenn Nutzer eine stabile Version benötigen
Führe einen Rollback durch, wenn Nutzer, die bereits auf dem Ziel-Release sind, zu einem Known-Good-Bundle zurückkehren müssen. Das ist die stärkere Reaktion als Pausieren. Es ändert, was der Channel ausliefert; prüfe daher den ausgewählten stabilen Build, bevor du die Aktion bestätigst.
Öffne in Capgo den betroffenen Channel und sieh dir die Build-Historie an. 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 Weg 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 umgestellt 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 das dein beabsichtigtes Recovery-Ziel ist. Es leitet Geräte auf den Web-Build zurück, der in der nativen App enthalten ist und sich vom letzten OTA-Bundle unterscheiden kann. Prüfe Kompatibilität und die Auswirkungen auf die Nutzer, bevor du es als Recovery-Schritt wählst.
Halte das Bundle, das den Incident verursacht hat, für die Analyse verfügbar, sofern dein Retention-Prozess nichts anderes vorgibt. Release-ID und Commit helfen Entwicklern, die Änderung mit der stabilen Version zu vergleichen. Sichere relevante Logs vor dem Cleanup, besonders wenn du verstehen musst, warum das Problem in den Tests nicht aufgefallen ist.
Ein Rollback ist nicht für jeden Fehler die richtige Lösung. Wenn die Ursache eine serverseitige Abhängigkeit ist, repariere diesen Service. Wenn die Änderung native code voraussetzt, die in den installierten Binaries fehlen, erstelle einen Native Build und veröffentliche die Änderung über den regulären App-Store-Release-Weg.
Schritt 5: Recovery mit Analytics und Device-Checks verifizieren
Verifiziere nach einer Pause oder einem Rollback, was die Geräte tun, statt die Änderung der Steuerung als Beweis für die Recovery zu werten. Prüfe zuerst den Status des aktiven Channels. Vergleiche dann Update-Adoption, Fehler und Device-Reports zwischen dem betroffenen Release und der stabilen Version.
Die live update Analytics von Capgo helfen dir, Adoptionsmetriken, Fehlerraten und Logs auf Geräteebene zu prüfen. Mit diesen Signalen beantwortest du konkrete Fragen: Erhalten neue Geräte das Target noch, prüfen betroffene Geräte auf das stabile Bundle, und hat der gemeldete Fehler nach der Wiederherstellung aufgehört?
Teste den User-Pfad, der fehlgeschlagen ist. Ein erfolgreicher Download beweist nicht, dass die App funktioniert. Öffne den entsprechenden Screen, wiederhole die Aktion, die zu der Meldung geführt hat, und prüfe, ob die App den erwarteten Zustand erreicht. Bei kritischen Flows sollte jemand das Ergebnis bestätigen, der die Änderung nicht selbst gemacht hat.
Vergleiche nur Vergleichbares. Eine globale Fehlerzählung kann aus Gründen steigen, die nichts mit dem Release zu tun haben, etwa ein Service-Problem oder verändertes Traffic-Aufkommen. Filtere nach Bundle, Channel, App-Version und Gerät, sofern diese Felder verfügbar sind. Suche nach einem Unterschied, der mit dem Release zusammenhängt, statt standardmäßig das neueste Update verantwortlich zu machen.
Prüfe auch Nutzer, die noch nicht aktualisiert haben. Sie können die Gesamtmetriken gesund aussehen lassen, während die betroffene Gruppe den Bug weiterhin sieht. Vergleiche den Anteil der Geräte auf dem Target mit dem Anteil auf stable und verknüpfe Support-Meldungen immer mit der Version, die Nutzer tatsächlich ausführen.
Halte das Ergebnis der Wiederherstellung und die verbleibende Unsicherheit fest. Wenn die Fehler sinken, aber einige Nutzer das Problem weiterhin melden, schließe den Incident erst ab, wenn du verstehst, ob sie offline sind, eine ältere native Shell nutzen oder noch das betroffene Bundle verwenden.
Die Wiederherstellung ist bestätigt, wenn der Channel auf die vorgesehene Version zeigt und der fehlerhafte User-Pfad auf einem Gerät funktioniert, das das Problem reproduzieren konnte. Metriken zeigen dir die Form des Problems; ein Device-Check bestätigt, was ein Mensch tatsächlich erlebt.
Schritt 6: Wiederholte Incidents durch sicherere Release-Workflows verhindern
Machen Sie Pause und Rollback schon vor dem Publishing zum Teil des Release-Plans. Ein Release-Owner sollte wissen, wer die Auslieferung stoppen und wer die Rückkehr zu Stable freigeben kann. Das beseitigt eine häufige Verzögerung: auf ein Meeting zu warten, während immer mehr Geräte in den Rollout kommen.
Halten Sie einen stabilen Fallback zugewiesen, während das Rollout-Ziel getestet wird. Nutzen Sie zuerst eine kleine, definierte Kohorte und erweitern Sie erst, wenn die vereinbarten Health-Signale innerhalb Ihrer Grenzwerte bleiben. Capgo unterstützt die channelbasierte Release-Steuerung, sodass Teams Testing und breite Production-Delivery sauber trennen können.
Integrieren Sie Release-Checks in CI/CD, den automatisierten Prozess, der Tests ausführt und eine Änderung deployt. Eine Pipeline kann das Bundle nach erfolgreichen Tests im vorgesehenen Channel veröffentlichen. Sie sollte außerdem sicher fehlschlagen, wenn der Channel falsch ist oder das Release noch nicht für die Promotion bereit ist.
Ein Continuous-Delivery-Workflow hält Software durch einen automatisierten Prozess jederzeit release-bereit. Bei einem OTA-Workflow sollte der Punkt der menschlichen Freigabe klar bleiben, auch wenn das Publishing automatisiert ist. Automatisierung sollte die gewählte Aktion wiederholbar machen, nicht die Entscheidung für eine ungeprüfte Änderung treffen.
Mit Capgo kann ein Deployment mit einem einzigen Befehl ein Bundle in einen Channel veröffentlichen. Behalte den Befehl im selben Release-Prozess wie deine Checks und mache 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 erhalten hat.
Bevor du automatische Safeguards aktivierst, definiere, welches Signal sie auslöst und welche Aktion sie ausführen. Eine Pause stoppt die weitere Verteilung, während die Geräte der aktuellen Kohorte auf dem Ziel bleiben. Ein Rollback leitet Geräte auf stable um. Diese Ergebnisse unterscheiden sich, also konfiguriere nicht das eine wie das andere.
Nutze einen Test-Channel, um die komplette Reaktion durchzuspielen. Veröffentliche eine harmlose Änderung, prüfe die Pause-Steuerung und teste dann den Rollback auf das vorherige Bundle. Bestätige das App-Verhalten auf einem Gerät nach jeder Aktion. Ein schriftliches Runbook sollte den Channel, den Befehl oder 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 einem Fehler eingrenzen können. Wenn dein Team Incidents über Zeitzonen hinweg übergibt, dokumentiere die letzte durchgeführte Aktion und wer die nächste Entscheidung verantwortet.
Falls 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 die Auslieferung und Recovery für kompatible App-Updates übernehmen.
Mittlerweile sollte dein Release-Prozess einen stabilen Fallback, einen Verantwortlichen, eine Stop-Regel und eine getestete Recovery-Aktion enthalten. Halte den Workflow so kurz, dass der On-Call-Engineer ihn auch unter Druck nutzen kann.
FAQ
Setzt 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 Kohorte sind, können auf dem Ziel-Bundle bleiben. Um diese Nutzer zurück auf stable zu bringen, nutze ein Rollback oder eine andere bewusste Channel-Aktion. Prüfe den Channel-Status nach der Änderung 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. Mach ein Rollback, wenn bekannt ist, dass das Ziel-Bundle Nutzern schadet oder betroffene Geräte ein stabiles Bundle brauchen. Die Entscheidung Capgo Pause Rollout vs. Rollback hängt davon ab, ob es dir eher um Eindämmung oder um Recovery für die bestehende Kohorte geht.
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 Gerät, das offline ist, bleibt auf seinem aktuellen Bundle, bis es wieder online geht. Prüfe, auf welches Bundle der Channel zeigt, und checke dann die betroffenen Geräte und ihren Update-Status, bevor du den Incident als gelöst erklärst.
Kann ein OTA-Rollback ein Problem der Native App beheben?
Nein. Ein OTA-Rollback kann ein früheres, aktualisierbares Web-Bundle wiederherstellen, aber keine nativen code in einer installierten App-Binary hinzufügen oder entfernen. Wenn das Problem von einer nativen Plugin- oder App-Shell-Änderung stammt, bewerten Sie, ob ein neuer nativer Build erforderlich ist. Identifizieren Sie zunächst, welche Ebene den Fehler verursacht hat.
Was sollte ich nach dem Pausieren oder Rollback prüfen?
Bestätige den Zustand des Channels und das aktive Bundle, dann prüfe die Update-Adoption und Fehler pro Release. Teste die User Journey, die auf einem Gerät der betroffenen Gruppe fehlgeschlagen ist. Prüfe auch Geräte, die noch nicht aktualisiert wurden, da Gesamtmetriken Probleme, die auf eine Version oder Kohorte beschränkt sind, verbergen können.
Fazit
Pause, wenn du die neue Exposition stoppen musst, während du untersuchst. Rollback, wenn Nutzer im Zielbereich eine stabile Version benötigen. Richte beide Kontrollen im Voraus ein und übe sie auf einem Test-Channel vor deinem nächsten Produktions-Release.
