Ein Pause stoppt einen Rollout vor mehreren Geräten. Ein Rollback bewegt betroffene Geräte zu einer bekannten guten Version. Capgo Unterstützt beide, so können Sie zunächst ein Problem lösen und dann entscheiden, was als nächstes zu tun ist.
Verwenden Sie diese Schritte, um die richtige Aktion auszuwählen, deren Auswirkungen zu überprüfen und die Wahrscheinlichkeit eines Wiederholungsfalls zu reduzieren.
Wir haben 6 öffentliche Anleitungen zu gestuften Rollouts und Rollbacks gelesen, die von Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform und Digia veröffentlicht wurden. Vier der 6 trennen die Pause von der Rückrufhandlung als unterschiedliche Aktionen, während 2 den Rückruf oder die Pause als einzige Steuerung überspringen. Keine der 6 beschreibt, wie man die Wiederherstellung mit Analytics oder Geräteprüfungen überprüfen kann, und keine beschreibt ein Workflow, der Wiederholungsfälle verhindert. Die richtige Wahl zwischen Pause und Rollback und die Bestätigung, dass es funktioniert, schließt eine Lücke, die in der öffentlichen Veröffentlichungsleitlinie offen blieb.
Inhaltsverzeichnis
- Schritt 1: Einrichten Sie die Freigabe-Kontrollen in Capgo
- Step 2: Choose whether to pause or roll back
- Schritt 3: Pausieren Sie weitere Expositionen, während Sie untersuchen
- Schritt 4: Rollen Sie zurück, wenn Benutzer eine stabile Version benötigen
- Schritt 5: Überprüfen Sie die Wiederherstellung mit Analytics und Geräteprüfungen
- Schritt 6: Verhindere wiederholte Vorfälle mit sichereren Release-Workflows
- FAQ
- Fazit
Schritt 1: Konfigurieren Sie die Release-Kontrollen in Capgo
Stellen Sie sicher, dass Ihr Team vor einem Vorfall weiß, welcher Kanal die Veröffentlichung liefert und welches Bundle stabil ist. Ein Kanal ist ein benannter Weg, der Geräte für eine Aktualisierung leitet. Ein Bundle ist die über diesen Weg gesendete, aktualisierbare Web-code.
In Capgo kann eine progressive Rollout-Kontrolle ein stabiles Bundle beibehalten, während ein separates Rollout-Ziel an eine ausgewählte Gruppe gesendet wird. Das gibt Ihnen einen Kontrollpunkt, bevor das neue Bundle an die breitere Benutzergruppe gelangt. Überprüfen Sie die progressive Rollout-Kontrollen vor der Aktivierung in der Produktion.
Schreiben Sie den Release-Eigner und die Signale auf, die die Ausweitung stoppen sollten. Zum Beispiel entscheiden Sie, was Ihr Team tun wird, wenn die Update-Fehler steigen, eine wichtige Bildschirmseite nicht funktioniert oder die Support-Mitarbeiter melden, dass die Benutzer eine Aufgabe nicht beenden können. Setzen Sie Grenzen basierend auf dem normalen Verhalten Ihres Apps anstatt eine Schwellenwert nur wegen seines strengen Klangs auszuwählen.
Eine OTA-Update ändert die aktualisierbare code der App über die Luft. Sie ersetzt nicht die native App-Binary, die von einem App-Store installiert wurde. Der Begriff über die Luft liefernde Aktualisierung beschreibt diese Lieferungsmethode. Halten Sie diese Grenze im Auge: Wenn ein Fix ein neues native Plugin oder eine Änderung an der native App-Konfiguration erfordert, kann ein Bundle-Rollback es nicht liefern.
Bevor die Veröffentlichung erfolgt, bestätigen Sie, dass das stabile Bundle das ist, das Sie erwarten. Überprüfen Sie den Kanalnamen, das Zielbundle und den Rollout-Zustand. Ein Tippfehler im Kanalnamen oder ein veralteter Zielwert kann die Reaktionen in die falsche Richtung lenken, wenn es um Minuten geht.
Zum jetzigen Zeitpunkt sollten Sie einen benannten Release-Eigner, ein bekannt-gutes Bundle und eine schriftliche Stop-Bedingung haben. Diese Vorbereitung verwandelt die nächste Entscheidung in einen operativen Vorgang, nicht in ein Durcheinander durch die Dashboard-Ansicht.
Schlüssel-Merkpunkt: Ein Pause begrenzt die neue Exposition. Ein Rollback ändert die Version, die Benutzer empfangen sollen.
Schritt 2: Wählen Sie, ob Sie pausieren oder zurückrollen möchten
For the Capgo pause rollout vs rollback decision, ask one question first: are you trying to stop more devices from getting the target, or move devices off a target that’s already causing harm? A pause limits new exposure. A rollback clears the target and returns devices to the stable fallback on their next update check.
Für die __CAPGO_KEEP_0__ Pause-Rollout-gegen-Rollback-Entscheidung, stellen Sie zunächst eine Frage: Versuchen Sie, mehr Geräte von dem Ziel abzuhalten oder versuchen Sie, Geräte von einem Ziel abzuhalten, das bereits Schaden verursacht? Eine Pause begrenzt die neue Exposition. Ein Rollback entfernt das Ziel und kehrt die Geräte auf das stabile Fallback zurück, wenn sie auf die nächste Aktualisierung überprüft werden.
Wählen Sie Rollback, wenn das Ziel für die Benutzer offensichtlich gefährlich ist, oder wenn das Team genügend Beweise hat, dass das bekannte gute Bundle sicherer ist. Ein Pause allein entfernt das schlechte Ziel nicht von Geräten, die bereits in der Rollout-Kohorte sind. Wenn diese Benutzer wieder auf stabil zurückkehren müssen, ist Rollback die Aktion, die ihren Update-Weg ändert.
Das Capgo Kanal CLI Referenz Listen separate Pause- und Rollback-Kontrollen. Behandeln Sie sie als unterschiedliche Aktionen, nicht als zwei Namen für denselben Notfall-Stop.
| Was Sie sehen | Erste Aktion | Was als nächstes überprüfen |
|---|---|---|
| Was als nächstes überprüfen | Frische Fehler, unklarer Umfang | Vergleiche betroffene und unbetroffene Geräte |
| Vergleichen betroffene und unbetroffene Geräte | Rücksetzen der Zielanwendung | Bestätigen Sie, dass die stabile Bundle aktiv ist |
| Issue tied to native code or a service | Die Anwendungspausierung oder -einstellung, dann die betroffene Layer reparieren | Check whether a native build or service repair is needed |
| Nur eine kleine Gruppe hat das Ziel, mit bestätigter Benutzerwirkung | Pause, während Sie untersuchen | Nur nach Genehmigung des Release-Eigentümers fortsetzen |
Ein Zurücksetzen kann einen Backend-Ausfall nicht beheben und kann keine fehlende native Fähigkeit hinzufügen. Identifizieren Sie zunächst, welche Ebene gescheitert ist. Wenn das Web-Bundle der Fehlerursache ist, wählen Sie zwischen Anhalten und Zurücksetzen basierend auf der Anzahl der Benutzer, die Hilfe benötigen.
Schritt 3: Anhalten Sie die weitere Aussetzung, während Sie untersuchen
Anhalten, wenn Sie neue Geräte von der Auslieferungsgruppe ausschließen möchten, aber noch nicht bereit sind, die Zielkonfiguration für Geräte, die bereits in der Gruppe sind, zurückzusetzen. Dies ist ein Schritt zur Kontrolle. Er gibt Ihnen Zeit, die Fakten zu überprüfen, während Sie das Problem verhindern, sich auf weitere Benutzer auszuwirken.
Öffnen Sie den Produktionskanal und überprüfen Sie, ob Sie auf die betroffene Auslieferung handeln. Anhalten Sie sie mit der CLI- oder API-Steuerung, die Ihr Team verwendet. Lesen Sie dann den Kanalzustand zurück. Verlassen Sie sich nicht nur auf den erfolgreichen Abschluss einer Anweisung; bestätigen Sie, dass die Auslieferung jetzt als angehalten angezeigt wird.
In Capgo’s fortschrittlicher Rollout-Modell können Geräte, die bereits in der Kohorte sind, nach einer Pause weiterhin auf das Ziel des Rollouts bleiben. Neue, für den Rollout qualifizierte Geräte erhalten auf ihrem nächsten Check die stabile Fallback-Version. Diese Unterscheidung ist wichtig: Pause stoppt den neuen Eintritt, bewegt aber selbst die bestehende Kohorte nicht zurück auf die stabile Version.
Ziehen Sie die Release-Daten vor, bevor Sie eine weitere Änderung vornehmen. Notieren Sie sich das Ziel-Bundle, den Kanal, den Zeitpunkt der Pause und den ersten bekannten Bericht. Halten Sie Geräte- oder Sitzungs-Daten fest, die Ihre Mannschaft sammeln darf. Ein klarer Zeitplan hilft Ihnen, die Rollout-Kohorte mit Geräten zu vergleichen, die weiterhin die stabile Version verwenden.
Überprüfen Sie das Problem über einen wiederholbaren Weg. Wenn Benutzer einen fehlgeschlagenen Login melden, testen Sie diesen genauen Weg auf einem betroffenen Gerät. Wenn die App auf dem Starten abstürzt, überprüfen Sie, ob der Absturz mit der neuen Bundle-Version und der native App-Version übereinstimmt. Vermeiden Sie es, jeden Support-Bericht als Beweis dafür zu behandeln, dass die Aktualisierung das Problem verursacht hat.
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: Teilen Sie den Support- und den Release-Team mit, dass der Rollout pausiert ist. Ansonsten kann eine Gruppe weiterhin Berichte eskalieren, während die andere annehmen könnte, dass der Rollout bereits rückgängig gemacht wurde.
Zum jetzigen Zeitpunkt sollten neue Geräte nicht mehr in die Rollout-Kohorte eintreten. Überprüfen Sie den Zustand des Kanals und das Verhalten eines Geräts, das vorher nicht in der Kohorte war, bevor Sie zu einer Rückkehr oder einer Fortsetzung wechseln.
Schritt 4: Zurücksetzen, wenn Benutzer eine stabile Version benötigen
Rücken Sie Benutzer zurück, die bereits auf der Zielversion sind, wenn sie sich wieder in Richtung eines bekannten guten Pakets bewegen müssen. Dies ist eine stärkere Reaktion als das Pausen. Es ändert, was der Kanal liefert, daher überprüfen Sie die ausgewählte stabile Version, bevor Sie die Aktion bestätigen.
In Capgo, öffnen Sie den betroffenen Kanal und überprüfen Sie seine Build-Geschichte. Wählen Sie die Version aus, die Sie wiederherstellen möchten, und bestätigen Sie, dass es die richtige stabile Pakete für diese App und den Kanal ist. Capgo’s Rückkehrdokumentation beschreibt den Dashboard-Pfad und weist darauf hin, dass Geräte die ausgewählte Version beim nächsten Update erhalten.
Nach der Rückkehr gehen Sie nicht davon aus, dass alle Geräte gleichzeitig geändert wurden. Ein Gerät muss nach einer Aktualisierung suchen, und ein offline-User mag das nicht tun, bis später. Lassen Sie den Vorfall offen, bis Sie die aktive Version des Kanals überprüft und die Wiederherstellungspfad auf einem Gerät in der betroffenen Kohorte getestet haben.
Verwenden Sie das interne Paket nur dann, wenn das der beabsichtigte Wiederherstellungsziel ist. Es leitet Geräte zurück zum Web-Paket, das innerhalb der native App verpackt ist, was möglicherweise von der letzten OTA-Paket unterschiedlich ist. Überprüfen Sie die Kompatibilität und den Benutzer-Einfluss, bevor Sie es als Wiederherstellungs-Schritt wählen.
Behalten Sie die Pakete, die zum Vorfall geführt haben, zur Analyse bereit, es sei denn, Ihr Retentionsprozess sagt etwas anderes. Die Release-ID und der Commit helfen Ingenieuren, den Änderungsprozess mit der stabilen Version zu vergleichen. Bewahren Sie relevante Protokolle vor der Löschung auf, insbesondere, wenn Sie verstehen müssen, warum das Problem während der Testphase entgangen ist.
Ein Rollback ist nicht die richtige Lösung für jeden Fehler. Wenn die Ursache ein Server-Abhängigkeit ist, reparieren Sie das Service. Wenn die Änderung auf eine native code angewiesen ist, die in den installierten Binären fehlt, bereiten Sie eine native Build und folgen Sie dem App-Store-Release-Path für diese Änderung.
Schritt 5: Überprüfe die Wiederherstellung mit Analytik und Geräteprüfungen
Nach einer Pause oder einem Rollback überprüfen Sie, was die Geräte tun, anstatt die Änderung der Kontrolle als Beweis der Wiederherstellung zu behandeln. Überprüfen Sie den aktiven Kanalzustand zuerst. Vergleichen Sie dann die Update-Adoption, Fehler und Geräteberichte zwischen der betroffenen Version und der stabilen Version.
Capgo’s live update-Analysen können Ihnen helfen, Adoptionsmetriken, Fehlerquoten und Geräteprotokolle zu überprüfen. Verwenden Sie diese Signale, um spezifische Fragen zu beantworten: Empfangen neue Geräte weiterhin das Ziel, prüfen betroffene Geräte, ob sie das stabile Paket suchen, und hat der gemeldete Fehler nach der Wiederherstellung aufgehört?
Testen Sie den Benutzerpfad, der fehlgeschlagen ist. Ein erfolgreicher Download beweist nicht, dass die App funktioniert. Öffnen Sie die relevante Seite, wiederholen Sie die Aktion, die zum Bericht geführt hat, und überprüfen Sie, ob die App den erwarteten Zustand erreicht hat. Wenn das Vorfall ein kritischer Workflow beinhaltet, bestätigen Sie das Ergebnis mit jemand anderem als der Person, die den Änderungen vorgenommen hat.
Vergleichen Sie Ähnliches mit Ähnlichem. Ein breiter Fehlerzähler kann aufgrund von Gründen steigen, die nichts mit der Veröffentlichung zu tun haben, wie z.B. ein Dienstproblem oder eine Änderung im Traffic. Filtern Sie nach Paket, Kanal, App-Version und Gerät, wenn diese Felder verfügbar sind. Suchen Sie nach einer release-gelinkten Differenz anstatt die neueste Aktualisierung als Standard zu verurteilen.
Auch überprüfen Sie die Benutzer, die sich nicht aktualisiert haben. Ihre Anwesenheit kann die Gesamtmetriken gesund aussehen lassen, während die betroffene Gruppe weiterhin den Fehler sieht. Verfolgen Sie den Anteil der Geräte auf dem Ziel gegenüber dem Anteil auf stabil und halten Sie die Supportberichte an die Version gebunden, die die Benutzer tatsächlich laufen.
Schreiben Sie den Auskunftsresultat und die verbleibende Unsicherheit auf. Wenn Fehler fallen, aber ein paar Benutzer immer noch den gleichen Fehler melden, schließen Sie den Vorfall nicht, bis Sie verstehen, ob sie offline sind, auf einem älteren native Shell laufen oder immer noch das betroffene Paket verwenden.
Die Wiederherstellung ist bestätigt, wenn der Kanal auf die beabsichtigte Version zeigt und der fehlende Benutzerpfad auf einem Gerät funktioniert, das das Problem reproduzieren konnte. Die Metriken helfen Ihnen, die Form des Problems zu sehen; ein Gerätecheck bestätigt, was eine Person erlebt.
Schritt 6: Verhindern Sie wiederholte Vorfall mit sichereren Veröffentlichungsworkflows
Stellen Sie Pause und Rollback als Teil des Veröffentlichungsplans vor der Veröffentlichung fest. Ein Veröffentlichungsbesitzer sollte wissen, wer die Exposition stoppen und wer eine Rückkehr zum Stabilen genehmigen kann. Das entfernt eine häufige Verzögerung: Warten auf eine Besprechung während mehr Geräte in die Rollout eintraten.
Halten Sie eine stabile Fallback-Zuweisung fest, während der Rollout-Ziel getestet wird. Verwenden Sie eine kleine, definierte Kohorte zuerst, dann erweitern Sie nur, wenn die vereinbarten Gesundheitssignale innerhalb Ihrer Grenzen bleiben. Capgo unterstützt kanalbasierte Release-Kontrolle, sodass Teams die Testung von der breiten Produktionslieferung trennen können.
Setzen Sie Release-Überprüfungen in CI/CD, dem automatisierten Prozess, der Tests und eine Änderung bereitstellt. Ein Pipeline kann das Bundle nach erfolgreichem Test in den vorgesehenen Kanal veröffentlichen. Es sollte auch sicher ausfallen, wenn der Kanal falsch ist oder die Veröffentlichung nicht für die Promotion bereit ist.
Eine kontinuierliche Lieferung ist ein Workflow, der das Software-Update bereitstellt, indem ein automatisierter Prozess verwendet wird. Für einen OTA-Workflow sollten Sie die menschliche Genehmigungspunkte klar halten, auch wenn die Veröffentlichung automatisiert ist. Die Automation sollte die wiederholbare Aktion machen, nicht die Entscheidung für eine unüberprüfte Änderung treffen.
Mit Capgo kann eine einbefehlende Bereitstellung ein Bundle in einen Kanal veröffentlichen. Halten Sie die Befehle im gleichen Veröffentlichungsprozess wie Ihre Überprüfungen fest und machen Sie den Zielkanal im Bereitstellungsprotokoll sichtbar. Das hilft dem aufgerufenen Ingenieur genau zu sehen, was ohne Raten in welchem Lane bereitgestellt wurde.
Bevor automatische Sicherheitsmaßnahmen aktiviert werden, müssen Sie festlegen, welcher Signalwert sie auslöst und welche Aktion sie ausführen. Ein Pause kann neue Exposition stoppen, während aktuelle Cohort-Geräte auf dem Ziel bleiben. Ein Rollback kann Geräte in Richtung Stabilität lenken. Diese Ergebnisse unterscheiden sich, also sollten Sie nicht eine als die andere konfigurieren.
Verwenden Sie einen Testkanal, um die vollständige Reaktion zu üben. Veröffentlichen Sie eine harmlose Änderung, überprüfen Sie die Pause-Kontrolle und testen Sie dann das Rollback auf das vorherige Bundle. Bestätigen Sie das App-Verhalten auf einem Gerät nach jeder Aktion. Ein schriftlicher Runbook sollte den Kanal, den Befehl oder die Dashboard-Pfad, den erwarteten Zustand und die Person enthalten, die den Erfolg bestätigt.
Die Release-Notes sollten den Bundle und dessen Zweck identifizieren. Halten Sie einen Link zwischen dem Bereitstellungs-Record und der Quelländerung, damit Ingenieure den Suchbereich einschränken können, wenn ein Fehler auftritt. Wenn Ihr Team Incidents über Zeitzone hinweg weitergibt, sollten Sie den letzten Aktionen und den nächsten Entscheidungsberechtigten aufnehmen.
Wenn das Incident auf eine breitere Frontend-Implementierungsbottleneck hinweist, könnte ein Web-Entwickler wie Amir Arezoo für die Website-Entwicklung relevant sein. Das ist jedoch getrennt von Capgo’s Rollout-Kontrollen, die die Lieferung und Wiederherstellung für kompatible App-Updates handhaben.
Indem Sie nun Ihren Release-Weg haben, sollten Sie einen stabilen Ausfallschritt, einen Eigentümer, eine Stop-Regel und eine getestete Wiederherstellungsaktion enthalten. Halten Sie den Workflow so kurz, dass der aufgerufene Ingenieur ihn unter Druck ausführen kann.
FAQ
Kann eine Capgo-Pause eine bereits aktualisierten Geräte zurückrollen?
Nein. Das Anhalten unterbricht neue, für die Rollout-Veröffentlichung geeignete Geräte, aber Geräte, die bereits in der Kohorte sind, können auf dem Ziel-Paket bleiben. Um die Benutzer zurück in Richtung Stabil zu bewegen, verwenden Sie die Wiederherstellung oder eine andere absichtliche Kanalaktion. Überprüfen Sie den Kanalzustand nach jeder Änderung und bestätigen Sie das Ergebnis auf einem Gerät, das das Ziel erhalten hat.
Wann sollte ich anhalten anstatt zurückzurollen?
Anhalten, wenn das Problem noch untersucht wird und Sie eine breitere Auswirkung vermeiden müssen. Zurückrollen, wenn das Ziel als schädlich für die Benutzer bekannt ist oder wenn betroffene Geräte ein stabiles Paket benötigen. Die Capgo Entscheidung zwischen Anhalten und Zurückrollen hängt davon ab, ob der unmittelbare Bedarf darin besteht, das Problem zu enthalten oder die bestehende Kohorte zu rekonstruieren.
Wird eine Wiederherstellung alle Geräte sofort aktualisieren?
Nein. Eine Wiederherstellung ändert das Paket, auf das der Kanal zeigt, aber die Geräte erhalten es, wenn sie das nächste Mal nach einer Aktualisierung suchen. Ein Gerät, das offline ist, kann auf seinem aktuellen Paket bleiben, bis es wieder online ist. Überprüfen Sie das Ziel des Kanals und dann die betroffenen Geräte und ihren Aktualisierungsstatus, bevor Sie den Vorfall als gelöst betrachten.
Can an OTA rollback fix a native app problem?
Nein. Eine OTA-Wiederherstellung kann ein früheres updatbares Web-Paket wiederherstellen, aber sie kann keine oder keine native code innerhalb eines installierten App-Binärs hinzufügen oder entfernen. Wenn das Problem von einem native Plugin oder einer App-Shell-Änderung kommt, sollten Sie prüfen, ob ein neuer native Build erforderlich ist. Zuerst müssen Sie identifizieren, welches Layer die Fehlfunktion verursacht hat.
Was sollte ich überprüfen, nachdem ich angehalten oder zurückgerollt bin?
Bestätigen Sie den Zustand des Kanals und der aktiven Bundle, überprüfen Sie dann die Update-Adoption und Fehler nach Release. Testen Sie die vom Benutzer auf einem Gerät aus der betroffenen Gruppe gescheiterte Reise. Überprüfen Sie auch Geräte, die noch nicht aktualisiert wurden, da sich die Gesamtmetriken Probleme verbergen können, die auf eine Version oder eine Kohorte beschränkt sind.
Zusammenfassung
Pause, wenn Sie neue Exposition stoppen müssen, während Sie untersuchen. Rollen Sie zurück, wenn Benutzer auf dem Ziel eine stabile Version benötigen. Stellen Sie beide Kontrollen im Voraus ein, dann probieren Sie sie auf einem Testkanal aus, bevor Sie Ihre nächste Produktionsveröffentlichung durchführen.
