Ein Pausieren stoppt eine Rollout von weiteren Geräten. Ein Zurücksetzen bewegt betroffene Geräte in Richtung einer bekannten guten Version. Capgo unterstützt beide, so können Sie ein Problem zuerst beheben 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 Wiederholung des Vorfalls zu minimieren.
Wir haben 6 öffentliche Anleitungen zu gestuften Rollouts und Zurücksetzungen gelesen, die von Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform und Digia veröffentlicht wurden. Vier der 6 trennen das Pausieren von dem Zurücksetzen als unterschiedliche Aktionen, während 2 das Zurücksetzen oder das Pausieren als die einzige Steuerung ignorieren. Keine der 6 beschreibt, wie man die Wiederherstellung mit Analytics oder Geräteprüfungen überprüfen kann, und keine beschreibt ein Workflow, um Wiederholungsvorfälle zu verhindern. Die richtige Wahl zwischen Pausieren und Zurücksetzen und die Bestätigung, dass es funktioniert hat, schließt eine Lücke, die in den öffentlichen Veröffentlichungsleitlinien 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 die weitere Auslieferung, 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 Analysen und Geräteprüfungen
- Schritt 6: Verhindern Sie wiederholte Vorfälle mit sichereren Veröffentlichungsworkflows
- FAQ
- Zusammenfassung
Schritt 1: Konfiguration der Releasekontrolle in Capgo
Stellen Sie sicher, dass Ihr Team 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 aktualisierbare Web-code, die über diesen Weg gesendet wird.
In Capgo kann eine progressive Veröffentlichung ein stabiles Bundle beibehalten, während ein separates Rolloutziel an eine ausgewählte Gruppe gesendet wird. Das gibt Ihnen einen Kontrollpunkt, bevor das neue Bundle an die breitere Benutzerbasis gelangt. Überprüfen Sie die progressive Veröffentlichungssteuerung bevor Sie sie in der Produktion aktivieren.
Schreiben Sie den Release-Eigner und die Signale auf, die die Expansion stoppen sollen. Zum Beispiel entscheiden Sie, was Ihre Mannschaft tun wird, wenn die Update-Fehler ansteigen, ein wichtiger Bildschirm nicht funktioniert oder die Support-Mitarbeiter melden, dass die Benutzer eine Aufgabe nicht beenden können. Legen Sie Grenzen auf der Grundlage des normalen Verhaltens Ihrer App fest, anstatt eine Schwellenwerte nur wegen seiner strengen Klangfarbe auszuwählen.
Eine OTA-Update ändert die app-aktualisierbare code über die Luft. Sie ersetzt nicht die native App-Binary, das von einem App-Store installiert wurde. Der Begriff OTA-Update beschreibt diese Lieferungsmethode. Halten Sie diese Grenze im Auge: Wenn ein Fix ein neues native Plugin oder eine Änderung an der native App-Einrichtung benötigt, kann ein Bundle-Rollback es nicht liefern.
Bevor die Veröffentlichung erfolgt, bestätigen Sie, dass der stabile Bundle der erwartete ist. Überprüfen Sie den Kanalnamen, den Zielbundle und den Rollout-Zustand. Ein Tippfehler in einem Kanalnamen oder ein veralteter Ziel kann die Reaktionen in die falsche Richtung lenken, wenn Minuten zählen.
Sie sollten jetzt einen benannten Release-Eigner, einen bekannten guten Bundle und eine schriftliche Stop-Bedingung haben. Diese Vorbereitung wandelt die nächste Entscheidung in eine operative Wahl, nicht in eine Panik durch das Dashboard.
Schlüssel-Merkpunkt: Ein Pause beschränkt 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
Für die Capgo Pause-Rollout- vs - Rollback-Entscheidung, stellen Sie sich zunächst eine Frage: Versuchen Sie, mehr Geräte von der Zielgruppe abzuhalten oder Geräte von einer Zielgruppe abzuholen, die bereits Schaden verursacht hat? Eine Pause begrenzt die neue Exposition. Ein Rollback entfernt das Ziel und kehrt die Geräte auf ihren nächsten Update-Check auf den stabilen Fallback zurück.
Wählen Sie Pause, wenn die Beweise unvollständig sind oder das Problem begrenzt erscheint. Sie haben möglicherweise einige Berichte, aber wissen nicht, ob der Fehler ein bestimmtes Gerätetyp, eine bestimmte Benutzerfluss oder alle aktualisierten Geräte betrifft. Eine Pause gibt dem Team Raum, den Signal zu untersuchen, ohne neue Geräte zur Rollout-Gruppe hinzuzufügen.
Wählen Sie Rollback, wenn die Zielgruppe offensichtlich für die Benutzer gefährlich ist oder wenn das Team genügend Beweise hat, dass die bekannte gute Bundle sicherer ist. Eine Pause allein entfernt die schlechte Zielgruppe nicht von Geräten, die bereits in der Rollout-Kohorte sind. Wenn diese Benutzer zurückkehren müssen, ist Rollback die Aktion, die ihren Update-Weg ändert.
Die Capgo Kanal CLI Referenz listet separate Pause- und Rollback-Kontrollen auf. Behandeln Sie sie als unterschiedliche Aktionen, nicht als zwei Namen für denselben Notfall-Stop.
| Was Sie sehen | Erste Aktion | Was sollten Sie als Nächstes überprüfen |
|---|---|---|
| Was Sie als nächstes überprüfen sollten | Fruhe Fehler, unklarer Umfang | Pausieren Sie die Rollout-Phase |
| bekannter Fehler, der die Zielgruppe betrifft | Rückgängigmachen der Zielgruppe | Bestätigen, dass die stabile Bundle aktiv ist |
| Problem verbunden mit nativem code oder einem Dienst | Pause oder enthalten Sie die App-Änderung, dann beheben Sie die betroffene Ebene | Überprüfen Sie, ob eine native Erstellung oder eine Dienstreparatur erforderlich ist |
| Nur eine kleine Gruppe hat das Ziel, und keine Benutzerwirkung wurde bestätigt | Während Sie untersuchen | Erst nach Genehmigung des Release-Eigentümers |
Ein Rückgängigmachen behebt keine Backend-Ausfallzeit 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
Pausieren Sie, wenn Sie neue Geräte von der Rollout-Gruppe ausschließen möchten, aber noch nicht bereit sind, das Ziel für bereits in der Gruppe befindliche Geräte zurückzusetzen. Dies ist ein Schritt zur Kontrolle. Er gibt Ihnen Zeit, die Fakten zu überprüfen, während das Problem nicht auf weitere Benutzer übertragen wird.
Öffnen Sie den Produktionskanal und überprüfen Sie, ob Sie auf den betroffenen Rollout handeln. Pausieren Sie ihn mit der CLI oder API-Steuerung, die Ihre Team verwendet. Lesen Sie dann den Kanalzustand zurück. Verlassen Sie sich nicht nur auf den erfolgreichen Abschluss einer Anweisung; bestätigen Sie, dass der Rollout jetzt als pausiert angezeigt wird.
In Capgo's fortschrittlichem Rollout-Modell können Geräte, die bereits in der Kohorte sind, nach einer Pausung weiterhin auf dem Rollout-Ziel bleiben. Neue, für die Aktualisierung geeignete Geräte erhalten auf ihrem nächsten Check die stabile Fallback-Version. Diese Unterscheidung ist wichtig: Pausieren stoppt neue Einträge, aber es bewegt sich selbst die bestehende Kohorte nicht zurück auf die stabile Version.
Nächsten, fassen Sie die Release-Daten vor der nächsten Änderung zusammen. Notieren Sie das Ziel-Bundle, den Kanal, den Zeitpunkt der Pausierung und den ersten bekannten Bericht. Halten Sie Geräte- oder Sitzungs-Daten, die Ihr Team 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 exakten Weg auf einem betroffenen Gerät. Wenn die App beim Start abstürzt, überprüfen Sie, ob der Absturz mit der neuen Bundle 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.
Setzen Sie einen Besitzer und einen Entscheidungszeitpunkt für die Untersuchung. Ein pausierter Rollout kann in der Schwebe bleiben, wenn niemand die nächste Bewegung übernimmt. Der Besitzer sollte entweder nachgewiesenen Beweisen folgen und den Rollout fortsetzen oder wenn das Ziel weiterhin gefährlich ist, den Rollback ausführen.
Pro-Tipp: Erzählen Sie dem Support-Team und der Release-Team, dass der Rollout pausiert ist. Ansonsten könnte eine Gruppe weiterhin Meldungen eskalieren lassen, während die andere annehmen könnte, der Rollout sei bereits rückgängig gemacht worden.
Zum jetzigen Zeitpunkt sollten keine neuen Geräte mehr in den Rollout-Cohort aufgenommen werden. Überprüfen Sie den Zustand des Kanals und das Verhalten eines Geräts, das vorher nicht zum Cohort gehörte, bevor Sie zu einem Rollback oder einer Fortsetzung übergehen.
Schritt 4: Rollback, wenn Benutzer eine stabile Version benötigen
Rollback, wenn Benutzer, die bereits auf dem Ziel sind, zurückgehen müssen, um sich einer bekannten guten Bundle zu nähern. Dies ist eine stärkere Reaktion als das Pausieren. 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 Bundle für diese App und Kanal ist. Capgo’s Rollback-Dokumentation beschreibt den Dashboard-Weg und weist darauf hin, dass Geräte die ausgewählte Build beim nächsten Mal, wenn sie nach einer Aktualisierung suchen, erhalten.
Nach dem Rollback 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 kann das nicht tun, bis später. Lassen Sie den Vorfall offen, bis Sie den aktiven Kanalversion überprüft und die Wiederherstellungspfad auf einem Gerät im betroffenen Cohort getestet haben.
Verwenden Sie die integrierte Bundle nur dann, wenn dies der beabsichtigte Wiederherstellungsziel ist. Es zeigt Geräte auf die Web-Ausführung zurück, die innerhalb der native App verpackt ist, die sich möglicherweise von der letzten OTA-Bundle unterscheidet. Überprüfen Sie die Kompatibilität und den Nutzer-Einfluss, bevor Sie es als Wiederherstellungs-Schritt wählen.
Behalten Sie die Bundle auf, die den Vorfall verursacht hat, für die 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 die Tests entgangen ist.
Ein Rollback ist nicht die richtige Lösung für jeden Fehler. Wenn die Ursache ein Server-seitiger Abhängigkeit ist, reparieren Sie das Service. Wenn die Änderung auf eine native code abzielt, die in den installierten Binären fehlt, bereiten Sie eine native Ausführung vor und folgen dem App-Store-Release-Path für diese Änderung.
Schritt 5: Überprüfen Sie die Wiederherstellung mit Analysen und Geräteprüfungen
Nach einer Pause oder einem Rollback überprüfen Sie, was die Geräte tun, anstatt die Kontrolländerung als Beweis für die 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-Analyse hilft Ihnen dabei, die Adoptionsmetriken, Fehlerquoten und Geräteebene-Protokolle zu überprüfen. Verwenden Sie diese Signale, um spezifische Fragen zu beantworten: erhalten neue Geräte noch den Zielwert, überprüfen betroffene Geräte nach dem stabilen Bundle und stoppten die gemeldeten Fehler nach der Wiederherstellung?
Testen Sie den Benutzungspfad, 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. 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 Bundle, 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 verdächtigen.
Überprüfen Sie auch die Benutzer, die noch 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 Zielwert gegenüber dem Anteil auf dem stabilen Bundle und halten Sie die Supportberichte an der Version fest, die die Benutzer tatsächlich laufen.
Notieren Sie sich das Wiederherstellungsresultat und die verbleibende Unsicherheit. Wenn Fehler fallen, aber ein paar Benutzer weiterhin denselben Fehler melden, schließen Sie den Vorfall nicht, bis Sie verstehen, ob sie offline sind, auf einem älteren Native-Shell oder noch mit dem betroffenen Bundle arbeiten.
Die Wiederherstellung ist bestätigt, wenn der Kanal auf die beabsichtigte Version zeigt und der fehlerhafte Benutzerpfad auf einem Gerät funktioniert, das das Problem reproduzieren konnte. Metriken helfen Ihnen, die Form des Problems zu erkennen; ein Gerätecheck bestätigt, was ein Mensch erlebt.
Schritt 6: Verhindere wiederholte Vorfälle mit sichereren Veröffentlichungsworkflows
Stellen Sie Pause und Rollback als Teil des Veröffentlichungsplans vor der Veröffentlichung ein. Der Veröffentlichungsbesitzer sollte wissen, wer die Exposition stoppen und wer eine Rückkehr zum Stabilen genehmigen kann. Das entfernt eine häufige Verzögerung: das Warten auf eine Besprechung, während mehr Geräte in die Rollout eintraten.
Behalten Sie eine stabile Fallback-Zuweisung bei, 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. Eine Pipeline kann das Bundle nach erfolgreichem Test an den beabsichtigten Kanal veröffentlichen. Sie sollte auch sicher scheitern, wenn der Kanal falsch ist oder die Veröffentlichung nicht bereit ist.
Ein kontinuierlicher Lieferungsworkflow hält das Software bereit für die Veröffentlichung durch einen automatisierten Prozess. 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.
Mit Capgo, kann eine einzeilige Bereitstellung eine Bundle an einen Kanal veröffentlichen. Halten Sie die Befehlszeile im selben Releaseprozess wie Ihre Überprüfungen und machen Sie den Zielkanal im Bereitstellungsprotokoll sichtbar. Das hilft dem aufgerufenen Ingenieur genau zu sehen, was ohne Vermutungen versendet wurde.
Bevor automatische Sicherheitsmechanismen aktiviert werden, definieren Sie, 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 Zielkanal bleiben. Ein Rollback kann Geräte in Richtung Stabilität leiten. 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 den Rollback auf das vorherige Bundle. Bestätigen Sie das App-Verhalten auf einem Gerät nach jeder Aktion. Ein schriftlicher Runbook sollte den Kanal, die Befehlszeile 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 Bereitstellungsprotokoll und der Quelldatei, damit Ingenieure den Suchbereich einschränken können, wenn ein Fehler auftritt. Wenn Ihr Team Incidents über Zeitzonen hinweg weitergibt, sollten Sie den letzten Aktionseingriff und den nächsten Entscheidungseigner aufnehmen.
Wenn das Incident auf eine breitere Frontend-Implementierungsengpässe hinweist, könnte ein Webentwickler wie Amir Arezoo relevant für die Website-Entwicklung sein. Das ist jedoch getrennt von Capgo’s Rollout-Kontrollen, die die Lieferung und Wiederherstellung für kompatible App-Updates verwalten.
Ihre Release-Pfad sollte jetzt einen stabilen Ausfallschritt, einen Besitzer, eine Stop-Regel und eine getestete Wiederherstellungsaktion enthalten. Halten Sie den Workflow so kurz, dass der aufgerufene Ingenieur ihn unter Druck verwenden kann.
FAQ
Pausiert man einen Capgo Rollout, werden bereits aktualisierte Geräte zurückgerollt?
Nein. Die Pause stoppt neue Geräte, die für die Veröffentlichung in Frage kommen, aber Geräte, die bereits in der Kohorte sind, können auf dem Ziel-Paket bleiben. Um die Benutzer zurück zur Stabilität zu bewegen, verwenden Sie die Rücksetzung 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-Paket erhalten hat.
Wann sollte ich pausieren anstatt zurückzusetzen?
Pausieren Sie, wenn das Problem noch untersucht wird und Sie eine breitere Aussetzung vermeiden möchten. Zurücksetzen Sie, wenn das Ziel bekannt ist, die Benutzer zu schädigen, oder wenn die betroffenen Geräte ein stabiles Paket benötigen. Die Capgo-Pausierung vs. -Rücksetzung hängt davon ab, ob der sofortige Bedarf darin besteht, die Ausbreitung zu verhindern oder die bestehende Kohorte wiederherzustellen.
Wird eine Rücksetzung alle Geräte sofort aktualisieren?
Nein. Eine Rücksetzung ä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 den Kanalziel, bevor Sie die betroffenen Geräte und ihren Update-Status überprüfen und den Vorfall als gelöst betrachten.
Kann eine OTA-Rücksetzung ein Problem eines native Apps beheben?
Kein. Eine OTA-Rollback kann ein früheres updatenfähiges Web-Bundle wiederherstellen, aber sie kann keine oder keine native code-Komponenten innerhalb eines installierten App-Binärs hinzufügen oder entfernen. Wenn das Problem von einer native Plugin- oder App-Shell-Änderung kommt, muss beurteilt werden, ob eine neue native Build erforderlich ist. Zuerst muss identifiziert werden, welcher Layer die Fehlfunktion verursacht hat.
Was sollte ich nach dem Pausieren oder Zurücksetzen überprüfen?
Bestätigen Sie den Zustand des Kanals und der aktiven Bundle, dann überprüfen Sie die Update-Adoption und Fehler nach Release. Testen Sie die fehlgeschlagene Benutzerreise auf einem Gerät aus der betroffenen Gruppe. Überprüfen Sie auch Geräte, die noch nicht aktualisiert wurden, da sich allgemeine Metriken Probleme in einer bestimmten Version oder Kohorte verbergen können.
Fazit
Pause, wenn Sie neue Exposition stoppen müssen, während Sie untersuchen. Rollen Sie zurück, wenn die Benutzer auf dem Ziel eine stabile Version benötigen. Stellen Sie beide Kontrollen im Voraus ein und probieren Sie sie dann auf einem Testkanal aus, bevor Sie Ihre nächste Produktionsveröffentlichung durchführen.
