Ein niedriger Schwellenwert kann ein gesundes OTA-Rollout unterbrechen. Ein zu hoher Wert kann es einem fehlerhaften Bundle ermöglichen, zu viele Geräte zu erreichen. Die Capgo Auto-Pause: Minimum Attempts Einstellung steuert, wann Capgo genügend Installations- und Fehlerdaten hat, um einen Channel zu pausieren. Verwenden Sie die folgenden Schritte, um sie sorgfältig einzurichten, zu testen und in Ihren Release-Flow zu integrieren.
Inhaltsverzeichnis
- Schritt 1: Funktion von Minimum Attempts verstehen
- Schritt 2: Auto-Pause-Einstellung in Capgo finden
- Schritt 3: Sicheren Wert für Minimum Attempts wählen
- Schritt 4: Auto-Pause mit Channel-basiertem Rollout testen
- Schritt 5: Attempts, Analytics und Auto-Rollback überwachen
- Schritt 6: Einstellung in CI/CD automatisieren
- FAQ
- Fazit
Schritt 1: Funktion von Minimum Attempts verstehen
Der Auto-Pause: Minimum Attempts Der Wert legt die kleinste Stichprobe fest, die Capgo braucht, bevor seine Pause-Regeln greifen. Es ist ein Gate, kein Fehlerlimit. Die Einstellung sagt Capgo, dass es mit der Bewertung des Rollouts warten soll, bis genügend Update-Attempts vorliegen.
Ein Attempt kann beinhalten, dass ein Gerät versucht, ein Bundle zu installieren. Der Attempt kann erfolgreich sein oder fehlschlagen. Das genaue Ergebnis hängt vom Update-Pfad, dem App-Status und der Updater-Konfiguration ab. Deshalb sollte man den Wert immer mit Blick auf die eigene Rollout-Größe lesen.
Die Channel-Referenz von Capgo beschreibtauto-pause-min-attemptsals minimale Anzahl an Installations- und Fehlschlag-Versuchen, bevor die Auto-Pause greifen kann. Das Feld wird in der CLI-Referenz als String dargestellt, daher den Wert im vom Befehl oder API erwarteten Format belassen. Du kannst die Capgo-Channel-CLI-Felder prüfen, bevor du einen Live-Channel änderst.
Sieh die Einstellung als Mindestnachweis-Regel an. Ein Wert von 1 kann bereits nach dem ersten protokollierten Versuch reagieren. Das kann bei einem sehr kleinen internen Test hilfreich sein, reagiert aber auch auf eine einzelne schlechte Netzwerksitzung. Ein höherer Wert gibt dem Rollout mehr Zeit, um eine nützliche Stichprobe zu sammeln.
Versuche von Nutzern trennen
Versuche sind nicht dasselbe wie eindeutige Personen. Ein Gerät kann ein Update erneut versuchen. Ein einzelner Nutzer kann die App auf mehreren Geräten ausführen. Deine Analytics-Ansicht gruppiert Ereignisse möglicherweise anders als deine eigenen Produktmetriken.
Bevor du eine Zahl wählst, schreibe auf, was der Schwellenwert schützen soll. Wenn das Ziel ist, ein defektes JavaScript-Bundle früh zu erkennen, kann ein kleiner, kontrollierter Channel einen niedrigeren Wert verwenden. Wenn das Ziel ist, eine breite Produktionsveröffentlichung zu schützen, brauchst du genügend Versuche, um Entscheidungen auf Basis eines einzelnen Geräts oder einer kurzen Störung zu vermeiden.
- Verwende einen kleinen Schwellenwert für einen privaten Test-Channel.
- Verwende einen größeren Schwellenwert, wenn der Channel gemischte Netzwerke und Gerätetypen hat.
- Erhöhe den Schwellenwert, wenn kurze Störungen zu falschen Pausen geführt haben.
- Senke ihn nur, wenn die Kosten einer späten Erkennung höher sind als die Kosten einer falschen Pause.
Auto-pause sollte einen Rollout stoppen. Er sollte Bundle-Review, Gerätetests oder einen klaren Rollback-Plan nicht ersetzen. Behandle den Schwellenwert als eine Kontrolle innerhalb deines Release-Prozesses.
Das Wichtigste in Kürze: Minimum attempts steuert, wie viele Rollout-Beweise Capgo benötigt, bevor seine Auto-pause-Richtlinie greifen kann.
Schritt 2: Auto-Pause-Einstellung in Capgo finden
Um die Capgo auto pause minimum attempts-Wert zu setzen, finde zuerst den Channel, der das Bundle ausliefert. Auto-pause gehört zur Rollout-Steuerung, daher kann die Änderung der app-weiten Updater-Konfiguration die Channel-Richtlinie nicht ändern, die du erwartest.
Starte im Capgo-Dashboard oder nutze den Channel-Befehl und den API-Pfad, den dein Team bereits verwendet. Prüfe den Channel-Namen, bevor du etwas änderst. Ein Test-Channel und ein Produktions-Channel können ähnliche Namen haben, und ein korrekter Wert auf dem falschen Channel ist immer noch ein Release-Vorfall, der nur darauf wartet, zu passieren.
Suche nach den Auto-Pause-Feldern in den Channel-Einstellungen. Die zugehörigen Felder können den Minimum-Attempts-Wert und eine Confidence-Einstellung umfassen. Behalte diese Felder bei deiner Change-Review zusammen. Ein Minimum-Sample legt fest, wann Capgo den Rollout bewerten darf. Ein Confidence-Wert kann beeinflussen, wie stark das Signal sein muss, bevor eine Pause ausgelöst wird.
Setze den Wert über den Pfad, den du auditieren kannst
Nutze das Dashboard, wenn du eine schnelle, kontrollierte Änderung benötigst und dein Team Dashboard-Änderungen dokumentiert. Verwende die CLI, wenn die Einstellung in ein Release-Skript gehört. Nutze die öffentliche API, wenn ein Service die Channel-Policy als Teil eines größeren Deployment-Systems verwaltet.
Welchen Pfad du auch wählst: Erfasse zuerst den alten Wert. Speichere Channel-Namen, Bundle-Version, Rollout-Status und den neuen Wert im selben Change-Record. So hast du eine klare Antwort, falls der Channel später pausiert.
Für API-gesteuerte Workflows stellt Capgo Channel-Ressourcen über seine öffentliche API bereit. Die Capgo Channel API-Dokumentation ist der richtige Ort, um die Feldnamen und die Request-Struktur zu prüfen, statt aus einem lokalen Skript zu raten.
Wenn du den Wert bearbeitest, gib eine ganze Zahl ein, wie das Feld es erwartet. Füge kein Prozentzeichen hinzu. Verwende keine Dezimalzahl. Wenn dein Tooling die Konfiguration als JSON speichert, halte die Schreibweise des Keys exakt bei und behalte das in der aktuellen Capgo-Referenz gezeigte String-Format bei.
Änderung bestätigen
Lies den Channel nach dem Speichern erneut. Nimm nicht an, dass ein erfolgreicher Befehl bedeutet, dass sich das beabsichtigte Feld geändert hat. Verifiziere die zurückgegebene Channel-Daten oder den Dashboard-Wert.
Stelle dir dann drei Fragen:
- Hat sich die Einstellung auf dem beabsichtigten Channel geändert?
- Verweist der Channel immer noch auf den beabsichtigten Bundle?
- Ist der Rollout aktiv, pausiert oder abgeschlossen?
Wenn der Wert nicht erscheint, stoppe dort. Prüfe Berechtigungen, die Schreibweise des Felds und die Channel-Identifikation. Ein Deployment-Skript, das Erfolg meldet, ohne den gespeicherten Zustand zu verifizieren, ist schwer zu vertrauen.
Schritt 3: Sicheren Wert für Minimum Attempts wählen
Wähle den Capgo Auto-Pause Minimum Attempts-Wert basierend auf Größe und Risiko des Rollouts. Es gibt keine sichere Zahl für jede App. Der richtige Schwellenwert gibt der Policy genug Evidenz, während sie ein schlechtes Update früh erkennt.
Beginne mit der kleinsten Gruppe, die dir etwas Nützliches sagen kann. Ein privater Channel kann interne Geräte mit bekannten App-Versionen enthalten. Ein Produktions-Channel kann ältere Geräte, schwache Verbindungen und Benutzer enthalten, die die App nur einmal alle paar Tage öffnen. Diese Gruppen sollten standardmäßig nicht denselben Schwellenwert teilen.
Einfache Entscheidungsregel verwenden
Fragen Sie, wie viele Versuche nötig sind, bevor ein Fehlermuster aussagekräftig ist. Wenn Ihr Test-Channel nur wenige Geräte hat, wird eine hohe Schwelle im Testzeitraum möglicherweise nie erreicht. Wenn Ihr Produktions-Channel innerhalb von Minuten viele Versuche erhält, kann eine sehr niedrige Schwelle das Release nach einem kurzen Netzwerkproblem pausieren.
Setzen Sie einen niedrigeren Wert, wenn:
- Der Channel privat ist.
- Das Bundle eine risikoreiche Funktion ändert.
- Sie während eines gestuften Tests schnelles Feedback benötigen.
- Ihr Team jeden Fehler kurz nach dem Release prüfen kann.
Setzen Sie einen höheren Wert, wenn:
- Der Channel eine breite Gerätevielfalt abdeckt.
- Nutzer sich über instabile Netzwerke verbinden.
- Die App täglich nur selten geöffnet wird.
- Eine kurze Störung viele falsche Fehler erzeugen könnte.
Verwenden Sie die Schwelle nicht, um ein bekanntes Problem zu verbergen. Wenn ein Bundle an einem erforderlichen nativen Plugin scheitert, pausieren Sie das Release selbst und beheben Sie die Ursache. Eine Mindestanzahl an Versuchen kann ein inkompatibles Bundle nicht sicher machen.
Schwellenwert mit Rollout-Größe koppeln
Angenommen, Sie veröffentlichen zuerst in einem kleinen internen Channel. Dann wählen Sie vielleicht einen Schwellenwert, der dem Team mehrere Installationsergebnisse zeigt, bevor Auto-Pause eingreifen kann. Sobald das Bundle diese Phase besteht, verschieben Sie es in einen größeren Channel mit einem Schwellenwert, der der größeren Stichprobe entspricht.
Dieser Ansatz hält das erste Signal schnell, ohne dass die Production-Policy auf eine winzige Stichprobe reagieren muss. Er gibt Ihnen außerdem eine klare Stelle, an der Sie die Einstellung anpassen können. Ändern Sie den Schwellenwert zusammen mit dem Channel, nicht erst, nachdem der Rollout bereits fehlgeschlagen ist.
Halten Sie den Wert neben dem Release-Eintrag fest. Notieren Sie, warum Sie ihn gewählt haben, was Sie dazu bringen würde, ihn zu ändern, und wer diese Änderung genehmigen darf. Das ist wichtig, wenn ein Teammitglied während eines Incidents einen pausierten Channel sieht und schnell Kontext braucht.
Pro-Tipp: Startet mit einem kontrollierten Channel, erfasst dessen Versuchsvolumen und passt den Produktions-Schwellenwert anhand des beobachteten Rollout-Verhaltens an, statt zu raten.
Schritt 4: Auto-Pause mit Channel-basiertem Rollout testen
Teste Auto-Pause auf einem Channel, bevor du dich in der Produktion darauf verlässt. Ein Channel gibt dir einen Rahmen für den Test. Du kannst ein Bundle an eine bekannte Gruppe senden, beobachten, wie die Attempts steigen, und prüfen, was passiert, wenn die Policy ihren Schwellenwert erreicht.
Erstelle zuerst ein Test-Bundle, das du klar von einem Live-Release unterscheiden kannst. Die code-Änderung muss sicher bleiben. Der Test soll die Release-Steuerung belegen, nicht ein zweites App-Problem erzeugen.
Ordne dem Channel als Nächstes eine kleine Gruppe Testgeräte zu. Prüfe, ob jedes Gerät die erwartete native App-Version hat. OTA code kann nicht jede native Abweichung beheben; ein Gerät mit der falschen Binary kann das Testergebnis verfälschen.
Veröffentliche das Bundle im Channel. Nutze nach Möglichkeit einen Befehl aus deinem normalen Capgo Deployment-Flow, aber halte die Bundle- und Channel-IDs im Release-Log fest. Verlasse dich bei einem Incident nicht auf den Terminal-Scrollback-Buffer.
Pause-Pfad testen
Du brauchst einen sicheren Weg, um einen fehlgeschlagenen Attempt zu erzeugen. Nutze ein reines Test-Bundle oder eine vom Team genehmigte, kontrollierte Fehlerbedingung. Beschädige niemals ein Produktions-Bundle, nur um zu sehen, ob Auto-Pause funktioniert.
Achte auf folgende Reihenfolge:
- Der Channel verweist auf das Test-Bundle.
- Die Geräte erhalten die Update-Anweisung.
- Attempts erscheinen in der Analytics-Ansicht.
- Die Mindestanzahl an Attempts ist erreicht.
- Das Fehlsignal führt dazu, dass der Channel pausiert wird, sofern die Policy-Bedingungen erfüllt sind.
Der fünfte Schritt ist wichtig. Erreichen des Mindestwerts für Versuche kann die Voraussetzungen für ein Auto-Pause erfüllen. Es bedeutet jedoch nicht, dass jeder Rollout genau bei dieser Anzahl pausiert. Andere Policy-Felder und beobachtete Ergebnisse können das Ergebnis beeinflussen.
Auch die Wiederherstellung testen
Nach der Pause prüfen Sie, was die Nutzer erhalten. Stellen Sie sicher, ob das fehlerhafte Bundle weiterhin ausgewählt ist, ob neue Geräte es nicht mehr empfangen und ob das vorherige sichere Bundle für einen Rollback verfügbar ist. Die Antwort hängt von Ihrer Updater- und Channel-Konfiguration ab, daher sollten Sie dies anhand der App-Logs verifizieren, statt es vorauszusetzen.
Fahren Sie erst dann mit einem bekannten, funktionierenden Bundle fort, nachdem jemand den Fehler überprüft hat. Wenn der Fehler von einem fehlerhaften Build stammt, erstellen Sie ein neues Bundle. Pushen Sie nicht einfach dasselbe Artefakt erneut und hoffen Sie, dass der nächste Versuch ein anderes Verhalten zeigt.
Dokumentieren Sie das Testergebnis. Fügen Sie den Schwellenwert, die Anzahl der Geräte, die Fehlerbedingung, die Pausezeit und die Wiederherstellungsaktion hinzu. So wird aus einem einmaligen Test eine wiederholbare Release-Prüfung.
Schritt 5: Attempts, Analytics und Auto-Rollback überwachen
Monitoring zeigt Ihnen, ob die Capgo Auto-Pause-Minimum-Attempts-Regel ein gesundes Rollout oder ein defektes erkennt. Beobachten Sie die Anzahl der Versuche im Zusammenhang mit dem Fehlerverhalten. Eine Anzahl ohne Kontext kann dazu führen, dass Sie zu früh pausieren oder ein wachsendes Problem übersehen.
Verwenden Sie Capgo Observe, um Update-Aktivität und Rollout-Status zu inspizieren. Die Capgo Observe Dokumentation beschreibt den Bereich, in dem Sie Update-Informationen anzeigen und das Auto-Pause-Verhalten konfigurieren können. Halten Sie das Dashboard während des ersten Teils eines Releases offen, insbesondere wenn das Bundle den Startprozess von code oder einen Kern-App-Flow ändert.
Signale gemeinsam auswerten
Schau dir zuerst die Gesamtzahl der Versuche an. Dann prüfe die Fehleranzahl und das Zeitmuster. Ein stetiger Strom erfolgreicher Installationen sieht anders aus als ein Ausbruch von Fehlern, nachdem ein Bundle aktiviert wurde.
Prüfe bei Verfügbarkeit die Details zu Gerät und App-Version. Wenn Fehler auf einer nativen Version konzentriert sind, benötigt das OTA-Bundle möglicherweise ein neueres Binary. Wenn Fehler in jeder Version auftreten, untersuche das Bundle selbst oder den Pfad des Update-Dienstes.
Netzwerkfehler können Rauschen erzeugen. Ein kurzer Ausfall kann fehlgeschlagene Versuche verursachen, ohne dass ein code-Defekt vorliegt. Deshalb sollte der Schwellenwert mit einer Konfidenzpolitik und einem menschlichen Review-Prozess arbeiten. Auto-Pause kann die Exposition stoppen, aber nicht jeden Fehler erklären.
Wissen, was Rollback in deinem Flow bedeutet
Ein Rollback bewegt betroffene Nutzer zurück zu einer bekannten, funktionierenden Release oder verhindert, dass das fehlerhafte Release weitere Geräte erreicht. Es repariert kein natives Binary, dem eine erforderliche Funktion fehlt. Es kann auch keine Datenmigration rückgängig machen, die ein OTA-Bundle bereits ausgeführt hat.
Bevor du es im Produktivbetrieb einsetzt, bestätige den Rollback-Pfad mit einem Testkanal. Verifiziere, welches Bundle als sicher gilt. Prüfe, was passiert, wenn ein Gerät während der Pause offline ist. Dokumentiere dann die Wiederherstellungsschritte dort, wo der On-Call-Engineer sie finden kann.
Capgos Rollback-Dokumentation kann dir helfen, die verfügbaren Rollback-Steuerungen auf deinen Kanalplan abzubilden. Nutze das dokumentierte Verhalten als Referenz, da das Ergebnis von der Updater-Version und der Release-Konfiguration abhängen kann.
Bei einem Incident zuerst pausieren, wenn das Fehlermuster eindeutig ist. Danach Logs und Bundle-Änderungen prüfen. Wenige Minuten, um die Ausbreitung zu stoppen, sind meist besser zu handhaben, als eine bekannte fehlerhafte Release-Version weiterlaufen zu lassen.
Schritt 6: Einstellung in CI/CD automatisieren
Setze den Capgo Auto-Pause-Minimum-Attempts-Wert in deinen Release-Workflow, wenn sich die Einstellung je nach Channel ändert. Automatisierung beseitigt manuelle Abweichungen. Außerdem macht sie den gewählten Schwellenwert in der code-Review sichtbar.
Halte Channel-Policy und Secrets getrennt. Channel-Name, Rollout-Stufe und Minimum-Attempts-Wert können in versionierter Konfiguration liegen. API-Tokens müssen in deinem CI/CD-Secret-Store bleiben. Committe niemals ein Token in ein Repository, nur weil die Channel-Einstellung bereits dort ist.
Ein Release-Job sollte eine klare Reihenfolge einhalten:
- Web-Bundle bauen.
- Tests ausführen und native Kompatibilität prüfen.
- Bundle hochladen.
- Den Zielkanal festlegen oder bestätigen.
- Den Wert für minimale Versuche anwenden.
- Den gespeicherten Kanalstatus überprüfen.
- Den Rollout veröffentlichen oder vorantreiben.
Nutze einen Dry-Run oder eine Review-Phase, wenn dein Deployment-System das unterstützt. Die Review sollte Bundle-ID, Kanal, Threshold und die Rollout-Aktion anzeigen, bevor der Production-Schritt läuft.
Die Verifizierung in den Job integrieren
Rufe nach Abschluss des Befehls API oder CLI den Kanalstatus erneut ab. Lass den Job fehlschlagen, wenn der zurückgegebene Wert nicht der erwarteten Konfiguration entspricht. Das fängt falsche Kanal-IDs, abgelehnte Felder und unvollständige Updates ab.
Umgebungsvariablen sind ein gängiger Weg, um Release-Einstellungen an einen CI-Job zu übergeben. Der Job kann einen Kanalnamen oder Threshold auslesen, ohne Secrets in den Quelldateien abzulegen. Halte die Variablennamen klar und validiere sie vor dem Deployment.
Zum Beispiel könnte dein Workflow Folgendes benötigen:
CAPGO_CHANNELfür den Zielkanal.CAPGO_MIN_ATTEMPTSfür den genehmigten Threshold.CAPGO_BUNDLE_IDfür das hochgeladene Bundle.
Diese Namen sind Workflow-Konventionen, keine Capgo-Feldnamen. Mappe sie an einer Stelle auf die exakten Felder CLI oder API. So lassen sich künftige Änderungen leichter prüfen.
Für einen tiefergehenden Sicherheitscheck lies die Empfehlungen von Capgo zur Absicherung von OTA-Updates in CI/CD-Pipelines. Die wichtigste Regel ist einfach: Token-Zugriff einschränken, die Release-Entscheidung loggen und das Ergebnis nach jeder Änderung verifizieren.
Änderungsprotokoll führen
Speichere den Schwellenwert zusammen mit der Commit- oder Release-ID. Füge den Grund für die Änderung hinzu. Falls ein Rollout unerwartet pausiert, kannst du die Policy mit dem Bundle und dem Deployment-Zeitpunkt vergleichen.
Capgo wird als Abonnement pro Organisation abgerechnet, mit einer kostenlosen 14-tägigen Testphase statt eines einmaligen Kaufs. Das Modell passt zu Teams, die den Release-Workflow testen wollen, bevor sie ihn fest in ihren regulären Delivery-Prozess integrieren. Halte die Testphase fokussiert: Konfiguriere einen Channel, führe einen Pause-Test durch und verifiziere einen Rollback-Pfad.
Ein Befehl kann das Update veröffentlichen. Der sicherere Workflow prüft auch den Channel, trackt die Adoption und lässt einen Rollback-Pfad offen.
FAQ
Was bedeutet Capgo auto pause minimum attempts?
Capgo auto pause minimum attempts legt die minimale Anzahl an Installations- und Fehlversuchen fest, die nötig ist, bevor die Auto-Pause-Policy greifen kann. Es ist ein Gate für die Stichprobengröße, kein Prozentsatz fehlgeschlagener Installationen. Ein niedriger Wert reagiert schneller, stützt sich aber auf weniger Daten. Ein höherer Wert gibt dem Channel mehr Zeit, Ergebnisse zu sammeln.
Wo lege ich in Capgo die Mindestanzahl an Versuchen für Auto-Pause fest?
Du setzt den Wert auf dem Channel, der das OTA-Bundle ausliefert. Nutze das Capgo Dashboard, CLI oder die öffentliche API, lies den Channel danach erneut aus und bestätige das gespeicherte Feld. Prüfe zuerst den Channel-Namen. Wenn Production aktiv ist, ändert das Bearbeiten eines Test-Channels nichts am Production-Rollout.
Was ist eine sichere Mindestanzahl an Versuchen?
Ein sicherer Wert hängt von der Channel-Größe, dem Geräte-Mix, der Netzwerkqualität und dem Release-Risiko ab. Nutze einen niedrigeren Schwellenwert für einen kontrollierten Test-Channel und einen höheren für einen breiten Production-Rollout. Starte mit einer bekannten Gruppe, beobachte das Attempt-Volumen und passe ihn anhand des beobachteten Verhaltens an.
Pausiert ein Release immer, wenn die Mindestanzahl an Versuchen erreicht ist?
Nein. Wenn der Minimum-Attempts-Wert von Capgo erreicht wird, qualifiziert das den Rollout für Auto-Pause, aber andere Policy-Bedingungen zählen weiterhin. Failure-Signale, Confidence-Settings, Channel-Status und Updater-Flow können das Ergebnis beeinflussen. Teste den kompletten Pause-Pfad mit einem sicheren Bundle, bevor du dich in Production darauf verlässt.
Kann Auto-Pause einen Rollback-Plan ersetzen?
Nein. Auto-Pause stoppt oder begrenzt die weitere Verbreitung, während ein Rollback die Nutzer auf ein bekanntes, funktionierendes Bundle zurückführt, sofern dieser Pfad verfügbar ist. Teste beide Kontrollmechanismen. Beachte auch, dass ein OTA-Rollback keine native Capability hinzufügen kann, die die installierte App nicht hat.
Fazit
Setze den Mindestwert für Versuche pro Channel, nicht aus Gewohnheit. Beginne mit einem kleinen Test-Rollout, prüfe die Pausen- und Rollback-Pfade und automatisiere die genehmigte Einstellung in CI/CD. Wenn du den Workflow testen möchtest, probiere Capgo mit einem Channel und einem kontrollierten Bundle aus, bevor du den Rollout ausbaust.
