Una soglia di tentativi troppo bassa può interrompere un rollout OTA in corso. Una troppo alta può far arrivare un bundle errato a troppi dispositivi. Il Capgo tentativi minimi per l'auto-pause controlla quando Capgo ha dati sufficienti su installazioni e fallimenti per mettere in pausa un canale. Segui i passaggi qui sotto per configurarla con cura, testarla e integrarla nel tuo flusso di rilascio.
Indice dei contenuti
- Passaggio 1: Capire cosa controlla il Minimum Attempts
- Passaggio 2: Trovare l'impostazione Auto-Pause in Capgo
- Passaggio 3: Scegli un valore di Minimum Attempts sicuro
- Passaggio 4: Testa l'Auto-Pause con un rollout basato su Channel
- Passaggio 5: Monitora tentativi, analytics e rollback automatico
- Passaggio 6: Automatizza l'impostazione nella CI/CD
- FAQ
- Conclusione
Passaggio 1: Capire cosa controlla il Minimum Attempts
L'oggetto tentativi minimi per l'auto-pause il valore definisce il campione minimo di cui Capgo ha bisogno prima che le regole di pausa intervengano. È un gate, non un limite di fallimenti. L'impostazione dice a Capgo di attendere che ci siano abbastanza tentativi di update prima di valutare il rollout.
Un tentativo può includere un dispositivo che prova a installare un bundle. Il tentativo può avere successo o fallire. L'esito esatto dipende dall'update path, dallo stato dell'app e dalla configurazione dell'updater. Per questo il valore va scelto in base alla dimensione del rollout.
Il riferimento al channel di Capgo descriveauto-pause-min-attemptscome il numero minimo di tentativi tra installazione e fallimento prima che l'auto-pause entri in funzione. Il campo è rappresentato come stringa nel riferimento CLI, quindi mantieni il valore nel formato richiesto dal comando o da API che utilizzi. Puoi rivedere i campi CLI del canale Capgo prima di modificare un canale live.
Considera questa impostazione come una regola di prova minima. Un valore pari a 1 potrebbe attivarsi dopo il primo tentativo registrato. Questo può aiutare durante un piccolo test interno, ma potrebbe anche scattare per una singola sessione di rete instabile. Un valore più alto dà al rollout più tempo per raccogliere un campione utile.
Distinguere i tentativi dagli utenti
I tentativi non coincidono con le persone uniche. Un dispositivo può riprovare un aggiornamento. Un singolo utente può eseguire l'app su più dispositivi. Anche la tua vista analytics potrebbe raggruppare gli eventi in modo diverso dalle tue metriche di prodotto.
Prima di scegliere un numero, scrivi cosa vuoi proteggere con la soglia. Se l'obiettivo è intercettare subito un bundle JavaScript corrotto, un canale di test piccolo può usare un valore più basso. Se l'obiettivo è proteggere un rilascio in produzione su larga scala, serve un numero di tentativi sufficiente per evitare decisioni basate su un singolo dispositivo o un breve outage.
- Usa una soglia bassa per un canale di test privato.
- Usa una soglia più alta quando il canale ha reti e tipi di dispositivi misti.
- Alza la soglia se brevi outage hanno causato pause errate.
- Abbassala solo quando il costo di un rilevamento tardivo è superiore al costo di una pausa errata.
L'auto-pause deve interrompere un rollout. Non deve sostituire la revisione del bundle, i test sui dispositivi o un piano di rollback chiaro. Considera la soglia come un singolo controllo all'interno del tuo processo di rilascio.
In sintesi: Il parametro "Minimum attempts" controlla quanta evidenza sul rollout Capgo necessita prima che la policy di auto-pause possa intervenire.
Passaggio 2: Trovare l'impostazione Auto-Pause in Capgo
Per impostare il Capgo di auto pause minimum attempts, individua prima il canale che distribuisce il bundle. L'auto-pause fa parte del controllo del rollout, quindi modificare la config dell'updater a livello 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à utilizzato 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 possono includere il valore minimum attempts e un'impostazione di confidence. Mantieni questi campi insieme durante la revisione delle modifiche. Un campione minimo indica quando Capgo può giudicare 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 auditare
Usa la dashboard quando ti serve una modifica rapida e controllata e il tuo team registra le modifiche fatte dalla dashboard. Usa CLI quando l'impostazione deve stare in 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.
Qualunque percorso scegli, registra prima il vecchio valore. 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 in seguito il canale va in pausa.
Per i workflow basati su API, Capgo espone le risorse del canale tramite la sua API pubblica. La documentazione API del canale Capgo è il posto giusto per controllare 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 richiesto dal campo. Non aggiungere il segno di percentuale. Non usare decimali. Se i tuoi tool salvano la configurazione in JSON, mantieni esatta l'ortografia della chiave e preserva 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 sia cambiato. Verifica i dati del canale restituiti o il valore sulla dashboard.
Poi fatti tre domande:
- L'impostazione è cambiata sul canale corretto?
- Il canale punta ancora al bundle previsto?
- Il rollout è attivo, in pausa o completato?
Se il valore non appare, fermati. Controlla i permessi, l'ortografia del campo e l'identificativo del canale. Uno script di deployment che riporta il successo senza verificare lo stato salvato è difficile da fidarsi.
Passaggio 3: Scegli un valore sicuro per i tentativi minimi
Scegli il valore Capgo per l'auto pause minimum attempts in base alla dimensione e al rischio del rollout. Non esiste un numero sicuro per ogni app. La soglia corretta fornisce alla policy prove sufficienti, permettendo comunque di rilevare subito un aggiornamento errato.
Inizia dal gruppo più piccolo che possa fornirti dati 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 decisionale semplice
Chiediti quanti tentativi servono prima che un pattern di fallimento 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 feature ad alto rischio.
- Hai bisogno di feedback rapidi durante un test graduale.
- Il tuo team può ispezionare ogni fallimento subito dopo il rilascio.
Imposta un valore più alto quando:
- Il canale serve un mix eterogeneo di dispositivi.
- Gli utenti si connettono tramite reti instabili.
- L'app ha una bassa frequenza di apertura giornaliera.
- Un breve outage potrebbe generare molti falsi fallimenti.
Non usare la soglia per nascondere un problema noto. Se un bundle fallisce su un plugin nativo richiesto, metti 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 superata questa fase, sposta il bundle su un canale più ampio con una soglia che rifletta il campione più grande.
Questo approccio mantiene il primo segnale rapido senza costringere la policy di produzione a reagire a un campione minuscolo. Ti offre anche un punto chiaro per regolare l'impostazione. Cambia la soglia insieme al canale, non dopo che il rollout è già fallito.
Monitora il valore accanto al record del rilascio. Segna perché lo hai scelto, cosa ti porterebbe a cambiarlo e chi può approvare tale modifica. È fondamentale quando un membro del team vede un canale in pausa durante un incidente e ha bisogno di contesto immediato.
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 affidarti in produzione. Un canale definisce il perimetro del test. Puoi inviare un bundle a un gruppo noto, monitorare l'aumento dei tentativi e confermare cosa succede quando la policy raggiunge la soglia.
Per prima cosa, crea un bundle di test facilmente identificabile per non confonderlo con un rilascio live. Mantieni al sicuro la modifica code. Il test deve validare il controllo del rilascio, non creare un secondo problema all'app.
Successivamente, assegna un piccolo gruppo di dispositivi di test al canale. Verifica che ogni dispositivo abbia la versione dell'app nativa prevista. Gli code OTA non possono risolvere ogni mismatch nativo, quindi un dispositivo con il binary errato può rendere il test poco chiaro.
Pubblica il bundle sul canale. Se possibile, usa un comando nel tuo normale flusso di deployment Capgo, ma tieni traccia degli ID di bundle e canale nel log di rilascio. Non fare affidamento sullo scroll del terminale durante un incidente.
Testa il percorso di pause
Ti serve un modo sicuro per generare un tentativo fallito. Usa un bundle dedicato ai test o una condizione di errore controllata e approvata dal team. Non danneggiare mai un bundle di produzione solo per vedere se l'auto-pause funziona.
Monitora la seguente sequenza:
- Il canale punta al bundle di test.
- I dispositivi ricevono l'istruzione di update.
- I tentativi appaiono nella vista analytics.
- Viene raggiunto il numero minimo di tentativi.
- Il segnale di errore causa la pausa del canale, se le condizioni della policy sono soddisfatte.
Il quinto passaggio è fondamentale. Raggiungere il valore minimo di tentativi può rendere l'auto-pause idonea. Non significa che ogni rollout si interrompa esattamente a quel numero: altri campi della policy e gli esiti osservati possono influenzare il risultato.
Testa anche il recovery
Dopo la pausa, conferma cosa ricevono gli utenti. Verifica se il bundle fallito rimane selezionato, se i nuovi dispositivi smettono di riceverlo e se il precedente bundle sicuro è disponibile per il rollback. La risposta dipende dalla configurazione di updater e channel, quindi verifica tramite gli app logs invece di dare nulla per scontato.
Poi riprendi con un bundle sicuramente funzionante solo dopo che qualcuno ha analizzato il fallimento. Se l'errore deriva da un build errato, crea un nuovo bundle. Non limitarti a pushare lo stesso artifact sperando che il prossimo tentativo vada diversamente.
Documenta il risultato del test. Includi la soglia, il numero di dispositivi, la condizione di errore, il tempo di pausa e l'azione di recovery. Questo trasforma un test isolato in un controllo di rilascio ripetibile.
Passaggio 5: Monitora tentativi, analytics e rollback automatico
Il monitoraggio ti dice se la regola degli attempt minimi per l'auto-pause di Capgo sta gestendo un rollout sano o interrotto. Osserva il conteggio dei tentativi insieme al comportamento degli errori. Un conteggio senza contesto può portarti a una pausa troppo anticipata o a ignorare un problema in crescita.
Usa Capgo Observe per ispezionare l'attività degli update e lo stato del rollout. Il Documentazione di Capgo Observe descrive l'area utilizzata per visualizzare le info sugli update e configurare l'auto-pause. Tieni aperto il dashboard durante la prima fase di un rilascio, specialmente se il bundle modifica l'code di avvio o un flusso core dell'app.
Analizza i segnali insieme
Controlla prima il totale dei tentativi. Poi verifica il numero di fallimenti e il pattern temporale. Un flusso costante di installazioni riuscite è diverso da un picco di fallimenti dopo l'attivazione di un bundle.
Controlla i dettagli di device e versione app, se disponibili. Se i fallimenti si concentrano su una versione nativa, il bundle OTA potrebbe richiedere un binary più recente. Se i fallimenti avvengono su ogni versione, ispeziona il bundle o il percorso del servizio di update.
I problemi di rete possono creare rumore. Un breve outage può generare tentativi falliti senza un difetto code. Per questo la soglia deve operare con una policy di fiducia e un processo di revisione umana. L'auto-pause può limitare l'esposizione, ma non può spiegare ogni singolo fallimento.
Capisci cosa significa rollback nel tuo workflow
Un rollback riporta gli utenti interessati a un rilascio stabile o impedisce al rilascio errato di raggiungere altri device. Non ripara un binary nativo privo di una funzionalità necessaria. Inoltre, non può annullare una migrazione 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 in un posto accessibile all'ingegnere on-call.
di Capgo documentazione rollback può aiutarti a mappare i controlli di rollback disponibili sul tuo piano di canale. Usa il comportamento documentato come riferimento, poiché il risultato può dipendere dalla versione dell'updater e dalla configurazione del rilascio.
Durante un incidente, attiva la pausa se il pattern di errore è chiaro. Poi ispeziona i log e le modifiche al bundle. Passare pochi minuti a bloccare l'esposizione è solitamente più semplice che lasciare che un rilascio noto come errato continui a diffondersi.
Passaggio 6: Automatizza l'impostazione nella CI/CD
Inserisci il valore di Capgo auto pause minimum attempts nel tuo workflow di rilascio quando l'impostazione cambia per ogni canale. L'automazione elimina il drift manuale e rende la soglia scelta visibile durante la review in code.
Mantieni la policy del canale separata dai secrets. Il nome del canale, lo stage di rollout e il valore di minimum attempts possono risiedere 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à presente.
Un job di rilascio dovrebbe seguire un ordine chiaro:
- Build del web bundle.
- Esegui i test e controlla la compatibilità nativa.
- Upload del bundle.
- Imposta o conferma il canale di destinazione.
- Applica il valore dei tentativi minimi.
- Verifica lo stato del canale salvato.
- Pubblica o avanza il rollout.
Usa una dry-run o una fase di review se il tuo sistema di deployment la supporta. La review deve mostrare bundle identifier, canale, soglia e azione di rollout prima dell'esecuzione in produzione.
Rendi la verifica parte del job
Al termine del comando API o CLI, recupera nuovamente lo stato del canale. Fallisci il job se il valore restituito non corrisponde alla configurazione attesa. Questo permette di intercettare ID canale errati, campi rifiutati o update parziali.
Le variabili d'ambiente sono un modo comune per passare le impostazioni di release in 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 sono più facili da revisionare.
Per un controllo di sicurezza più approfondito, consulta la guida di Capgo per mettere in sicurezza gli aggiornamenti OTA nelle pipeline CI/CD. L'abitudine che conta è semplice: limita l'accesso ai token, logga la decisione di rilascio e verifica il risultato dopo ogni modifica.
Mantieni un registro delle modifiche
Memorizza la soglia insieme all'ID del commit o del rilascio. Aggiungi il motivo della modifica. Se un rollout si mette in pausa inaspettatamente, puoi confrontare la policy con il bundle e l'orario del deployment.
Capgo viene fatturato come 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 rilascio prima di renderlo parte del loro processo di delivery abituale. Mantieni il trial mirato: configura un canale, esegui un test di pausa e verifica un percorso di rollback.
Un solo comando può pubblicare l'update. Il workflow più sicuro è quello che controlla anche il canale, monitora l'adozione e lascia una via 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 attivarsi. È 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 risultati.
Dove imposto l'auto pause minimum attempts in Capgo?
Imposti il valore sul canale che distribuisce il bundle OTA. Usa la dashboard Capgo, CLI o la API pubblica, quindi rileggi il canale per confermare il campo salvato. Controlla prima il nome del canale. Modificare un canale di test mentre la produzione è attiva non cambierà il rollout in produzione.
Qual è un valore sicuro per i tentativi minimi?
Un valore sicuro dipende dalla dimensione del canale, dal mix di dispositivi, dalla qualità della rete e dal rischio del rilascio. Usa una soglia più bassa per un canale di test controllato. Usa una soglia più alta per un rollout di produzione esteso. Inizia con un gruppo noto, monitora il volume dei 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 Capgo tentativi rende il rollout idoneo all'auto-pause, ma contano anche le altre condizioni della policy. Segnali di errore, impostazioni di confidence, stato del canale e il flusso dell'updater possono influenzare il risultato. Testa l'intero percorso di pausa con un bundle sicuro prima di affidarti ad esso in produzione.
L'auto-pause può sostituire un piano di rollback?
No. L'auto-pause ferma o limita l'esposizione, mentre il rollback sposta gli utenti verso un bundle noto come funzionante, quando disponibile. Testa entrambi i controlli. Ricorda anche che un rollback OTA non può aggiungere funzionalità native che l'app installata non possiede.
Conclusione
Imposta il valore dei tentativi minimi per canale, non per abitudine. Inizia con un rollout di test limitato, verifica i percorsi di pause e rollback, quindi automatizza la configurazione approvata nella tua CI/CD. Se vuoi testare il workflow, prova Capgo con un singolo canale e un bundle controllato prima di estendere il rollout.
