Risolvi: il canale default di Capgo non aggiorna i dispositivi

Cambiare il Cloud Default in Capgo indirizza subito i nuovi dispositivi. Le installazioni esistenti possono restare sul vecchio canale finché non effettuano di nuovo il check-in, il che spiega molti casi in cui un canale Cloud Default di Capgo non aggiorna i dispositivi.

Esegui i controlli in ordine. Verifica prima l'assegnazione del dispositivo, poi ispeziona la build dell'app, lo stato di sincronizzazione, le regole di rollout, i log e le impostazioni di rollback.

Indice dei contenuti

• Passo 1: Conferma che il dispositivo è assegnato al canale predefinito
• Passaggio 2: Verifica l'app, il runtime nativo e la compatibilità dell'update
• Passo 3: Verifica che il deployment abbia effettivamente raggiunto il canale predefinito
• Passo 4: Forza una nuova sincronizzazione e ispeziona i log lato dispositivo
• Passo 5: Revisiona regole di rollout, gate di versione e rollback automatico
• Passo 6: Usa le analytics in tempo reale per trovare il punto esatto del fallimento
• Passo 7: Impedisci che il canale predefinito diventi obsoleto
• FAQ
• Conclusione

Passo 1: Conferma che il dispositivo è assegnato al canale predefinito

L'obiettivo è capire quale regola decide attualmente il canale del dispositivo. Un Cloud Default si applica solo se un'assegnazione più forte non ha già reclamato il dispositivo.

Apri il dashboard Capgo e ispeziona il dispositivo interessato. Controlla il suo canale attuale, l'app ID, la versione e l'ultimo check-in. Confronta questi valori con un dispositivo che ha ricevuto l'aggiornamento previsto. Questo confronto spesso rivela rapidamente il problema.

La selezione del canale segue un ordine. Un canale forzato ha la massima priorità. Segue un override del dashboard o del dispositivo API. Poi viene un canale locale impostato dall'app. Quindi Capgo verificadefaultChannelnella configurazione dell'app nativa. Il Cloud Default è il fallback.

Questo ordine significa che un dispositivo può ignorare un Cloud Default modificato senza alcun errore nel dashboard. Ad esempio, una build di test potrebbe ancora avere un canale locale da un test precedente. L'app continua a usare quel valore locale finché non lo rimuovi.

Usa il Guida alla debug di Capgo updater quando il canale risolto è vuoto o inaspettato. Copre il caso in cui l'app non ha un default utilizzabile e il dispositivo non ha un override.

Successivamente, controlla la configurazione di Capacitor. Una configurazione tipica può includere un canale come questo:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

Il campo è opzionale. Se lo ometti, il dispositivo può ereditare il Cloud Default. Questo può funzionare bene per le build di produzione perché il routing dei canali resta in Capgo Cloud. Se lo includi, assicurati che il valore corrisponda al canale a cui effettui effettivamente il deploy.

Ora cerca eventuali override locali nell'applicazione code. Una chiamata asetChannel()modifica la cache locale. Non crea un Device Override sul backend. La dashboard potrebbe quindi non mostrare alcun override anche se l'app continua a usare il canale locale.

Azzera quel valore locale quando il dispositivo deve tornare al routing normale. Usa il metodo del plugin che rimuove l'assegnazione del canale del dispositivo, oppure rimuovi il code che imposta il canale e reinstalla l'app per un test pulito.

In sintesi: Una modifica al Cloud Default non può sovrascrivere un'assegnazione locale, dell'app o del dispositivo più specifica.

Passaggio 2: Verifica l'app, il runtime nativo e la compatibilità dell'update

L'obiettivo è dimostrare che l'app installata può accettare il bundle che hai caricato. Un canale corretto non può comunque distribuire un update a un runtime nativo incompatibile.

Inizia dall'app ID. L'app installata sul dispositivo deve usare la stessa identità dell'app del progetto in cui hai caricato il bundle. Un mismatch può sembrare un problema del canale perché il dispositivo controlla l'app Capgo sbagliata.

Poi confronta la versione del runtime nativo con le regole di compatibilità del bundle. I live updates di Capgo possono modificare JavaScript, CSS e asset web. Non possono aggiungere un plugin nativo o cambiare code del progetto nativo dopo il rilascio dell'app. Le modifiche native richiedono comunque una nuova build per gli store.

Pensa al runtime nativo come alla cornice attorno all'code web. Se il nuovo bundle si aspetta un API nativo che l'app installata non ha, Capgo non dovrebbe applicarlo. Fai una build e carica una versione nativa compatibile prima di testare quel bundle.

Controlla la versione e la piattaforma dell'app installata. Testa un bundle Android su Android. Testa un bundle iOS su iOS. Conferma anche che il bundle punti alla versione corretta dell'app se il tuo canale usa i version gates.

Dopo aver modificatodefaultChannel, esegui il comando sync dalla root del progetto:

npx cap sync

Questo passaggio copia la configurazione aggiornata nei progetti nativi. Modificarecapacitor.configsenza sincronizzare lascia l'app nativa con il vecchio setting del canale. Una nuova build da quel progetto nativo non aggiornato riprodurrà sempre lo stesso risultato.

Per un test pulito, builda una nuova app dopo il sync. Non affidarti a un vecchio binario installato sul telefono. Disinstallalo quando devi rimuovere lo stato locale del canale in cache, poi installa la nuova build e ricontrolla il canale.

Il Capgo update behavior documentation spiega quando l'updater controlla la presenza di un bundle. Tieni conto di questa tempistica quando fai i test. Avvia l'app o riportala in foreground, poi attendi che il controllo finisca prima di concludere che l'update sia fallito.

Controlla anche il gate della versione nativa del bundle. Un bundle può trovarsi nel canale corretto ma restare non disponibile perché la versione minima dell'app non corrisponde a quella del dispositivo. Leggi i dettagli del rilascio nella dashboard invece di dare per scontato che l'ultimo upload valga per ogni installazione.

Se l'app supera questi controlli, hai isolato il problema. La domanda successiva è se la release ha raggiunto il canale previsto.

Passo 3: Verifica che il deployment abbia effettivamente raggiunto il canale predefinito

L'obiettivo è confermare che il bundle esista nel canale risolto dal dispositivo. Caricare un bundle in un canale non lo rende disponibile in tutti gli altri.

Apri il canale in Capgo Cloud. Controlla il bundle attivo, la sua versione e lo stato di deployment. Confronta il nome del canale con il valore restituito dall'app. Fai attenzione a piccole differenze comeproductionrispetto aprod. Channel names must match exactly.

Se fai deploy tramite CI/CD, controlla l'output del comando nello stesso job che ha caricato il bundle. Verifica l'app ID e il channel passati a CLI. Una pipeline può completarsi con un upload riuscito pur puntando per errore a un channel di staging.

Controlla poi lo stato del bundle. Una release in bozza o inattiva può essere visibile nella dashboard ma non disponibile per i dispositivi. Se il channel ha un rollout graduale, il dispositivo interessato potrebbe non soddisfare la regola di rollout.

Usa un dispositivo di test noto. Assegnagli un ruolo chiaro. Ad esempio, fissa un dispositivo su un channel di test e lascia un altro sul Cloud Default. Carica una modifica innocua, poi confronta i loro record di check-in. Questo elimina ogni incertezza dal test.

Il motore live OTA di Capgo è progettato per modifiche al web layer. Può distribuire un bundle JavaScript, CSS o un aggiornamento di asset senza attendere una nuova revisione degli store. Questa velocità dipende dal fatto che la release sia attiva nel channel esatto che il dispositivo controlla.

Se hai modificato il Cloud Default pochi istanti fa, tieni presente il timing del dispositivo. Le nuove installazioni usano subito il nuovo percorso. I dispositivi esistenti di solito passano al nuovo quando eseguono il prossimo controllo aggiornamenti. Chiudere e riaprire l'app può aiutare ad attivare quel controllo, ma non può sovrascrivere un channel fissato.

Ora verifica il risultato all'interno dell'app. ChiamagetChannel()dopo l'avvio dell'updater. Logga il channel restituito accanto alla versione dell'app e del bundle. È più utile che controllare solo la dashboard perché mostra ciò che il dispositivo ritiene.

Aspettati un ritardo se l'app verifica solo all'avvio o in foreground. Non testare aprendo una schermata che non avvia mai l'updater. Inserisci il check in un percorso di avvio noto per una build di test breve, poi rimuovi i log extra prima del rilascio.

Se il canale restituito è corretto ma nessun bundle arriva, passa alle regole di compatibilità e rollout. Se il canale restituito è errato, torna al Passo 1 e rimuovi l'assegnazione che ha la precedenza su Cloud Default.

Passo 4: Forza una nuova sincronizzazione e ispeziona i log lato dispositivo

L'obiettivo è distinguere uno stato locale obsoleto da un problema di delivery lato server. Un nuovo check-in fornisce nuove prove.

Prima, assicurati che il dispositivo abbia accesso alla rete. Una sessione app riuscita non dimostra che l'updater possa raggiungere il suo endpoint. Filtri aziendali, regole VPN, portali captive o una sessione scaduta possono bloccare la richiesta di aggiornamento.

Poi, porta l'app in primo piano. Aspetta che il check dell'updater finisca. Se la tua app espone un evento di stato dell'aggiornamento, registra quell'evento con il canale corrente. Evita di registrare solo “update started”. Devi sapere se l'app ha trovato un bundle, scaricato, verificato, installato o rifiutato.

Usa i log dei dispositivi di Capgo per trovare la prima fase fallita. Il primo errore è di solito più utile del messaggio finale “update failed”. Ad esempio, un canale mancante indica un problema di routing. Un rifiuto di compatibilità indica il runtime nativo o il version gate. Un errore di download indica l'accesso alla rete o la richiesta del bundle.

Una reinstallazione è un test utile, ma altera le prove. Reinstallare può cancellare lo stato del canale locale. Usala solo dopo aver catturato il canale corrente e i log, non prima.

Per un controllo ripetibile, registra questi valori in una riga di log:

• App ID e versione nativa dell'app
• Canale risolto dagetChannel()
• Ultimo controllo dell'updater
• Versione del bundle trovata dal server
• Risultato dell'installazione o del rifiuto

Questo piccolo record aiuta quando il dispositivo appartiene a un tester che non riesce a riprodurre il problema su richiesta. Fornisce anche al team CI un segnale chiaro per i test smoke automatizzati.

Usa il repository sorgente ufficiale di Capgo Capacitor Updater quando devi ispezionare il comportamento del plugin API. In particolare, presta attenzione alla differenza tra un cambio di canale locale e un'assegnazione del dispositivo nel dashboard.

Consiglio pro: Cattura il canale risolto prima di cancellarlo. Altrimenti, potresti correggere lo stato e perdere l'indizio che spiegava il fallimento.

Passo 5: Revisiona regole di rollout, gate di versione e rollback automatico

L'obiettivo è verificare se Capgo ha trattenuto o revocato intenzionalmente il bundle. Un aggiornamento mancante è talvolta una regola di sicurezza che funziona come previsto.

Apri le impostazioni del canale e rivedi ogni regola associata al rilascio. Cerca versioni minime dell'app, impostazioni di rollout percentuale, filtri dei dispositivi e condizioni legate al rilascio. Un dispositivo fuori dalla regola rimarrà sul bundle attuale anche se il canale è corretto.

Controlla anche il formato della versione. Capgo usa la semantic versioning per confrontare i rilasci. Un gate di versione che sembra corretto a un occhio umano può comportarsi diversamente se l'app o il bundle usa un formato inaspettato. Mantieni il formato coerente tra build native e rilasci OTA.

Poi rivedi il comportamento del rollback. Un rollback automatico può riportare un dispositivo a un bundle precedente dopo un health check fallito. Il dashboard può mostrare il code attivo più vecchio, mentre il rilascio atteso rimane presente ma non disponibile.

Non eliminare un bundle sospetto prima di rivedere i suoi eventi. L'eliminazione rimuove prove utili. Prima registra la versione del bundle, il canale, lo stato del rollout e la ragione del rollback. Poi decidi se mettere in pausa il rilascio o pubblicare una versione nota come buona.

Usa un canale a fasi per le modifiche a rischio. Invia il bundle prima a un piccolo gruppo di test. Monitora l'adozione e i segnali di errore. Una volta che il rilascio si comporta come previsto, procedi con il rollout. Questo impedisce a un cambiamento problematico del layer web di raggiungere tutti i dispositivi attivi in una volta sola.

Rollback only repairs code that OTA can change. If the failure comes from a missing native plugin or an incompatible native API, you need a new store build. Sending an older JavaScript bundle will not add the native piece that the app lacks.

Quando ispezioni una regola, poni tre domande:

• Il dispositivo soddisfa la condizione di versione dell'app?
• Il dispositivo è all'interno del gruppo di rollout?
• Un health check o un'azione manuale lo ha riportato a un bundle precedente?

Capgo è utile qui perché lo stesso modello di canale può gestire un rilascio graduale, supportare un rollback e mostrare l'attività degli aggiornamenti in un unico workflow. Mantieni il set di regole piccolo. Una policy breve è più facile da auditare rispetto a una pila di eccezioni create durante un incidente.

Se hai bisogno di check basati su API, il documentazione pubblica API di Capgo descrive le risorse per dispositivi, canali e bundle. Usala per confrontare la vista del server con ciò che l'app riporta. Questo confronto può rivelare un filtro del dashboard obsoleto o un'assegnazione del dispositivo creata dall'automazione.

Un rollback è un guardrail, non un sostituto del testing. Tieni sempre disponibile un bundle known-good in ogni canale di produzione.

Passo 6: Usa le Analytics in tempo reale per trovare il punto esatto del fallimento

L'obiettivo è smettere di trattare "non aggiornato" come un unico fallimento. Le analytics possono mostrare se il dispositivo non ha mai effettuato il check-in, non ha trovato un bundle idoneo, ha fallito durante il download o è stato rollback in seguito.

Inizia con il gruppo di dispositivi interessati. Filtra per versione dell'app, piattaforma, channel e versione del bundle. Cerca un pattern. Se fallisce solo un vecchio build nativo, il problema potrebbe essere un gate di compatibilità nativa. Se falliscono tutti i dispositivi in un channel, ispeziona il channel o il deployment.

Confronta l'adozione nel tempo. Una linea piatta dopo il rilascio suggerisce problemi di routing o idoneità. Un aumento seguito da un calo suggerisce errori di installazione o rollback. Un aumento lento potrebbe semplicemente significare che i dispositivi non hanno ancora aperto l'app.

Usa i timestamp con attenzione. L'ora dell'evento nel dashboard può differire dall'ora locale dell'utente. Abbina l'evento di aggiornamento con l'ultimo check-in del dispositivo. Questo aiuta quando un tester dice che l'aggiornamento è fallito prima che l'app avesse effettivamente effettuato il check-in.

Le analytics aiutano anche a testare in sicurezza una modifica del channel. Cambia una variabile alla volta. Mantieni il bundle costante mentre testi il routing. Poi mantieni il routing costante mentre testi un nuovo bundle. Se cambi entrambi, i dati non possono dirti quale modifica ha risolto il problema.

Per un incidente, salva un piccolo set di evidenze:

• Identificativo del dispositivo o etichetta di test interna
• Channel risolto
• Versione dell'app nativa
• Bundle atteso e bundle installato
• Ora dell'ultimo check-in
• Evento di rollback o rifiuto

La vista in tempo reale di Capgo è più utile quando il processo di rilascio invia aggiornamenti tramite CI/CD. Un job di deployment può caricare un bundle, mentre un passo di monitoraggio verifica che i dispositivi di test riportino il canale e il bundle previsti. Questo trasforma un reclamo manuale in un gate di rilascio.

Mantieni i dati analitici collegati ai record di rilascio. Scrivi il riferimento al commit o alla build nelle note di deployment. Quando due bundle hanno etichette di versione simili, il riferimento alla build ti dice quale code si è effettivamente aggiornato.

Se solo i dispositivi esistenti falliscono dopo una modifica a Cloud Default, attendi il loro prossimo check-in prima di cambiare altre impostazioni. Una nuova installazione è un controllo utile. Ti dice se la rotta predefinita funziona per dispositivi che non hanno stato locale precedente.

Passo 7: Prevenire che il Canale Predefinito diventi obsoleto

L'obiettivo è rendere visibile il drift dei canali prima che colpisca gli utenti. Una breve checklist di rilascio può prevenire la maggior parte dei casi ricorrenti.

Scegli un unico modello di routing per ogni ambiente dell'app. Per la produzione, puoi ometteredefaultChannele lasciare che Capgo Cloud controlli il default. Per una build di test, puoi impostare un canale esplicito. La configurazione pericolosa è un mix di vecchi override locali, config native obsolete e un nuovo Cloud Default che nessuno verifica.

Inseriscinpx cap syncnel percorso di build dopo le modifiche alla configurazione. Fai fallire la build se lo step di sync fallisce. Il comando è semplice, ma saltarlo può incorporare il canale di ieri nel binario nativo di oggi.

Aggiungi uno smoke test dopo il deployment. Il dispositivo di test dovrebbe avviare l'app, chiamaregetChannel(), verificare la presenza del bundle atteso e registrare il risultato. La verifica è spesso il passaggio mancante nei workflow OTA. Un semplice upload prova ben poco.

Mantieni il canale locale code dietro una feature flag chiara. Se un helper di test chiamasetChannel(), assicurati che le build di produzione non possano includerlo accidentalmente. Ricorda che la cache locale potrebbe non apparire come un override nel dashboard, quindi l'UI non può intercettare ogni problema.

Usa una checklist di rilascio come questa:

1. Conferma l'app ID e la versione nativa.
2. Scegli il canale di destinazione.
3. Carica il bundle su quel channel.
4. Conferma che il bundle è attivo.
5. Esegui lo smoke test sul dispositivo.
6. Verifica il channel restituito congetChannel().
7. Monitora l'adozione prima di allargare il rollout.

Mantieni attiva la protezione rollback per i rilasci in produzione. Un errore comune è distribuire senza un channel o un piano di rollback chiari: così il team ha meno modi sicuri per fermare un bundle difettoso.

Capgo usa un abbonamento per organizzazione, con 14 giorni di prova gratuita. Considera la prova come un'occasione per testare il flusso di rilascio su build reali dell'app, non solo per guardare la dashboard. Prova un deployment graduale, un test di rollback e un controllo automatizzato del channel.

La sicurezza deve far parte della stessa checklist. Proteggi i token CI/CD. Limita chi può modificare il Cloud Default. Tieni le credenziali di deployment di produzione fuori dagli script locali. Una modifica non autorizzata del channel può sembrare un dispositivo obsoleto finché non controlli l'audit trail.

Per i team che rilasciano spesso, mantieni il processo noioso. Un comando per il deploy. Un dispositivo di test noto. Una regola di channel chiara. Traccia, adotta, fai rollback.

In sintesi: Previeni il routing obsoleto sincronizzando la config, evitando override locali nascosti, testando il channel risolto e mantenendo il rollback pronto.

FAQ

Perché il canale cloud default di Capgo non aggiorna i dispositivi esistenti?

I dispositivi esistenti potrebbero mantenere il vecchio canale fino al prossimo controllo degli aggiornamenti. Anche un canale locale, un override dal dashboard o un'assegnazione forzata possono avere la precedenza sul Cloud Default. Verifica il canale risolto del dispositivo congetChannel(), rimuovi eventuali assegnazioni più forti, quindi porta l'app in primo piano.

Cambiare il Cloud Default di Capgo modifica ogni app installata?

No, cambiare il Cloud Default non riscrive istantaneamente il canale di ogni app installata. I nuovi dispositivi possono usare subito il nuovo default. Le installazioni esistenti devono fare il check-in prima di poter cambiare, e non cambieranno comunque se vale una regola di canale più forte o un override locale.

Cosa fa npx cap sync per un cambio di canale Capgo?

npx cap synccopia la configurazione Capacitor aggiornata nei progetti nativi. Se modifichidefaultChannelma salti il sync, il prossimo Native Build potrebbe ancora contenere l'impostazione del vecchio canale. Esegui il comando dalla root del progetto, poi fai la build e installa un nuovo binario di test.

setChannel crea un override del dispositivo in Capgo?

No,setChannel()modifica il canale memorizzato localmente dall'app. Non crea un Device Override sul backend, quindi il dashboard di Capgo potrebbe non mostrare il dispositivo come sovrascritto. Rimuovi l'assegnazione locale quando il dispositivo deve tornare al routing di default, quindi verifica il risultato congetChannel().

Può Capgo aggiornare code nativi tramite un bundle OTA?

No, gli aggiornamenti OTA di Capgo si applicano al code del web layer, come JavaScript, CSS e asset. Un plugin nativo, un permesso o una modifica API nativa richiedono una nuova build per gli store. Se il bundle richiede code nativi che l'app installata non ha, l'aggiornamento potrebbe essere rifiutato anche se il canale è corretto.

Conclusione

Parti dal canale risolto, non dal default della dashboard. Controlla le assegnazioni, eseguinpx cap sync, verifica il bundle rispetto al runtime nativo e ispeziona i log del dispositivo prima di cambiare le regole di rollout. Poi aggiungi un piccolo test post-deploy in Capgo che chiamagetChannel()e conferma il bundle atteso.