Una pausa interrompe il rollout verso nuovi dispositivi. Un rollback riporta i dispositivi interessati a una versione stabile. Capgo supporta entrambi, così puoi prima contenere il problema e poi decidere come procedere.
Segui questi passaggi per scegliere l'azione corretta, verificarne l'effetto e ridurre il rischio di ripetere l'incidente.
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 unico strumento. 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 pause e rollback, e poi confermarne l'efficacia, colma una lacuna presente in tutte le guide pubbliche al rilascio.
Indice dei contenuti
- Passaggio 1: Configura i controlli di rilascio in Capgo
- Passaggio 2: Scegli se mettere in pausa o fare il rollback
- Passaggio 3: Ferma l'esposizione mentre investigi
- Passaggio 4: Esegui il rollback per versioni stabili
- Passaggio 5: Verifica il ripristino con analytics e device
- Passaggio 6: Evita incidenti con workflow di rilascio sicuri
- FAQ
- Conclusione
Passaggio 1: Configura i controlli di rilascio in Capgo
Prima di un incidente, assicurati che il team sappia quale channel sta distribuendo il rilascio e quale bundle è stabile. Un channel è una corsia nominata che indirizza i dispositivi verso un update. Un bundle è il code web aggiornabile inviato tramite quel channel.
In Capgo, un progressive rollout può mantenere un bundle stabile mentre invia un target di rollout separato a un gruppo selezionato. Questo ti offre un punto di controllo prima che il nuovo bundle raggiunga la base utenti più ampia. Controlla i controlli del progressive rollout prima di abilitarne uno in produzione.
Individua il responsabile del rilascio e i segnali che devono bloccare l'espansione. Ad esempio, decidi cosa farà il tuo team se aumentano i fallimenti degli update, se una schermata chiave smette di funzionare o se il supporto segnala che gli utenti non riescono a completare un task. Imposta dei limiti basati sul comportamento normale della tua app, invece di scegliere una soglia solo perché sembra rigorosa.
Un update OTA modifica gli code aggiornabili dell'app via air. Non sostituisce il binario nativo installato tramite app store. Il termine over-the-air update descrive questo approccio di distribuzione. Tieni a mente questo confine: se una fix richiede un nuovo plugin nativo o una modifica alla configurazione nativa dell'app, un rollback del bundle non la fornirà.
Prima del rilascio, conferma che il bundle stabile sia quello previsto. Controlla il nome del channel, il target bundle e lo stato del rollout. Un errore di battitura nel nome di un channel o un target obsoleto possono indirizzare i responsabili verso il controllo sbagliato quando ogni minuto conta.
A questo punto dovresti avere un responsabile del rilascio, un bundle testato e una condizione di stop scritta. Questa preparazione trasforma la decisione successiva in una scelta operativa, non in una corsa frenetica nel dashboard.
In sintesi: Un pause limita la nuova esposizione. Un rollback cambia la versione che gli utenti riceveranno.
Passaggio 2: Scegli tra pause o rollback
Per decidere tra Capgo pause rollout e rollback, poniti prima una domanda: vuoi evitare che altri dispositivi ricevano il target, o vuoi rimuovere il target da chi lo ha già ricevuto e sta riscontrando problemi? Una pausa limita la nuova esposizione. Un rollback rimuove il target e riporta i dispositivi alla versione stabile al prossimo controllo degli update.
Scegli la pausa quando le prove sono incomplete o il problema sembra limitato. Potresti avere pochi report senza sapere se il bug riguarda un tipo di dispositivo, un particolare flusso utente o ogni dispositivo aggiornato. La pausa permette al team di analizzare i segnali senza aggiungere nuovi dispositivi al gruppo di rollout.
Scegli il rollback quando il target è chiaramente insicuro per gli utenti, o quando il team ha prove sufficienti che il bundle noto come stabile sia più sicuro. Una pausa non rimuove il target dai dispositivi già inclusi nel rollout. Se quegli utenti devono tornare alla versione stabile, il rollback è l'azione che modifica il loro percorso di update.
L'oggetto canale Capgo riferimento CLI elenca controlli separati per pause e rollback. Trattali come azioni diverse, non come due nomi per lo stesso stop di emergenza.
| Cosa vedi | Prima azione | Cosa controllare dopo |
|---|---|---|
| Errori iniziali, scope poco chiaro | Metti in pausa il rollout | Confronta i dispositivi interessati e non |
| Bug noto che colpisce la cohort target | Effettua il rollback del target | Conferma che il bundle stabile sia attivo |
| Problema legato a code nativo o a un servizio | Metti in pausa o isola il cambiamento, poi correggi lo strato interessato | Verifica se serve un Native Build o la riparazione di un servizio |
| Solo un piccolo gruppo ha il target, nessun impatto utente confermato | Metti in pausa durante l'indagine | Riprendi solo dopo l'approvazione del release owner |
Un rollback non risolverà un outage del backend e non può aggiungere una funzionalità nativa mancante. Identifica prima quale strato è fallito. Se il problema è il web bundle, scegli tra pausa e rollback in base a quanti utenti necessitano di un fix immediato.
Passaggio 3: Metti in pausa l'esposizione mentre investighi
Usa la pausa quando devi impedire ai nuovi dispositivi di entrare nel gruppo di rollout, ma non sei ancora pronto a revertire il target per quelli già inclusi. È una misura di contenimento che ti permette di verificare i fatti senza far propagare il problema ad altri utenti.
Apri il canale di produzione e verifica di agire sul rollout interessato. Mettilo in pausa tramite la dashboard, CLI o il sistema di controllo API usato dal tuo team. Poi verifica lo stato del canale: non limitarti a confermare l'esecuzione del comando, assicurati che il rollout risulti effettivamente in pausa.
Nel modello di progressive rollout di Capgo, i dispositivi già nella coorte possono rimanere sul target del rollout anche dopo la pausa. I nuovi dispositivi idonei riceveranno la versione stable al controllo successivo. Questa distinzione è fondamentale: la pausa blocca i nuovi ingressi, ma non riporta automaticamente la coorte esistente alla versione stable.
Successivamente, cattura i dettagli del rilascio prima di apportare altre modifiche. Registra il bundle target, il canale, l'orario della pausa e il primo report ricevuto. Conserva i dettagli di dispositivi o sessioni che il tuo team è autorizzato a raccogliere. Una timeline chiara ti aiuterà a confrontare la coorte del rollout con i dispositivi che usano ancora il bundle stable.
Verifica il problema seguendo un percorso riproducibile. Se gli utenti segnalano un errore nel login, testa esattamente quel flusso su un dispositivo interessato. Se l'app crasha all'avvio, controlla se il crash è correlato al nuovo bundle o alla versione della native app. Evita di considerare ogni segnalazione di supporto come prova certa che l'update abbia causato il problema.
Assegna un responsabile e un tempo limite per l'indagine. Un rollout in pausa può rimanere in sospeso se nessuno gestisce il passo successivo. Il responsabile dovrà riprendere il rollout dopo aver verificato la release o scegliere il rollback se il target risulta ancora insicuro.
Consiglio pro: Informa il supporto e il team di release che il rollout è in pausa. Altrimenti, un gruppo potrebbe continuare a segnalare problemi mentre l'altro assume 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 canale e il comportamento di un dispositivo che non faceva parte del cohort prima di procedere con il rollback o la ripresa.
Passaggio 4: Rollback quando gli utenti necessitano di una versione stabile
Esegui il rollback quando gli utenti già sul target devono tornare a un bundle noto come stabile. Questa è una risposta più drastica rispetto alla pausa. Poiché modifica ciò che il canale serve, 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 che vuoi ripristinare, quindi conferma che sia il bundle stabile corretto per questa app e questo canale. La documentazione di Capgo sul documentazione sul rollback descrive il percorso nel dashboard e specifica che i dispositivi riceveranno la build selezionata al prossimo controllo di un aggiornamento.
Dopo il rollback, non dare per scontato che ogni dispositivo si sia aggiornato istantaneamente. Un dispositivo deve controllare se ci sono aggiornamenti e un utente offline potrebbe non farlo fino a più tardi. Mantieni l'incidente aperto finché non avrai verificato la versione attiva del canale e testato il percorso di recovery su un dispositivo nel cohort interessato.
Usa il bundle integrato solo se è l'obiettivo di recovery desiderato. Reindirizza i dispositivi alla web build inclusa nell'app nativa, che potrebbe differire dall'ultimo bundle OTA. Verifica compatibilità e impatto sugli utenti prima di usarlo come step di recovery.
Conserva il bundle che ha causato l'incidente per l'analisi, 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. Preserva i log rilevanti prima della pulizia, specialmente se devi capire perché il problema è sfuggito ai test.
Il rollback non è la soluzione per ogni errore. Se la root cause è una dipendenza lato server, ripara quel servizio. Se la modifica dipende da code nativi assenti nei binari installati, prepara un Native Build e segui il percorso di rilascio degli app store.
Step 5: Verifica il recovery con analytics e controlli sui dispositivi
Dopo un pause o un rollback, verifica cosa stanno facendo i dispositivi invece di considerare la modifica del controllo come prova del 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 dispositivo. Usa questi segnali per rispondere a domande precise: i nuovi dispositivi ricevono ancora il target, i dispositivi interessati controllano il bundle stabile e il fallimento segnalato è cessato dopo il ripristino?
Testa il percorso utente che ha fallito. 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 previsto. 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ò aumentare per motivi non legati al rilascio, come un problema di servizio o una variazione di traffico. Filtra per bundle, channel, versione dell'app e dispositivo dove questi campi sono disponibili. Cerca una differenza legata al rilascio invece di dare per scontato che sia colpa dell'ultimo update.
Controlla anche gli utenti che non hanno aggiornato. La loro presenza può far sembrare sane le metriche complessive mentre il gruppo interessato vede ancora il bug. Monitora la quota di dispositivi sul target rispetto a quella sulla versione stabile e tieni le segnalazioni di supporto legate alla versione che gli utenti usano davvero.
Annota il risultato del ripristino e le incertezze che restano. Se gli errori calano ma alcuni utenti segnalano ancora lo stesso problema, non chiudere l'incidente finché non capisci se sono offline, su una native shell più vecchia o ancora sul bundle interessato.
Il ripristino è confermato quando il canale punta alla versione desiderata e il percorso dell'utente che presentava l'errore funziona su un dispositivo che poteva riprodurre il problema. Le metriche aiutano a capire l'entità del problema; un controllo sul dispositivo conferma l'esperienza reale dell'utente.
Passaggio 6: Prevenire incidenti ricorrenti con workflow di rilascio più sicuri
Includi pause e rollback nel piano di rilascio prima del publishing. Un release owner deve sapere chi può interrompere l'esposizione e chi può approvare il ritorno alla versione stable. Questo elimina un ritardo comune: aspettare una riunione mentre altri dispositivi entrano nel rollout.
Mantieni un fallback stabile assegnato durante il test del rollout. Usa prima una coorte piccola e definita, poi espandi solo quando i segnali di health concordati rimangono entro i limiti. Capgo supporta il controllo dei rilasci basato sui canali, permettendo ai team di separare i test dal rilascio massivo 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 inoltre 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 per il rilascio tramite un processo automatizzato. Per un workflow OTA, mantieni chiaro il punto di approvazione umana anche quando il publishing è automatizzato. L'automazione deve rendere l'azione scelta ripetibile, non prendere decisioni su una modifica non revisionata.
Con Capgo, un deployment con un solo comando può pubblicare un bundle su un canale. Mantieni il comando nello stesso processo di release dei tuoi controlli e rendi visibile il canale di destinazione nel registro di deployment. Questo aiuta l'ingegnere on-call a vedere esattamente cosa è stato rilasciato, senza dover indovinare quale lane lo abbia ricevuto.
Prima di attivare le protezioni automatiche, definisci quale segnale le innesca e quale azione devono compiere. Una pausa può bloccare la nuova esposizione mantenendo i dispositivi della coorte attuale sul target. Un rollback può reindirizzare i dispositivi verso la versione stabile. Questi esiti sono diversi, quindi non configurare l'una come se fosse l'altra.
Usa un canale di test per simulare l'intera risposta. Pubblica una modifica innocua, verifica il controllo della 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 canale, 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 registro di deployment e la modifica al codice sorgente, così gli ingegneri possano restringere il campo della ricerca quando appare un errore. Se il tuo team si passa la gestione degli incidenti tra fusi orari, includi l'ultima azione intrapresa e il responsabile della prossima decisione.
Se l'incidente indica 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 processo di rilascio dovrebbe includere un fallback stabile, un responsabile, una regola di stop e un'azione di recovery 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 ai nuovi dispositivi idonei di entrare nel rollout, ma i dispositivi già presenti nel cohort possono rimanere sul bundle target. Per riportare quegli utenti a una versione stabile, usa il rollback o un'altra azione deliberata sul canale. Controlla lo stato del canale dopo ogni modifica e conferma il risultato su un dispositivo che ha ricevuto il target.
Quando dovrei mettere in pausa invece di fare un rollback?
Metti in pausa quando il problema è ancora in fase di investigazione e devi limitare l'esposizione. Fai il rollback quando è noto che il target danneggia gli utenti o quando i dispositivi coinvolti necessitano di un bundle stabile. La scelta tra Capgo pause rollout vs rollback dipende dal fatto che l'esigenza immediata sia il contenimento o il recovery del cohort esistente.
Un rollback aggiornerà tutti i dispositivi immediatamente?
No. Un rollback cambia il bundle a cui punta il canale, ma i dispositivi lo riceveranno al prossimo controllo degli aggiornamenti. Un dispositivo offline potrebbe 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 nativi all'interno del binario dell'app installata. Se il problema deriva da un plugin nativo o da una modifica dell'app shell, valuta se serve un nuovo Native Build. Prima identifica quale layer ha causato l'errore.
Cosa devo controllare dopo aver messo in pausa o fatto un rollback?
Conferma lo stato del canale e il bundle attivo, poi controlla l'adozione degli update e gli errori per release. Testa il percorso utente che non ha funzionato su un dispositivo del gruppo interessato. Controlla anche i dispositivi che non si sono ancora aggiornati, visto che le metriche generali possono nascondere problemi limitati a una singola versione o coorte.
Conclusione
Metti in pausa quando devi fermare l'esposizione a nuovi utenti mentre indaghi. Fai rollback quando gli utenti 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.
