Una pausa impedisce al rollout di raggiungere altri dispositivi. Un rollback riporta i dispositivi interessati a una versione stabile e verificata. Capgo supporta entrambi, così puoi prima contenere il problema e decidere come procedere.
Usa questi passaggi per scegliere l'azione corretta, verificarne l'effetto e ridurre la probabilità che l'incidente si ripeta.
Abbiamo analizzato 6 guide pubbliche su staged rollout e rollback pubblicate da Google Play, Amazon Appstore, CodePush di Microsoft, Bitrise, Nearform e Digia. Quattro su sei distinguono la pausa dal rollback come azioni separate, mentre due saltano il rollback o considerano la pausa come unica leva. Nessuna delle 6 spiega come verificare il ripristino tramite analytics o controlli sui dispositivi, e nessuna descrive un workflow per prevenire incidenti ricorrenti. Scegliere correttamente tra pausa e rollback, e poi confermarne l'efficacia, colma una lacuna che le linee guida pubbliche sui rilasci lasciano aperta.
Indice dei contenuti
- Passo 1: Configura i controlli di rilascio in Capgo
- Passo 2: Scegli se mettere in pausa o eseguire il rollback
- Passo 3: Sospendi ulteriori esposizioni mentre indaghi
- Passo 4: Esegui il rollback quando serve una versione stabile
- Fase 5: verifica il recovery con analytics e controlli sui dispositivi
- Passaggio 6: prevenire incidenti ricorrenti con workflow di rilascio più sicuri
- FAQ
- Conclusione
Passo 1: Configura i controlli di rilascio in Capgo
Prima di un incidente, assicurati che il tuo team sappia quale channel sta distribuendo il rilascio e quale bundle è stabile. Un channel è una corsia nominata che indirizza i dispositivi dell'app a un aggiornamento. Un bundle è il web code aggiornabile inviato attraverso quella corsia.
In Capgo, un rollout progressivo può mantenere un bundle stabile in posizione mentre invia un target di rollout separato a un gruppo selezionato. Questo ti fornisce un punto di controllo prima che il nuovo bundle raggiunga la base utenti più ampia. Rivedi i controlli del rollout progressivo prima di attivarne uno in produzione.
Annota il responsabile del rilascio e i segnali che dovrebbero fermare l'espansione. Ad esempio, decidi cosa farà il tuo team se gli errori di aggiornamento aumentano, se uno screen chiave smette di funzionare o se il supporto segnala che gli utenti non riescono a completare un task. Imposta limiti basati sul comportamento normale della tua app, invece di scegliere una soglia solo perché sembra rigorosa.
Un aggiornamento OTA modifica il code aggiornabile dell'app in modalità over-the-air. Non sostituisce il binario nativo dell'app installato da un app store. Il termine over-the-air update descrive questo approccio di distribuzione. Tieni presente questo confine: se una correzione richiede un nuovo plugin nativo o una modifica alla configurazione nativa dell'app, un rollback del bundle non la fornirà.
Prima del rilascio, verifica che il bundle stabile sia quello previsto. Controlla il nome del channel, il bundle di destinazione e lo stato del rollout. Un refuso nel nome del channel o un target obsoleto possono indirizzare i responsabili verso il controllo sbagliato quando ogni minuto conta.
A questo punto dovresti avere un release owner nominato, un bundle known-good e una condizione di stop scritta. Questa preparazione trasforma la decisione successiva in una scelta operativa, non in una corsa frenetica sul dashboard.
In sintesi: Una pausa limita la nuova esposizione. Un rollback cambia la versione a cui gli utenti vengono indirizzati.
Passo 2: Scegli se mettere in pausa o eseguire il rollback
Per la decisione tra pause rollout e rollback di Capgo, chiedi prima una cosa: stai cercando di impedire ad altri dispositivi di ricevere il target, o di spostare i dispositivi da un target che sta già causando danni? Una pausa limita la nuova esposizione. Un rollback rimuove il target e riporta i dispositivi al fallback stabile al prossimo controllo degli aggiornamenti.
Scegli la pausa quando le evidenze sono incomplete o il problema sembra limitato. Potresti avere pochi report ma non sapere se il bug riguarda un tipo di dispositivo, un flusso utente specifico o tutti i dispositivi aggiornati. La pausa dà al team lo spazio per analizzare il segnale senza aggiungere nuovi dispositivi al gruppo di rollout.
Scegli il rollback quando il target è chiaramente non sicuro per gli utenti, o quando il team ha prove sufficienti che il bundle noto come funzionante è più sicuro. Una pausa da sola non rimuove il target difettoso dai dispositivi già nella coorte di rollout. Se quegli utenti devono tornare alla versione stabile, il rollback è l'azione che cambia il loro percorso di aggiornamento.
Il Capgo canale CLI riferimento elenca controlli distinti per pausa e rollback. Trattali come azioni diverse, non come due nomi per lo stesso stop di emergenza.
| Cosa vedi | Prima azione | Cosa verificare dopo |
|---|---|---|
| Errori iniziali, ambito non chiaro | Metti in pausa il rollout | Confronta i dispositivi interessati e non interessati |
| Bug noto che interessa la coorte target | Rollback del target | Conferma che il bundle stabile è attivo |
| Problema legato a code nativo o a un servizio | Metti in pausa o contieni la modifica dell'app, poi correggi il layer interessato | Verifica se serve una riparazione del build nativo o del servizio |
| Solo un piccolo gruppo ha la versione target, senza impatto confermato sugli utenti | Metti in pausa durante l'indagine | Riprendi solo dopo l'approvazione del responsabile del rilascio |
Un rollback non risolve un'interruzione del backend e non può aggiungere una funzionalità nativa mancante. Identifica prima quale layer ha fallito. Se il problema è nel bundle web, scegli tra messa in pausa e revert in base a quanti utenti necessitano di un intervento.
Passo 3: Sospendi ulteriori esposizioni mentre indaghi
Metti in pausa quando devi impedire a nuovi dispositivi di entrare nel gruppo di rollout ma non sei ancora pronto a fare rollback del target per quelli già presenti. È una misura di contenimento: ti dà il tempo di verificare i fatti evitando che il problema si propaghi ad altri utenti.
Apri il canale di produzione e verifica di intervenire sul rollout interessato. Mettilo in pausa tramite la dashboard, CLI o il API usato dal tuo team. Poi rileggi lo stato del canale: non limitarti a verificare che il comando sia andato a buon fine, ma conferma che il rollout risulti effettivamente in pausa.
Nel modello di progressive rollout di Capgo, i dispositivi già nella cohort possono rimanere sul target del rollout anche dopo una pausa. I nuovi dispositivi idonei ricevono il fallback stable al controllo successivo. La distinzione conta: la pausa blocca i nuovi ingressi, ma non sposta di per sé la cohort esistente su stable.
Poi raccogli i dettagli del rilascio prima di fare altre modifiche. Registra il bundle target, il canale, l'orario della pausa e la prima segnalazione nota. Conserva i dettagli di dispositivi o sessioni che il tuo team è autorizzato a raccogliere. Una timeline chiara ti aiuta a confrontare la cohort del rollout con i dispositivi che usano ancora il bundle stable.
Verifica il problema seguendo un percorso riproducibile. Se gli utenti segnalano un login fallito, testa esattamente quel flusso su un dispositivo interessato. Se l'app crasha all'avvio, controlla se il crash è correlato al nuovo bundle e alla versione dell'app nativa. Evita di considerare ogni segnalazione di supporto come prova che l'update abbia causato il problema.
Assegna un responsabile e una scadenza per la decisione dell'indagine. Un rollout in pausa può restare in limbo se nessuno gestisce il prossimo passo. Il responsabile deve riprendere dopo che le evidenze confermano che la release è sicura, oppure scegliere il rollback se il target resta insicuro.
Consiglio pro: Avvisa il supporto e il team di release che il rollout è in pausa. Altrimenti un gruppo può continuare a escalare le segnalazioni mentre un altro dà per scontato che il rollout sia già stato annullato.
A questo punto, i nuovi dispositivi non dovrebbero più entrare nel cohort del rollout. Controlla lo stato del channel e il comportamento di un dispositivo che non faceva parte del cohort prima di passare al rollback o alla ripresa.
Passo 4: Esegui il rollback quando serve una versione stabile
Esegui il rollback quando gli utenti già sul target devono tornare a un bundle sicuramente funzionante. Questa è una risposta più incisiva della pausa. Cambia ciò che il channel distribuisce, quindi verifica la build stabile selezionata prima di confermare l'azione.
In Capgo, apri il canale interessato e controlla la cronologia delle build. Scegli la versione da ripristinare, poi conferma che sia il bundle stabile corretto per questa app e per questo canale. Capgo documentazione rollback descrive il percorso nella dashboard e precisa che i dispositivi riceveranno la build selezionata al prossimo controllo degli aggiornamenti.
Dopo il rollback, non dare per scontato che tutti i dispositivi siano cambiati subito. Un dispositivo deve controllare se ci sono aggiornamenti, e un utente offline potrebbe non farlo fino a più tardi. Tieni l'incidente aperto finché non hai verificato la versione attiva del canale e testato il percorso di recupero su un dispositivo del gruppo interessato.
Usa il bundle integrato solo quando è il target di recovery previsto. Riporta i dispositivi alla web build inclusa nell'app nativa, che potrebbe differire dall'ultimo bundle OTA. Verifica la compatibilità e l'impatto sugli utenti prima di sceglierlo come step di recovery.
Mantieni disponibile per l'analisi il bundle che ha causato l'incidente, a meno che il tuo processo di retention non preveda diversamente. Il release ID e il commit aiutano gli ingegneri a confrontare la modifica con la versione stabile. Conserva i log rilevanti prima del cleanup, soprattutto se devi capire perché il problema è sfuggito ai test.
Il rollback non è la soluzione giusta per ogni problema. Se la root cause è una dipendenza lato server, sistema quel servizio. Se la modifica dipende da code nativi assenti dai binari installati, prepara una Native Build e segui il percorso di rilascio degli app store per quella modifica.
Fase 5: verifica il recovery con analytics e controlli sui dispositivi
Dopo una pausa o un rollback, verifica cosa stanno facendo i dispositivi invece di considerare la modifica del controllo come prova di recovery. Controlla prima lo stato del canale attivo. Poi confronta l'adozione degli update, gli errori e i report dei dispositivi tra la release interessata e la versione stabile.
Le analytics di live update di Capgo ti aiutano a esaminare metriche di adozione, tassi di errore e log a livello di device. Usa questi segnali per rispondere a domande precise: i nuovi device ricevono ancora il target, i device interessati controllano il bundle stabile e il fallimento segnalato è cessato dopo il recovery?
Testa il percorso utente che ha dato errore. Un download riuscito non dimostra che l'app funzioni. Apri la schermata interessata, ripeti l'azione che ha portato alla segnalazione e verifica che l'app raggiunga lo stato atteso. Se l'incidente riguarda un flusso critico, fai confermare il risultato a qualcuno che non ha fatto la modifica.
Confronta dati omogenei. Un conteggio errori ampio può salire per motivi non legati al rilascio, come un problema di servizio o una variazione di traffico. Filtra per bundle, channel, versione dell'app e device dove questi campi sono disponibili. Cerca una differenza legata al rilascio invece di dare la colpa all'ultimo update per default.
Controlla anche gli utenti che non hanno aggiornato. La loro presenza può far sembrare sane le metriche complessive mentre la coorte interessata vede ancora il bug. Monitora la quota di device sul target rispetto a quella sul bundle stabile e lega le segnalazioni di supporto alla versione che gli utenti usano davvero.
Annota il risultato del recovery e l'incertezza che resta. Se gli errori calano ma alcuni utenti segnalano ancora lo stesso problema, non chiudere l'incidente finché non hai capito se sono offline, su una native shell più vecchia o stanno ancora usando il bundle interessato.
Il ripristino è confermato quando il canale punta alla versione prevista e il percorso utente che falliva funziona su un dispositivo in grado di riprodurre il problema. Le metriche aiutano a vedere la forma del problema; il controllo su dispositivo conferma ciò che la persona sperimenta.
Passaggio 6: prevenire incidenti ricorrenti con workflow di rilascio più sicuri
Integra pause e rollback nel piano di rilascio prima di pubblicare. Un release owner deve sapere chi può interrompere l'esposizione e chi può approvare il ritorno a stable. Questo elimina un ritardo comune: aspettare una riunione mentre altri dispositivi entrano nel rollout.
Mantieni un fallback stabile assegnato mentre testi il target del rollout. Parti da un gruppo piccolo e definito, poi espandi solo quando i segnali di salute concordati restano entro i tuoi limiti. Capgo supporta il controllo dei rilasci basato sui canali, così i team possono separare i test dalla distribuzione ampia in produzione.
Inserisci i controlli di rilascio nella CI/CD, il processo automatizzato che esegue i test e deploya una modifica. Una pipeline può pubblicare il bundle sul canale previsto dopo il superamento dei test. Deve anche fallire in modo sicuro se il canale è errato o se il rilascio non è pronto per la promozione.
Un workflow di continuous delivery mantiene il software pronto al rilascio tramite un processo automatizzato. Per un workflow OTA, mantieni chiaro il punto di approvazione umana anche quando la pubblicazione è automatizzata. L'automazione deve rendere ripetibile l'azione scelta, non prendere la decisione per una modifica non revisionata.
Con Capgo, un deployment con un solo comando può pubblicare un bundle su un channel. Mantieni il comando nello stesso processo di release dei tuoi check e rendi visibile il channel di destinazione nel record di deployment. Così l'ingegnere on-call vede esattamente cosa è stato rilasciato, senza dover indovinare quale lane lo abbia ricevuto.
Prima di abilitare le salvaguardie automatiche, definisci quale segnale le attiva e quale azione intraprendono. Una pausa può fermare la nuova esposizione mantenendo i dispositivi della cohort attuale sul target. Un rollback può indirizzare i dispositivi verso stable. Questi esiti sono diversi, quindi non configurare l'una come se fosse l'altra.
Usa un test channel per simulare l'intera procedura di risposta. Pubblica una modifica innocua, verifica il controllo di pausa e poi testa il rollback al bundle precedente. Conferma il comportamento dell'app su un dispositivo dopo ogni azione. Un runbook scritto dovrebbe includere il channel, il comando o il percorso nel dashboard, lo stato atteso e la persona che conferma il successo.
Le release notes dovrebbero identificare il bundle e il suo scopo. Mantieni un link tra il record di deployment e la modifica al codice sorgente, così gli ingegneri possono restringere la ricerca quando compare un errore. Se il tuo team passa la gestione degli incidenti tra fusi orari, includi l'ultima azione intrapresa e il responsabile della prossima decisione.
Se l'incidente punta a un collo di bottiglia più ampio nell'implementazione front-end, un web developer come Amir Arezoo potrebbe essere rilevante per lo sviluppo web. Questo è distinto dai controlli di rollout di Capgo, che gestiscono la distribuzione e il ripristino degli aggiornamenti app compatibili.
A questo punto, il tuo percorso di rilascio dovrebbe includere un fallback stabile, un responsabile, una regola di stop e un'azione di ripristino testata. Mantieni il workflow abbastanza breve da permettere all'ingegnere on-call di usarlo sotto pressione.
FAQ
Mettere in pausa un rollout di Capgo effettua il rollback sui dispositivi già aggiornati?
No. La pausa impedisce a nuovi dispositivi idonei di entrare nel rollout, ma i dispositivi già nella coorte possono restare sul bundle di destinazione. Per riportare quegli utenti sulla versione stabile, usa il rollback o un'altra azione mirata sul canale. Controlla lo stato del canale dopo ciascuna modifica, poi verifica il risultato su un dispositivo che ha ricevuto la versione target.
Quando dovrei mettere in pausa invece di fare un rollback?
Metti in pausa quando il problema è ancora in fase di analisi e devi fermare un'esposizione più ampia. Esegui il rollback quando si sa che il target danneggia gli utenti o quando i dispositivi interessati necessitano di un bundle stabile. La scelta tra pause rollout e rollback di Capgo dipende se l'esigenza immediata è contenimento o ripristino per la coorte esistente.
Un rollback aggiornerà subito tutti i dispositivi?
No. Un rollback modifica il bundle a cui punta il canale, ma i dispositivi lo ricevono al successivo controllo aggiornamenti. Un dispositivo offline può rimanere sul bundle attuale finché non si riconnette. Verifica il target del canale, poi controlla i dispositivi interessati e il loro stato di aggiornamento prima di dichiarare risolto l'incidente.
Un rollback OTA può risolvere un problema di un'app nativa?
No. Un rollback OTA può ripristinare un bundle web aggiornabile precedente, ma non può aggiungere o rimuovere code nativo all'interno di un binario di un'app installata. Se il problema deriva da un plugin nativo o da una modifica all'app-shell, valuta se serve una nuova build nativa. Per prima cosa identifica quale livello ha causato l'errore.
Cosa dovrei controllare dopo aver messo in pausa o fatto un rollback?
Conferma lo stato del canale e il bundle attivo, quindi verifica l'adozione degli aggiornamenti e gli errori per release. Testa il percorso utente che ha fallito su un dispositivo del gruppo interessato. Controlla anche i dispositivi che non hanno ancora aggiornato, poiché le metriche generali possono nascondere problemi limitati a una versione o a un coorte.
Conclusione
Metti in pausa quando devi fermare la nuova esposizione mentre indaghi. Fai rollback quando gli utenti sul target hanno bisogno di una versione stabile. Configura entrambi i controlli in anticipo, poi provali su un canale di test prima del prossimo rilascio in produzione.
