Come impostare i tentativi di auto-pausa di Capgo

Una soglia di tentativi bassa può mettere in pausa un rollout OTA sano. Una soglia alta può far arrivare un bundle difettoso a troppi dispositivi. Il Capgo auto pause tentativi minimi impostazione controlla quando Capgo ha dati sufficienti su installazioni e fallimenti per mettere in pausa un canale. Usa i passaggi seguenti per configurarla con attenzione, testarla e integrarla nel tuo flusso di rilascio.

Indice dei contenuti

• Passo 1: Capire cosa controlla Minimum Attempts
• Passaggio 2: Trova l'impostazione Auto-Pause in Capgo
• Passo 3: Scegliere un valore sicuro per Minimum Attempts
• Passaggio 4: testa l'Auto-Pause con un rollout basato sul canale
• Passaggio 5: Monitora tentativi, analytics e rollback automatico
• Passaggio 6: Automatizza l'impostazione nella CI/CD
• FAQ
• Conclusione

Passo 1: Capire cosa controlla Minimum Attempts

Il auto pause tentativi minimi value imposta il campione minimo di cui Capgo ha bisogno prima che le regole di pausa possano attivarsi. È un gate, non un limite di fallimenti. L'impostazione dice a Capgo di attendere finché non ci sono abbastanza tentativi di aggiornamento prima di valutare il rollout.

Un tentativo può includere un dispositivo che cerca di installare un bundle. Il tentativo può riuscire o fallire. L'esito esatto dipende dal percorso di aggiornamento, dallo stato dell'app e dalla configurazione dell'updater. Ecco perché il valore va letto tenendo presente la dimensione del rollout.

Il riferimento ai canali di Capgo descriveauto-pause-min-attemptscome il numero minimo di tentativi di installazione più fallimenti prima che l'auto-pausa possa avere effetto. Il campo è rappresentato come stringa nel riferimento di CLI, quindi mantieni il valore nel formato atteso dal comando o da API che utilizzi. Puoi rivedere il campi del canale CLI di Capgo prima di modificare un canale live.

Pensa all'impostazione come a una regola di evidenza minima. Un valore di 1 può reagire dopo il primo tentativo registrato. Questo può aiutare durante un piccolo test interno, ma può anche reagire a una singola sessione di rete problematica. Un valore più grande dà al rollout più tempo per raccogliere un campione utile.

Separa i tentativi dagli utenti

Gli attempt non sono la stessa cosa delle persone uniche. Un dispositivo potrebbe ritentare un aggiornamento. Un singolo utente potrebbe eseguire l'app su più dispositivi. La tua vista analytics potrebbe anche raggruppare gli eventi in modo diverso dalle tue metriche di prodotto.

Prima di scegliere un numero, scrivi cosa vuoi che la soglia protegga. Se l'obiettivo è catturare presto un bundle JavaScript rotto, un canale controllato di piccole dimensioni può usare un valore più basso. Se l'obiettivo è proteggere un rilascio di produzione ampio, hai bisogno di abbastanza attempt per evitare decisioni basate su un solo dispositivo o su un'interruzione breve.

• Usa una soglia piccola per un canale di test privato.
• Usa una soglia più grande quando il canale ha reti e tipi di dispositivo misti.
• Aumenta la soglia se brevi interruzioni hanno causato pause false.
• Ridurla solo quando il costo di una rilevazione tardiva è superiore al costo di una pausa falsa.

L'auto-pause deve interrompere un rollout, non sostituire la revisione del bundle, i test sui dispositivi o un piano di rollback chiaro. Considera la soglia come uno dei controlli del tuo processo di rilascio.

In sintesi: Minimum attempts controlla quanta evidenza del rollout deve raccogliere Capgo prima che la sua policy di auto-pause possa intervenire.

Passaggio 2: Trova l'impostazione Auto-Pause in Capgo

Per impostare il Capgo valore auto pause minimum attempts, individua prima il canale che distribuisce il bundle. L'auto-pause fa parte del controllo del rollout, quindi modificare la configurazione dell'updater a livello di app potrebbe non cambiare la policy del canale che ti aspetti.

Inizia dalla dashboard di Capgo o usa il comando channel e il percorso API già in uso dal tuo team. Verifica il nome del canale prima di modificare qualsiasi cosa. Un canale di test e uno di produzione potrebbero avere nomi simili, e un valore corretto sul canale sbagliato è comunque un incidente di rilascio in agguato.

Cerca i campi auto-pause nelle impostazioni del canale. I campi correlati potrebbero includere il valore minimum attempts e un'impostazione di confidence. Gestisci questi campi insieme durante la revisione delle modifiche. Un campione minimo indica quando Capgo può valutare il rollout. Un valore di confidence può influenzare quanto debba essere forte il segnale prima che avvenga una pausa.

Imposta il valore tramite il percorso che puoi verificare

Usa la dashboard quando serve una modifica rapida e controllata e il team registra le modifiche fatte dalla dashboard. Usa il CLI quando l'impostazione fa parte di uno script di release. Usa la API pubblica quando un servizio gestisce la policy del canale all'interno di un sistema di deployment più ampio.

Indipendentemente dal percorso scelto, registra prima il valore precedente. Salva il nome del canale, la versione del bundle, lo stato del rollout e il nuovo valore nello stesso record di modifica. Così avrai una risposta chiara se il canale viene messo in pausa in seguito.

Per i workflow basati su API, Capgo espone le risorse dei canali tramite la sua API pubblica. Il Documentazione del canale Capgo API è il posto giusto per verificare i nomi dei campi e la struttura della richiesta, invece di indovinare da uno script locale.

Quando modifichi il valore, inserisci un numero intero come previsto dal campo. Non aggiungere il segno di percentuale. Non usare decimali. Se il tuo tooling salva la configurazione in JSON, mantieni l'ortografia della chiave esatta e conserva il formato stringa mostrato nel riferimento Capgo attuale.

Conferma la modifica

Rileggi il canale dopo averlo salvato. Non dare per scontato che un comando riuscito significhi che il campo previsto è stato modificato. Verifica i dati del canale restituiti o il valore nel dashboard.

Poi poni tre domande:

• L'impostazione è cambiata sul canale previsto?
• Il canale punta ancora al bundle previsto?
• Il rollout è attivo, in pausa o completato?

Se il valore non appare, fermati lì. Controlla i permessi, l'ortografia del campo e l'identificatore del canale. Uno script di deployment che riporta successo senza verificare lo stato salvato è difficile da fidarsi.

Passo 3: Scegli un valore sicuro per i tentativi minimi

Scegli il valore dei tentativi minimi per la pausa automatica di Capgo in base alla dimensione e al rischio del rollout. Non esiste un numero sicuro per ogni app. La soglia giusta fornisce alla policy abbastanza evidenze, pur rilevando un aggiornamento difettoso in anticipo.

Inizia con il gruppo più piccolo che possa darti informazioni utili. Un canale privato può contenere dispositivi interni con versioni dell'app note. Un canale di produzione può includere dispositivi datati, connessioni deboli e utenti che aprono l'app solo una volta ogni pochi giorni. Questi gruppi non dovrebbero condividere la stessa soglia di default.

Usa una regola di decisione semplice

Chiedi quanti tentativi servono prima che un pattern di fallimenti sia significativo. Se il tuo canale di test ha solo pochi dispositivi, una soglia alta potrebbe non essere mai raggiunta durante la finestra di test. Se il tuo canale di produzione riceve molti tentativi in pochi minuti, una soglia molto bassa potrebbe mettere in pausa il rilascio dopo un breve problema di rete.

Imposta un valore più basso quando:

• Il canale è privato.
• Il bundle modifica una funzionalità ad alto rischio.
• Hai bisogno di feedback rapido durante un test graduale.
• Il tuo team può esaminare ogni fallimento poco dopo il rilascio.

Imposta un valore più alto quando:

• Il canale serve un mix eterogeneo di dispositivi.
• Gli utenti si connettono da reti instabili.
• L'app viene aperta poche volte al giorno.
• Un breve disservizio potrebbe generare molti falsi fallimenti.

Non usare la soglia per nascondere un problema noto. Se un bundle fallisce su un plugin nativo richiesto, metti tu stesso in pausa il rilascio e risolvi la causa. Un'impostazione di tentativi minimi non può rendere sicuro un bundle incompatibile.

Abbina la soglia alla dimensione del rollout

Supponiamo che tu rilasci prima su un piccolo canale interno. Potresti scegliere una soglia che permetta al team di vedere diversi risultati di installazione prima che l'auto-pause intervenga. Una volta che il bundle supera quella fase, spostalo su un canale più ampio con una soglia che rifletta il campione più grande.

Questo approccio mantiene rapido il primo segnale senza costringere la policy di produzione a reagire su un campione minuscolo. Ti dà anche un punto chiaro per regolare l'impostazione. Cambia la soglia insieme al canale, non dopo che il rollout è già fallito.

Tieni traccia del valore accanto al record del rilascio. Annota perché lo hai scelto, cosa ti porterebbe a cambiarlo e chi può approvare la modifica. Questo conta quando un membro del team vede un canale in pausa durante un incidente e ha bisogno di contesto in fretta.

Consiglio pro: Inizia con un canale controllato, monitora il volume di tentativi e poi regola la soglia di produzione basandoti sul comportamento reale del rollout invece che su supposizioni.

Passaggio 4: testa l'Auto-Pause con un rollout basato sul canale

Testa l'auto-pause su un canale prima di farci affidamento in produzione. Un canale definisce il perimetro del test. Puoi inviare un bundle a un gruppo noto, osservare l'aumento dei tentativi e verificare cosa succede quando la policy raggiunge la soglia.

Per prima cosa, crea un bundle di test riconoscibile, senza confonderlo con un rilascio live. Mantieni al sicuro la modifica code. Il test deve mettere alla prova i controlli di rilascio, non creare un altro problema all'app.

Successivamente, assegna un piccolo gruppo di dispositivi di test al canale. Verifica che ogni dispositivo abbia la versione nativa dell'app prevista. L'OTA code non può correggere ogni discrepanza nativa, quindi un dispositivo che esegue il binario sbagliato può rendere difficile l'interpretazione del test.

Pubblica il bundle nel canale. Quando possibile, usa un singolo comando nel tuo flusso di deployment Capgo standard, ma conserva gli ID di bundle e canale nel log di rilascio. Non fare affidamento sul buffer di scrollback del terminale durante un incidente.

Testa il percorso di pausa

Serve un modo sicuro per generare un tentativo fallito. Usa un bundle solo per test o una condizione di fallimento controllata approvata dal team. Non danneggiare mai un bundle di produzione solo per verificare se l'auto-pause funziona.

Osserva la seguente sequenza:

1. Il canale punta al bundle di test.
2. I dispositivi ricevono l'istruzione di aggiornamento.
3. I tentativi appaiono nella vista analytics.
4. Viene raggiunto il numero minimo di tentativi.
5. Il segnale di fallimento fa mettere in pausa il canale, se le condizioni di policy sono soddisfatte.

Il quinto passo è importante. Raggiungere il valore minimo di tentativi può rendere l'auto-pause ammissibile. Non significa che ogni rollout si metta in pausa a quel conteggio esatto. Altri campi di policy e risultati osservati possono influenzare il risultato.

Testa anche il recupero

Dopo la pausa, verifica cosa ricevono gli utenti. Controlla se il bundle fallito resta selezionato, se i nuovi dispositivi smettono di riceverlo e se il bundle sicuro precedente è disponibile per il rollback. La risposta dipende dalla configurazione di updater e canale, quindi verificala nei log dell'app invece di darla per scontata.

Riprendi quindi con un bundle verificato solo dopo che qualcuno ha analizzato il fallimento. Se il fallimento deriva da una build difettosa, crea un nuovo bundle. Non limitarti a ripubblicare lo stesso artefatto sperando che il tentativo successivo vada diversamente.

Documenta il risultato del test. Includi la soglia, il numero di dispositivi, la condizione di fallimento, il tempo di pausa e l'azione di recupero. Questo trasforma un test una tantum in un controllo di rilascio ripetibile.

Passaggio 5: Monitora tentativi, analytics e rollback automatico

Il monitoraggio ti dice se la regola dei tentativi minimi per l'auto-pausa di Capgo sta rilevando un rollout sano o problematico. Tieni d'occhio il conteggio dei tentativi insieme al comportamento in caso di errore. Un conteggio senza contesto può farti mettere in pausa troppo presto o farti perdere un problema in crescita.

Usa Capgo Observe per controllare l'attività di aggiornamento e lo stato del rollout. La documentazione di Capgo Observe descrive l'area usata per visualizzare le informazioni sugli aggiornamenti e configurare il comportamento di auto-pausa. Tieni aperto il dashboard durante la prima parte di un rilascio, soprattutto quando il bundle modifica il comportamento di startup code o un flusso principale dell'app.

Analizza i segnali insieme

Osserva prima il totale dei tentativi. Poi controlla il numero di fallimenti e il pattern temporale. Un flusso costante di installazioni riuscite appare diverso da un picco di fallimenti dopo l'attivazione di un bundle.

Controlla i dettagli del dispositivo e della versione dell'app quando disponibili. Se i fallimenti si concentrano su una sola versione nativa, il bundle OTA potrebbe richiedere un binario più recente. Se i fallimenti compaiono in tutte le versioni, esamina il bundle stesso o il percorso del servizio di aggiornamento.

I fallimenti di rete possono creare rumore. Un'interruzione breve può generare tentativi falliti senza un difetto di code. Ecco perché la soglia dovrebbe funzionare con una policy di confidenza e un processo di revisione umana. L'auto-pausa può fermare l'esposizione, ma non può spiegare ogni fallimento.

Capisci cosa significa il rollback nel tuo flusso

Un rollback riporta gli utenti interessati verso una release nota come affidabile o impedisce alla release difettosa di raggiungere altri dispositivi. Non ripara un binario nativo che manca di una funzionalità richiesta. Non può nemmeno annullare una migrazione dei dati già eseguita da un bundle OTA.

Prima di passare in produzione, conferma la procedura di rollback con un canale di test. Verifica quale bundle viene considerato sicuro. Controlla cosa succede se un dispositivo è offline durante la pausa. Infine, scrivi i passaggi per il ripristino dove l'ingegnere on-call può trovarli.

di Capgo documentazione rollback può aiutarti ad associare i controlli di rollback disponibili al tuo piano dei canali. Usa il comportamento documentato come riferimento, dato che il risultato può dipendere dalla versione dell'updater e dalla configurazione del rilascio.

Durante un incidente, metti prima in pausa se il pattern di errore è chiaro. Poi ispeziona i log e le modifiche ai bundle. Passare qualche minuto a fermare l'esposizione è di solito più gestibile che lasciare che un rilascio noto come difettoso continui a diffondersi.

Passaggio 6: Automatizza l'impostazione nella CI/CD

Inserisci il valore Capgo auto pause minimum attempts nel tuo workflow di rilascio quando l'impostazione cambia a ogni canale. L'automazione elimina le derive manuali. Rende anche la soglia scelta visibile nella review di code.

Mantieni la policy del canale separata dai secrets. Il nome del canale, la fase di rollout e il valore dei tentativi minimi possono stare in una configurazione versionata. I token API devono restare nel tuo secret store della CI/CD. Non committare mai un token in un repository solo perché l'impostazione del canale è già lì.

Un job di rilascio dovrebbe seguire un ordine chiaro:

1. Esegui la build del web bundle.
2. Esegui i test e controlla la compatibilità nativa.
3. Esegui l'upload del bundle.
4. Imposta o conferma il canale di destinazione.
5. Applica il valore dei tentativi minimi.
6. Verifica lo stato del canale salvato.
7. Pubblica o avanza il rollout.

Usa una fase di dry-run o di revisione se il tuo sistema di deployment la supporta. La revisione deve mostrare il bundle identifier, il canale, la soglia e l'azione di rollout prima che parta lo step di produzione.

Rendi la verifica parte del job

Al termine del comando API o CLI, recupera di nuovo lo stato del canale. Fai fallire il job se il valore restituito non corrisponde alla configurazione prevista. Così intercetti ID canale errati, campi rifiutati e update parziali.

Le variabili d'ambiente sono un modo comune per passare le impostazioni di rilascio a un job CI. Il job può leggere il nome di un canale o una soglia senza inserire secret nei file sorgente. Mantieni i nomi delle variabili chiari e validali prima del deployment.

Ad esempio, il tuo workflow potrebbe richiedere:

• CAPGO_CHANNELper il canale di destinazione.
• CAPGO_MIN_ATTEMPTSper la soglia approvata.
• CAPGO_BUNDLE_IDper il bundle caricato.

Quei nomi sono convenzioni di workflow, non nomi di campi Capgo. Mappali ai campi esatti CLI o API in un unico punto. Così le modifiche future saranno più facili da revisionare.

Per un controllo di sicurezza più approfondito, consulta la guida di Capgo sulla messa in sicurezza degli aggiornamenti OTA nelle pipeline CI/CD. L'abitudine che conta è semplice: limita l'accesso ai token, logga la decisione di release e verifica il risultato dopo ogni modifica.

Mantieni un registro delle modifiche

Salva la soglia insieme all'ID del commit o della release. Aggiungi il motivo della modifica. Se un rollout va in pausa inaspettatamente, puoi confrontare la policy con il bundle e il momento del deployment.

Capgo viene fatturato tramite abbonamento per organizzazione, con una prova gratuita di 14 giorni invece di un acquisto una tantum. Questo modello si adatta ai team che vogliono testare il workflow di release prima di integrarlo nel processo di delivery regolare. Mantieni il test mirato: configura un canale, esegui un test di pausa e verifica un percorso di rollback.

Un singolo comando può pubblicare l'update. Il workflow più sicuro è quello che controlla anche il canale, monitora l'adozione e lascia un percorso di rollback.

FAQ

Cosa significa Capgo auto pause minimum attempts?

Capgo auto pause minimum attempts imposta il numero minimo di installazioni e tentativi falliti necessari prima che la policy di auto-pause possa scattare. È una soglia sulla dimensione del campione, non una percentuale di installazioni fallite. Un valore basso reagisce prima, ma potrebbe basarsi su meno dati. Un valore più alto dà al canale più tempo per raccogliere i risultati.

Dove imposto l'auto pause minimum attempts in Capgo?

Imposti il valore sul channel che distribuisce il bundle OTA. Usa la dashboard di Capgo, CLI o la API pubblica, quindi rileggi il channel per confermare il campo salvato. Controlla prima il nome del channel. Modificare un channel di test quando la produzione è attiva non cambierà il rollout di produzione.

Qual è un valore minimo sicuro per i tentativi?

Un valore sicuro dipende dalla dimensione del channel, dalla mix di dispositivi, dalla qualità della rete e dal rischio del rilascio. Usa una soglia più bassa per un channel di test controllato. Usa una soglia più alta per un rollout di produzione ampio. Inizia con un gruppo noto, monitora il volume dei suoi tentativi e regola in base al comportamento osservato.

Raggiungere il valore minimo di tentativi mette sempre in pausa un rilascio?

No. Raggiungere il valore minimo di tentativi di Capgo rende il rollout idoneo all'auto-pause, ma contano anche altre condizioni di policy. Segnali di errore, impostazioni di confidenza, stato del canale e il flusso dell'updater possono influenzare l'esito. Testa l'intero percorso di pausa con un bundle sicuro prima di affidarti a questa funzione in produzione.

L'auto-pausa può sostituire un piano di rollback?

No. L'auto-pause interrompe o limita l'ulteriore esposizione, mentre il rollback sposta gli utenti verso un bundle noto e funzionante quando tale percorso è disponibile. Testa entrambi i controlli. Ricorda anche che un rollback OTA non può aggiungere una capacità nativa che l'app installata non possiede.

Conclusione

Imposta il valore minimo di tentativi per canale, non per abitudine. Inizia con un rollout di test ridotto, verifica i percorsi di pausa e rollback, poi automatizza l'impostazione approvata in CI/CD. Se vuoi testare il workflow, prova Capgo con un canale e un bundle controllato prima di espandere il rollout.