So legst du Capgo Auto-Pause-Versuche fest

Ein zu niedriger Schwellenwert kann einen stabilen OTA-Rollout pausieren. Ein zu hoher kann dazu führen, dass ein fehlerhaftes Bundle zu viele Geräte erreicht. Die Capgo Mindestanzahl der Versuche für Auto-Pause Einstellung steuert, wann Capgo über genügend Installations- und Fehlerdaten verfügt, um einen Channel zu pausieren. Nutze die folgenden Schritte, um sie sorgfältig einzustellen, zu testen und in deinen Release-Flow zu integrieren.

Inhaltsverzeichnis

• Schritt 1: Verstehe die Steuerung durch Minimum Attempts
• Schritt 2: Finde die Auto-Pause-Einstellung in Capgo
• Schritt 3: Sicheren Wert für Minimum Attempts wählen
• Schritt 4: Auto-Pause mit Channel-basiertem Rollout testen
• Schritt 5: Attempts, Analytics und automatischen Rollback überwachen
• Schritt 6: Einstellung in CI/CD automatisieren
• FAQ
• Fazit

Schritt 1: Funktion von Minimum Attempts verstehen

Die Mindestanzahl der Versuche für Auto-Pause Der Wert legt die kleinste Capgo fest, die benötigt wird, bevor die Pause-Regeln greifen können. Er fungiert als Gate, nicht als Limit für Fehlversuche. Die Einstellung weist Capgo an, mit dem Rollout zu warten, bis genügend Update-Versuche vorliegen.

Ein Versuch kann den Versuch eines Geräts beinhalten, ein Bundle zu installieren. Der Versuch kann erfolgreich oder fehlgeschlagen sein. Das genaue Ergebnis hängt vom Update-Pfad, dem App-Status und der Updater-Konfiguration ab. Daher sollte der Wert unter Berücksichtigung Ihrer Rollout-Größe gewählt werden.

Die Channel-Referenz von Capgo beschreibtauto-pause-min-attemptsals die Mindestanzahl an Installationsversuchen plus Fehlversuchen, bevor das Auto-Pause greift. Das Feld wird in der CLI Referenz als String dargestellt; behalte also das Format bei, das der Befehl oder API erwartet. Du kannst die Capgo Channel CLI Felder überprüfen, bevor du einen Live-Channel änderst.

Betrachte diese Einstellung als eine Art Mindestnachweis-Regel. Ein Wert von 1 könnte bereits nach dem ersten erfassten Versuch reagieren. Das hilft bei sehr kleinen internen Tests, kann aber auch auf eine einzige schlechte Netzwerkverbindung reagieren. Ein höherer Wert gibt dem Rollout mehr Zeit, eine aussagekräftige Stichprobe zu sammeln.

Versuche von Nutzern unterscheiden

Versuche sind nicht dasselbe wie eindeutige Personen. Ein Gerät kann ein Update wiederholt versuchen. Ein einzelner Nutzer kann die App auf mehreren Geräten verwenden. Deine Analytics-Ansicht gruppiert Events zudem eventuell anders als deine eigenen Produktmetriken.

Bevor du eine Zahl wählst, überlege dir, was der Schwellenwert schützen soll. Wenn das Ziel ist, ein fehlerhaftes JavaScript-Bundle frühzeitig zu erkennen, kann ein kleiner, kontrollierter Channel einen niedrigeren Wert nutzen. Wenn du ein breites Production-Release schützen willst, benötigst du genug Versuche, um Entscheidungen basierend auf nur einem Gerät oder einem kurzen Ausfall zu vermeiden.

• Nutze einen niedrigen Schwellenwert für private Test-Channels.
• Nutze einen höheren Schwellenwert, wenn der Channel verschiedene Netzwerke und Gerätetypen umfasst.
• Erhöhe den Schwellenwert, wenn kurze Ausfälle zu falschen Pausen geführt haben.
• Senke ihn nur, wenn die Kosten einer verspäteten Erkennung höher sind als die Kosten einer falschen Pause.

Auto-Pause sollte einen Rollout stoppen, aber keinen Bundle-Review, Gerätetests oder einen klaren Rollback-Plan ersetzen. Betrachte den Schwellenwert als eine zusätzliche Kontrolle innerhalb deines Release-Prozesses.

Das Wichtigste in Kürze: Minimum attempts steuert, wie viele Rollout-Daten Capgo benötigt, bevor die Auto-Pause-Policy greift.

Schritt 2: Die Auto-Pause-Einstellung in Capgo finden

Um den Wert für Capgo die auto-pause minimum attempts festzulegen, suche zuerst den Channel, der das Bundle ausliefert. Auto-Pause gehört zur Rollout-Steuerung; eine Änderung der appweiten Updater-Config ändert daher eventuell nicht die erwartete Channel-Policy.

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. Test- und Production-Channels können ähnliche Namen haben – ein falscher Wert im falschen Channel führt direkt zum Release-Incident.

Suche in den Channel-Einstellungen nach den Auto-Pause-Feldern. Dazu gehören meist der Minimum-Attempts-Wert und eine Confidence-Einstellung. Betrachte diese Felder bei deinem Change-Review immer zusammen. Ein Minimum Sample bestimmt, wann Capgo den Rollout bewerten kann. Ein Confidence-Wert beeinflusst, wie stark das Signal sein muss, bevor ein Pause erfolgt.

Setze den Wert über einen auditierbaren Pfad

Nutze das Dashboard für schnelle, kontrollierte Änderungen, wenn dein Team Dashboard-Änderungen protokolliert. Nutze CLI, wenn die Einstellung Teil eines Release-Skripts ist. Nutze die öffentliche API, wenn ein Service die Channel-Policy als Teil eines größeren Deployment-Systems verwaltet.

Egal welchen Weg du 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.

Bei API-gesteuerten Workflows stellt Capgo Channel-Ressourcen über seine öffentliche API bereit. Die Capgo Channel API Dokumentation ist der richtige Ort, um Feldnamen und Request-Struktur zu prüfen, anstatt sie aus einem lokalen Skript zu erraten.

Gib beim Bearbeiten des Wertes eine ganze Zahl ein, wie es das Feld erwartet. Füge kein Prozentzeichen hinzu. Nutze keine Dezimalzahlen. Wenn dein Tooling Konfigurationen als JSON speichert, achte auf die exakte Schreibweise des Keys und behalte das String-Format der aktuellen Capgo Referenz bei.

Änderung bestätigen

Lies den Channel nach dem Speichern erneut aus. Gehe nicht davon aus, dass ein erfolgreicher Befehl bedeutet, dass das Feld wie gewünscht geändert wurde. Verifiziere die zurückgegebenen Channel-Daten oder den Dashboard-Wert.

Stelle dann drei Fragen:

• Wurde die Einstellung im richtigen Channel geändert?
• Zeigt der Channel noch auf das beabsichtigte Bundle?
• Ist der Rollout aktiv, pausiert oder abgeschlossen?

Falls der Wert nicht erscheint, stoppe dort. Prüfe Berechtigungen, die Schreibweise des Felds und die Channel-ID. Ein Deployment-Script, das Erfolg meldet, ohne den gespeicherten Zustand zu prüfen, ist kaum vertrauenswürdig.

Schritt 3: Wähle einen sicheren Wert für die Mindestversuche

Wähle den Mindestversuche-Wert für die Capgo Auto-Pause anhand von Größe und Risiko des Rollouts. Es gibt keine sichere Zahl für jede App. Der richtige Schwellenwert gibt der Policy genug Anhaltspunkte und erkennt ein schlechtes Update trotzdem früh.

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 Production-Channel kann ältere Geräte, schwache Verbindungen und Nutzer umfassen, die die App nur alle paar Tage öffnen. Diese Gruppen sollten standardmäßig nicht denselben Schwellenwert nutzen.

Nutze eine einfache Entscheidungsregel

Überlege, wie viele Versuche du brauchst, damit ein Fehlermuster aussagekräftig wird. Wenn dein Test-Channel nur wenige Geräte hat, wird ein hoher Schwellenwert im Testzeitraum eventuell nie erreicht. Wenn dein Production-Channel in Minuten viele Versuche bekommt, kann ein sehr niedriger Schwellenwert das Release nach einem kurzen Netzwerkproblem pausieren.

Setze einen niedrigeren Wert, wenn:

• Der Channel ist privat.
• Das Bundle ändert ein risikoreiches Feature.
• Du brauchst schnelles Feedback während eines Staged Tests.
• Dein Team kann jeden Fehler kurz nach dem Release prüfen.

Setze einen höheren Wert, wenn:

• Der Channel bedient eine breite Gerätepalette.
• Nutzer sind über instabile Netzwerke verbunden.
• Die App hat eine geringe tägliche Öffnungsrate.
• Ein kurzer Ausfall könnte viele Fehlalarme auslösen.

Nutze den Threshold nicht, um bekannte Probleme zu kaschieren. Wenn ein Bundle wegen eines erforderlichen Native Plugins fehlschlägt, pausiere das Release manuell und behebe die Ursache. Eine Einstellung für die Mindestversuche macht ein inkompatibles Bundle nicht sicher.

Schwellenwert und Rollout-Größe aufeinander abstimmen

Angenommen, du veröffentlichst zuerst in einem kleinen internen Channel. Du kannst einen Threshold wählen, der dem Team erlaubt, mehrere Installationsergebnisse zu sehen, bevor Auto-Pause eingreift. Sobald das Bundle diese Phase besteht, verschiebe es in einen größeren Channel mit einem Threshold, der die größere Stichprobe widerspiegelt.

Dieser Ansatz sorgt für schnelles Feedback, ohne dass die Production-Policy auf eine winzige Stichprobe reagieren muss. Zudem hast du einen klaren Punkt, um die Einstellung anzupassen. Ändere den Threshold passend zum Channel, nicht erst, wenn das Rollout bereits fehlgeschlagen ist.

Dokumentiere den Wert direkt beim Release-Record. Notiere, warum du ihn gewählt hast, was eine Änderung bewirken würde und wer diese Änderung genehmigen kann. Das ist wichtig, wenn ein Teammitglied während eines Incidents einen pausierten Channel sieht und schnell Kontext benötigt.

Pro-Tipp: Beginne mit einem kontrollierten Channel, erfasst dessen Attempt-Volumen und passe den Production-Threshold dann basierend auf dem beobachteten Rollout-Verhalten an, statt auf Vermutungen zu setzen.

Schritt 4: Auto-Pause mit Channel-basiertem Rollout testen

Teste Auto-Pause in einem Channel, bevor du dich in der Produktion darauf verlässt. Ein Channel dient als Test-Boundary. Du kannst ein Bundle an eine definierte Gruppe senden, die steigenden Attempts zusehen und bestätigen, was passiert, wenn die Policy den Schwellenwert erreicht.

Erstelle zuerst ein Test-Bundle, das du eindeutig von einem Live-Release unterscheiden kannst. Halte die code Änderung sicher. Der Test soll die Release-Steuerung beweisen, nicht ein zweites App-Problem verursachen.

Ordne dem Channel als Nächstes eine kleine Gruppe von Testgeräten zu. Prüfe, ob jedes Gerät die erwartete native App-Version hat. OTA code kann nicht jeden nativen Mismatch 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.

Den Pause-Pfad testen

Du benötigst einen sicheren Weg, um einen fehlgeschlagenen Attempt zu provozieren. Nutze ein reines Test-Bundle oder eine vom Team genehmigte, kontrollierte Fehlerbedingung. Beschädige niemals ein Production-Bundle, nur um zu prüfen, ob Auto-Pause funktioniert.

Achte auf folgende Sequenz:

1. Der Channel zeigt auf das Test-Bundle.
2. Die Geräte erhalten die Update-Anweisung.
3. Attempts erscheinen in der Analytics-View.
4. Die minimale Anzahl an Attempts ist erreicht.
5. Das Fehlsignal führt dazu, dass der Channel pausiert wird, sofern die Policy-Bedingungen erfüllt sind.

Der fünfte Schritt ist entscheidend. Das Erreichen des Minimum-Attempts-Werts kann die Auto-Pause auslösen. Das bedeutet nicht, dass jeder Rollout exakt bei dieser Anzahl pausiert. Andere Policy-Felder und beobachtete Ergebnisse können das Resultat beeinflussen.

Auch die Wiederherstellung testen

Prüfen Sie nach der Pause, was die User erhalten. Kontrollieren Sie, ob das fehlerhafte Bundle ausgewählt bleibt, ob neue Devices es nicht mehr erhalten und ob das vorherige sichere Bundle für einen Rollback bereitsteht. Das Ergebnis hängt von Ihrem Updater- und Channel-Setup ab – verifizieren Sie dies anhand der App-Logs, statt sich auf Vermutungen zu verlassen.

Setzen Sie den Rollout erst mit einem verifizierten Bundle fort, nachdem der Fehler analysiert wurde. Falls der Fehler durch einen schlechten Build verursacht wurde, erstellen Sie ein neues Bundle. Pushen Sie nicht einfach dasselbe Artefakt erneut in der Hoffnung, dass der nächste Versuch anders verläuft.

Dokumentieren Sie das Testergebnis. Notieren Sie den Schwellenwert, die Anzahl der Devices, die Fehlerbedingung, die Pause-Dauer und die Recovery-Maßnahme. So wird aus einem einmaligen Test ein wiederholbarer Release-Check.

Schritt 5: Attempts, Analytics und automatischen Rollback überwachen

Das Monitoring zeigt Ihnen, ob die Capgo Auto-Pause Minimum-Attempts-Regel einen gesunden oder einen fehlerhaften Rollout erkennt. Achten Sie auf die Anzahl der Versuche im Verhältnis zum Fehlerverhalten. Ein Wert ohne Kontext kann dazu führen, dass Sie zu früh pausieren oder ein wachsendes Problem übersehen.

Nutzen Sie Capgo Observe, um die Update-Aktivität und den Rollout-Status zu prüfen. Die Capgo Observe Dokumentation beschreibt den Bereich zum Einsehen von Update-Infos und zur Konfiguration des Auto-Pause-Verhaltens. Halte das Dashboard während der ersten Phase eines Releases offen, besonders wenn das Bundle den code oder einen Core-App-Flow ändert.

Signale gemeinsam auswerten

Schau dir zuerst die Gesamtzahl der Versuche an. Prüfe dann die Anzahl der Fehler und das zeitliche Muster. Ein stetiger Strom erfolgreicher Installs unterscheidet sich von einem plötzlichen Anstieg an Fehlern, sobald ein Bundle aktiv wird.

Prüfe Geräte- und App-Versionsdetails, sofern verfügbar. Häufen sich Fehler bei einer bestimmten Native-Version, benötigt das OTA-Bundle eventuell eine neuere Binary. Treten Fehler bei allen Versionen auf, untersuche das Bundle selbst oder den Update-Service-Pfad.

Netzwerkfehler können Rauschen verursachen. Ein kurzer Ausfall kann fehlgeschlagene Versuche ohne code Defekt erzeugen. Deshalb sollte der Schwellenwert mit einer Confidence-Policy und einem manuellen Review-Prozess kombiniert werden. Auto-Pause kann die Verbreitung stoppen, aber nicht jeden Fehler erklären.

Verstehen, was Rollback in deinem Workflow bedeutet

Ein Rollback führt betroffene Nutzer zu einem bekannten, stabilen Release zurück oder verhindert, dass das fehlerhafte Release weitere Geräte erreicht. Es repariert keine Native Binary, der eine erforderliche Capability fehlt. Es kann auch keine Datenmigration rückgängig machen, die ein OTA-Bundle bereits ausgeführt hat.

Bevor ihr in die Produktion geht, bestätigt den Rollback-Pfad mit einem Test-Channel. Prüft, welches Bundle als sicher gilt. Checkt, was passiert, wenn ein Gerät während der Pause offline ist. Schreibt dann die Recovery-Schritte dort auf, wo der On-Call-Engineer sie findet.

Capgos Rollback-Dokumentation kann euch dabei helfen, die verfügbaren Rollback-Steuerungen auf euren Channel-Plan abzustimmen. Nutzt das dokumentierte Verhalten als Referenz, da das Ergebnis von der Updater-Version und dem Release-Setup abhängen kann.

Pausiert während eines Incidents zuerst, wenn das Fehlermuster eindeutig ist. Untersucht dann die Logs und Bundle-Änderungen. Ein paar Minuten, um die Verbreitung zu stoppen, sind meist einfacher zu handhaben, als ein bekannt schlechtes Release weiterlaufen zu lassen.

Schritt 6: Einstellung in CI/CD automatisieren

Integriert den Capgo Auto-Pause-Minimum-Attempts-Wert in euren Release-Workflow, wenn sich die Einstellung pro Channel unterscheidet. Automatisierung verhindert manuellen Drift. Zudem wird der gewählte Schwellenwert in der code Review sichtbar.

Haltet Channel-Policies getrennt von Secrets. Der Channel-Name, die Rollout-Phase und der Minimum-Attempts-Wert können in einer versionierten Konfiguration liegen. API Tokens müssen in eurem CI/CD Secret Store bleiben. Committet niemals ein Token in ein Repository, nur weil die Channel-Einstellung dort bereits vorhanden ist.

Ein Release-Job sollte einer klaren Reihenfolge folgen:

1. Web-Bundle builden.
2. Tests ausführen und Native Compatibility prüfen.
3. Bundle uploaden.
4. Zielkanal festlegen oder bestätigen.
5. Apply the minimum attempts value.
6. Gespeicherten Kanalstatus überprüfen.
7. Rollout veröffentlichen oder fortsetzen.

Nutze einen Dry-Run oder eine Review-Phase, falls dein Deployment-System dies unterstützt. Die Review sollte Bundle-ID, Kanal, Threshold und die Rollout-Aktion anzeigen, bevor der Production-Schritt ausgeführt wird.

Verifizierung fest in den Job integrieren

Rufe nach Abschluss des API oder CLI Befehls den Kanalstatus erneut ab. Schlage den Job fehl, falls der Rückgabewert nicht der erwarteten Konfiguration entspricht. So werden falsche Kanal-IDs, abgelehnte Felder und unvollständige Updates erkannt.

Environment Variables sind ein gängiger Weg, um Release-Einstellungen in einen CI-Job zu übergeben. Der Job kann einen Kanalnamen oder Threshold auslesen, ohne Secrets in Source-Files zu speichern. Halte die Variablennamen klar und validiere sie vor dem Deployment.

Beispielsweise 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 zentral auf die exakten CLI oder API Felder. Das erleichtert die Überprüfung zukünftiger Änderungen.

Für eine tiefergehende Sicherheitsprüfung beachte die Empfehlungen von Capgo zur Absicherung von OTA-Updates in CI/CD-Pipelines. Die wichtigste Regel ist simpel: 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 14-tägigen Testphase statt eines einmaligen Kaufs. Dieses Modell passt ideal für Teams, die den Release-Workflow testen wollen, bevor sie ihn fest in ihren Delivery-Prozess integrieren. Halte den Test fokussiert: Konfiguriere einen Channel, führe einen Pause-Test durch und verifiziere einen Rollback-Pfad.

Ein einziger Befehl kann das Update veröffentlichen. Der sicherere Workflow ist jedoch derjenige, der auch den Channel prüft, die Adoption trackt und einen Rollback-Pfad bereithält.

FAQ

Was bedeutet Capgo auto pause minimum attempts?

Capgo auto pause minimum attempts legt die Mindestanzahl an Installationen und Fehlversuchen fest, die nötig sind, bevor die Auto-Pause-Policy greift. Es handelt sich um eine Stichproben-Schwelle, nicht um einen Prozentsatz fehlgeschlagener Installationen. Ein niedriger Wert reagiert schneller, basiert aber auf weniger Daten. Ein höherer Wert gibt dem Channel mehr Zeit, Ergebnisse zu sammeln.

Wo stelle ich auto pause minimum attempts in Capgo ein?

Du setzt den Wert auf dem Channel, der das OTA-Bundle ausliefert. Nutze das Capgo Dashboard, CLI oder die öffentliche API und lies den Channel danach aus, um das gespeicherte Feld zu bestätigen. Prüfe zuerst den Channel-Namen. Das Bearbeiten eines Test-Channels während eines aktiven Production-Rollouts ändert nichts am Production-Rollout selbst.

Was ist ein sicherer Wert für die minimalen Versuche?

Ein sicherer Wert hängt von der Channel-Größe, der Geräte-Mix, der Netzwerkqualität und dem Release-Risiko ab. Nutze einen kleineren Schwellenwert für einen kontrollierten Test-Channel. Nutze einen größeren Schwellenwert für einen breiten Production-Rollout. Starte mit einer bekannten Gruppe, beobachte das Attempt-Volumen und passe den Wert basierend auf dem Verhalten an.

Führt das Erreichen des minimalen Versuche-Werts immer zu einem Release-Pause?

Nein. Das Erreichen des Capgo Schwellenwerts für minimale Versuche macht den Rollout für Auto-Pause berechtigt, aber andere Policy-Bedingungen spielen weiterhin eine Rolle. Failure-Signale, Confidence-Einstellungen, der Channel-Status und der Updater-Flow können das Ergebnis beeinflussen. Teste den kompletten Pause-Pfad mit einem sicheren Bundle, bevor du dich in der 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 zu einem bekannten guten Bundle zurückführt, sofern dieser Pfad verfügbar ist. Teste beide Mechanismen. Beachte auch, dass ein OTA-Rollback keine Native Capability hinzufügen kann, die die installierte App nicht besitzt.

Fazit

Lege den Wert für die minimalen Versuche pro Channel fest, statt dich auf Gewohnheiten zu verlassen. Starte mit einem kleinen Test-Rollout, verifiziere die Pause- und Rollback-Pfade und automatisiere die genehmigte Einstellung anschließend in deiner CI/CD. Um den Workflow zu testen, probiere Capgo mit einem Channel und einem kontrollierten Bundle aus, bevor du den Rollout erweiterst.