A fermare una distribuzione impedisce che raggiunga altri dispositivi. Un rollback sposta i dispositivi colpiti verso una versione nota. Capgo Supporta entrambi, quindi puoi contenere un problema prima di decidere cosa fare successivamente.
Segui questi passaggi per scegliere l'azione giusta, controllarne l'effetto e ridurre la possibilità di ripetere l'incidente.
Abbiamo letto 6 guide pubbliche sulla distribuzione in fase di testing e rollback pubblicate da Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform e Digia. Quattro delle 6 separano la pausa dalla rollback come azioni distinte, mentre 2 trascurano il rollback o trattano la pausa come l'unico strumento. Nessuna delle 6 spiega come verificare la ripresa con l'analisi dei dati o i controlli dei dispositivi, e nessuna descrive un flusso di lavoro per prevenire incidenti ripetuti. Ottenere la scelta tra pausa e rollback giusta, quindi confermarne l'efficacia, chiude una lacuna lasciata aperta nelle linee guida di rilascio pubbliche.
Tavola dei Contenuti
- Passo 1: Configura i controlli di rilascio in Capgo
- Passo 2: Scegli se fermare o tornare indietro
- Passo 3: Fermare l'esposizione ulteriore mentre indagini
- Passo 4: Reimposta quando gli utenti richiedono una versione stabile
- Verifica la ripresa con gli analisi e i controlli del dispositivo
- Passo 6: Prevenire incidenti ripetuti con flussi di rilascio più sicuri
- FAQ
- Conclusioni
Passo 1: Configura i controlli di rilascio in Capgo
Prima di un incidente, assicurati che il tuo team sappia quale canale sta distribuendo il rilascio e quale pacchetto è stabile. Un canale è una via denominata che dirige i dispositivi di app verso un aggiornamento. Un pacchetto è l'aggiornamento web code inviato attraverso quella via.
In Capgo, un rilascio progressivo può mantenere un pacchetto stabile in posizione mentre invia un obiettivo di rilascio separato a un gruppo selezionato. Ciò ti fornisce un punto di controllo prima che il nuovo pacchetto raggiunga la base utenti più ampia. Verifica i progressivi controlli di rilascio prima di abilitarli in produzione.
Scrivi il nome del proprietario del rilascio e i segnali che dovrebbero fermare l'espansione. Ad esempio, decidi cosa il tuo team farà se le fallite degli aggiornamenti aumentano, una schermata chiave smette di funzionare o il supporto riferisce che gli utenti non possono completare una task. Imposta limiti basati sul comportamento normale dell'app piuttosto che scegliere un limite solo perché sembra severo.
Un aggiornamento OTA cambia l'aggiornamento web code dell'app in modo wireless. Non sostituisce il binario nativo dell'app installato da un negozio di app. Il termine aggiornamento wireless descrive questo approccio di consegna. Tieni presente questo confine: se un fix richiede un nuovo plugin nativo o una modifica alla configurazione nativa dell'app, un rollback del pacchetto non lo fornirà.
Prima della rilascio, conferma che il bundle stabile sia quello che ti aspetti. Controlla il nome del canale, il bundle di destinazione e lo stato di distribuzione. Un errore di battitura nel nome del canale o un bundle obsoleto possono mandare i rispondenti verso il controllo sbagliato quando ogni minuto conta.
Da ora dovresti avere un proprietario di rilascio con nome, un bundle noto buono e una condizione di arresto scritta. Quella preparazione trasforma la prossima decisione in un'opzione operativa, non una ricerca disordinata nel dashboard.
Chiave di apprendimento: Un'interruzione limita l'esposizione nuova. Un rollback cambia la versione ai quali gli utenti sono diretti per ricevere.
Passo 2: Scegli se interrompere o tornare indietro
Per la decisione di interruzione del rollout vs rollback Capgo, chiedi una domanda prima: stai cercando di fermare più dispositivi dal ricevere il target, o spingere i dispositivi da un target che già sta causando danni? Un'interruzione limita l'esposizione nuova. Un rollback cancella il target e restituisce i dispositivi al fallback stabile sul loro prossimo controllo di aggiornamento.
Scegli l'interruzione quando la prova è incompleta o l'incidente sembra limitato. Potresti avere un pugno di segnalazioni ma non sapere se il bug colpisce un tipo di dispositivo, un flusso di utente specifico o ogni dispositivo aggiornato. L'interruzione dà al team lo spazio per esaminare il segnale senza aggiungere nuovi dispositivi al gruppo di distribuzione.
Scegliere il rollback quando il bersaglio è chiaramente pericoloso per gli utenti, o quando il team ha abbastanza prove che il bundle noto è più sicuro. Una sola pausa non elimina il bersaglio dannoso dai dispositivi già nella cohort di distribuzione. Se gli utenti devono tornare a stabile, il rollback è l'azione che cambia il loro percorso di aggiornamento.
Scegli Scegliere il canale Capgo di riferimento CLI controlli di pausa e rollback separati. Trattali come azioni diverse, non due nomi per lo stesso arresto di emergenza.
| Cosa vedi | Prima azione | Cosa controllare successivamente |
|---|---|---|
| Cosa controllare di seguito | Errori precoci, ambito incerto | Confronta dispositivi colpiti e non colpiti |
| Confronta dispositivi colpiti e non colpiti | Ripristina il target | Conferma che il bundle stabile è attivo |
| Problema legato a un code nativo o a un servizio | Sospendi o blocca l'aggiornamento dell'app, quindi ripara il layer interessato | Controlla se è necessario un build nativo o un riparazione del servizio |
| Solo un piccolo gruppo ha l'obiettivo, con nessun impatto confermato per l'utente | Sospendi mentre si indaga | Resume only after the release owner approves |
Un rollback non risolverà un'interruzione del backend e non potrà aggiungere una capacità nativa mancante. Identifica prima il layer che ha fallito. Se il bundle web è responsabile, scegli tra la sospensione e il ripristino in base al numero di utenti che necessitano di sollievo.
Passo 3: Fermare l'esposizione ulteriore mentre indaghi
Sospendi quando hai bisogno di fermare nuovi dispositivi dall'ingresso nel gruppo di distribuzione, ma non sei pronto a ripristinare il target per i dispositivi già in esso. Questo è un passo di contenimento. Acquista tempo per verificare i fatti mentre impedisce che l'errore si diffonda a più utenti.
Apri il canale di produzione e verifica di essere in grado di agire sull'implementazione interessata. Fermalo con il dashboard, CLI, o API che il tuo team utilizza. Poi leggi lo stato del canale. Non contare solo sul completamento con successo di un comando; conferma che l'implementazione ora mostra come fermata.
In Capgo’s modello di rollout progressivo, i dispositivi già nella cohort possono rimanere sul target di rollout dopo una pausa. I nuovi dispositivi idonei ricevono il fallback stabile al loro prossimo controllo. Quella distinzione conta: la pausa ferma l'ingresso nuovo, ma non sposta da solo la cohort esistente verso lo stabile.
Successivamente, cattura i dettagli della release prima di fare un'altra modifica. Registra il bundle di destinazione, il canale, l'ora della pausa e il primo rapporto noto. Conserva i dettagli del dispositivo o della sessione che il tuo team è autorizzato a raccogliere. Una chiara timeline ti aiuta a confrontare la cohort di rollout con i dispositivi ancora sul bundle stabile.
Controlla l'errore attraverso un percorso ripetibile. Se gli utenti segnalano un login fallito, testa quel viaggio esatto su un dispositivo interessato. Se l'app si blocca al lancio, controlla se il crash si allinea con il nuovo bundle e la versione nativa dell'app. Evita di considerare ogni rapporto di supporto come prova che l'aggiornamento ha causato il problema.
Imponi un proprietario e un orario di decisione per l'indagine. Un rollout pausato può rimanere in limbo se nessuno assume il prossimo passo. Il proprietario dovrebbe o riprendere dopo che la release è stata chiarita o scegliere il rollback quando il target rimane pericoloso.
Pro consiglio: Informare il supporto e l'equipaggio di rilascio che il rollout è stato sospeso. Altrimenti, un gruppo potrebbe continuare a segnalare rapporti mentre un altro assume che il rollout sia già stato annullato.
Ora, i dispositivi nuovi non dovrebbero più entrare nel cohort di distribuzione. Controlla lo stato del canale e il comportamento di un dispositivo che non faceva parte del cohort prima di passare al rollback o alla ripresa.
Passo 4: Reimposta quando gli utenti hanno bisogno di una versione stabile
Reimposta quando gli utenti già su target devono spostarsi verso un bundle noto buono. Questo è il risposta più forte rispetto al pausa. Cambia cosa il canale serve, quindi verifica la versione stabile selezionata prima di confermare l'azione.
In Capgo, apri il canale interessato e revisiona la sua storia di build. Scegli la versione che desideri ripristinare, quindi conferma che è il bundle stabile corretto per questa app e canale. Capgo documentazione del rollback descrive il percorso del dashboard e nota che i dispositivi ricevono la build selezionata la prossima volta che controllano per un aggiornamento.
Dopo il rollback, non assumere che ogni dispositivo sia cambiato subito. Un dispositivo ha bisogno di controllare per un aggiornamento, e un utente offline potrebbe non farlo fino a più tardi. Tieni l'incidente aperto fino a quando non hai controllato la versione attiva del canale e hai testato il percorso di recupero su un dispositivo nel cohort interessato.
Usa solo il bundle integrato quando è il target di recupero intenzionale. Punti i dispositivi verso il build web incorporato all'interno dell'app nativa, che potrebbe differire dalla versione OTA precedente. Controlla la compatibilità e l'impatto dell'utente prima di sceglierlo come passo di recupero.
Conserva il bundle che ha causato l'incidente per l'analisi a meno che il tuo processo di conservazione non dica il contrario. L'ID di rilascio e il commit aiutano gli ingegneri a confrontare il cambiamento con la versione stabile. Preserva i log pertinenti prima della pulizia, soprattutto se hai bisogno di capire perché l'errore è sfuggito ai test.
La rollback non è la soluzione giusta per ogni fallimento. Se la causa radice è una dipendenza server-side, ripara quel servizio. Se il cambiamento dipende da una code nativa assente dai binari installati, prepara una build nativa e segui il percorso di rilascio dell'app store per quel cambiamento.
Verifica la ripristino con gli analisi e i controlli dispositivi
After a pause or rollback, verify what devices are doing rather than treating the control change as proof of recovery. Check the active channel state first. Then compare update adoption, errors, and device reports across the affected release and the stable version.
Capgo’s live update analytics can help you inspect adoption metrics, error rates, and device-level logs. Use those signals to answer specific questions: are new devices still receiving the target, are affected devices checking for the stable bundle, and did the reported failure stop after recovery?
Verifica il percorso utente che ha fallito. Un download riuscito non dimostra che l'app funziona. Apri la schermata relativa, ripeti l'azione che ha portato al report e verifica che l'app raggiunga lo stato previsto. Se l'incidente coinvolge un flusso critico, fai confermare il risultato da qualcuno diverso da chi ha apportato il cambiamento.
Confronta con simili. Un conteggio di errori ampio può aumentare per motivi non correlati alla release, come un problema di servizio o un cambiamento nel traffico. Filtra per bundle, canale, versione dell'app e dispositivo dove sono disponibili. Cerca una differenza collegata alla release piuttosto che incolpare l'aggiornamento più recente per default.
Controlla anche gli utenti che non hanno effettuato l'aggiornamento. La loro presenza può rendere le metriche generali sane mentre il gruppo interessato continua a vedere il bug. Traccia la quota di dispositivi sul canale di destinazione rispetto a quella sul canale stabile, e mantieni i report di supporto legati alla versione che gli utenti effettivamente utilizzano.
Riporta il risultato di recupero e la rimanente incertezza. Se gli errori diminuiscono ma alcuni utenti continuano a segnalare lo stesso problema, non chiudi l'incidente fino a quando non capisci se sono offline, utilizzano una shell nativa più vecchia o ancora il bundle interessato.
La ripresa è confermata quando il canale punta alla versione prevista e il percorso utente che falliva funziona su un dispositivo che poteva riprodurre l'errore. Le metriche ti aiutano a vedere la forma del problema; un controllo del dispositivo conferma ciò che una persona sperimenta.
Passo 6: Prevenire incidenti ripetuti con flussi di rilascio più sicuri
Assicurarsi che la pausa e il rollback siano parte del piano di rilascio prima di pubblicare. Il proprietario di rilascio dovrebbe sapere chi può fermare l'esposizione e chi può approvare il ritorno allo stato stabile. Ciò elimina un ritardo comune: l'attesa di una riunione mentre più dispositivi entrano nella distribuzione.
Tenere un fallback stabile assegnato mentre il target di distribuzione viene testato. Utilizzare un piccolo gruppo definito per primo, poi espandere solo quando i segnali di salute concordati rimangono entro i tuoi limiti. Capgo supporta il controllo di rilascio basato sui canali, quindi i team possono separare il testing dalla consegna di produzione ampia.
Collocare i controlli di rilascio in CI/CD, il processo automatizzato che esegue i test e distribuisce un cambiamento. Una pipeline può pubblicare il bundle al canale inteso dopo che i test passano. Dovrebbe anche fallire in modo sicuro se il canale è sbagliato o il rilascio non è pronto per la promozione.
Un flusso di consegna continuo tiene il software pronto per il rilascio attraverso un processo automatizzato. Per un workflow OTA, tenere il punto di approvazione umana chiaro anche quando la pubblicazione è automatizzata. L'automazione dovrebbe rendere l'azione scelta ripetibile, non prendere la decisione per un cambiamento non revisionato.
Con Capgo, un'unica operazione di deployment può pubblicare un bundle a un canale. Tenere il comando nella stessa procedura di rilascio dei controlli e rendere il canale di destinazione visibile nel registro di deployment. Ciò aiuta l'ingegnere di chiamata vedere esattamente cosa è stato spedito senza dover indovinare quale pista l'ha ricevuto.
Prima di abilitare le misure di sicurezza automatiche, definisci il segnale che le attiva e l'azione che eseguono. Un'interruzione può fermare la nuova esposizione mentre mantiene i dispositivi della cohort corrente sul target. Un rollback può dirigere i dispositivi verso lo stato stabile. Questi esiti differiscono, quindi non configurare uno come se fosse l'altro.
Utilizza un canale di test per eseguire la prova completa. Pubblica un cambiamento innocuo, verifica il controllo di pausa e quindi testa il rollback al bundle precedente. Conferma il comportamento dell'applicazione su un dispositivo dopo ogni azione. Il runbook scritto dovrebbe includere il canale, la struttura di comando o la cartella del dashboard, lo stato previsto e la persona che conferma il successo.
Il rilascio dovrebbe includere le note che identificano il bundle e il suo scopo. Mantieni un collegamento tra il record di distribuzione e il cambiamento di origine affinché gli ingegneri possano ridurre la ricerca quando un errore compare. Se il tuo team si occupa di incidenti in diverse zone orarie, includi l'azione più recente e il prossimo proprietario della decisione.
Se l'incidente indica un blocco di implementazione front-end più ampio, un web developer come Amir Arezoo Potrebbe essere rilevante per il lavoro di sviluppo web. Ciò è separato dai controlli di Capgo per la distribuzione e il ripristino degli aggiornamenti di app compatibili.
Ora, il tuo percorso di rilascio dovrebbe includere un fallback stabile, un proprietario, una regola di arresto e un'azione di recupero testata. Mantieni il workflow breve in modo che l'ingegnere di chiamata possa usarlo sotto pressione.
FAQ
Sospende un Capgo rollout: torna indietro i dispositivi già aggiornati?
No. La pausa ferma nuovi dispositivi idonei dall'ingresso nella distribuzione, ma i dispositivi già nella cohort possono rimanere sul bundle di destinazione. Per spostare gli utenti verso lo stato stabile, utilizza il rollback o un'altra azione del canale deliberata. Controlla lo stato del canale dopo ogni modifica, quindi conferma il risultato su un dispositivo che ha ricevuto il target.
Quando dovresti pausare invece di ripristinare?
Pause when the issue is still under investigation and you need to stop wider exposure. Roll back when the target is known to harm users or when affected devices need a stable bundle. The Capgo pause rollout vs rollback choice depends on whether the immediate need is containment or recovery for the existing cohort.
Un rollback aggiornerebbe tutti i dispositivi immediatamente?
No. Un rollback cambia il bundle al quale il canale punta, ma i dispositivi lo ricevono quando controllano l'aggiornamento successivo. Un dispositivo offline può rimanere sul suo bundle corrente fino a quando non si riattiva. Verifica il target del canale, quindi controlla i dispositivi interessati e lo stato dell'aggiornamento prima di dichiarare l'incidente risolto.
Un rollback OTA può risolvere un problema di app nativa?
No. An OTA rollback can restore an earlier updateable web bundle, but it can’t add or remove native code inside an installed app binary. If the issue comes from a native plugin or app-shell change, assess whether a new native build is needed. First identify which layer caused the failure.
Cosa dovresti controllare dopo aver pausato o ripristinato?
Conferma lo stato del canale e del bundle attivo, quindi controlla l'adozione e gli errori delle versioni. Testa il percorso utente che ha fallito su un dispositivo del gruppo interessato. Controlla anche i dispositivi che non sono stati aggiornati ancora, poiché i metri generali possono nascondere problemi limitati a una versione o a un cohort.
Conclusioni
Pausa quando hai bisogno di fermare l'esposizione nuova mentre investighi. Reimposta quando gli utenti del target hanno bisogno di una versione stabile. Imposta entrambi i controlli in anticipo, quindi esercitali su un canale di test prima della tua prossima rilascio di produzione.
