Canali

Un canale Live Update punta a una specifica build del bundle JS della tua app, condivisa con tutti i dispositivi configurati per ricevere aggiornamenti da quel canale. Quando installi il SDK Capgo Live Updates nella tua app, ogni binario nativo configurato per quel canale verificherà la disponibilità di aggiornamenti all'avvio dell'app. Puoi modificare la build a cui punta il canale in qualsiasi momento e, se necessario, tornare a build precedenti.

Risposta breve: per staging e produzione in un'app Capacitor, crea un staging e a una production canale in Capgo, carica ogni bundle su staging prima, testalo, poi promuovi lo stesso bundle su production.

Canali in azione

Pensa a un canale come a un puntatore con nome a un aggiornamento: production può servire la tua app rilasciata mentre beta serve i tester. Questi tre brevi video mostrano come un dispositivo finisce su un canale. Ognuno ha una musica di sottofondo opzionale e nessuna narrazione; le spiegazioni qui sotto coprono gli stessi passaggi.

1. Usa il canale di default

Un dispositivo che esegue v1.1.0 chiede a Capgo un aggiornamento. Senza un'assegnazione del dispositivo o un canale configurato nell'app, Capgo controlla il predefinito nel cloud, production, e ne restituisce il v1.2.0 bundle. I dev e staging canali mantengono i propri bundle senza influenzare questo dispositivo.

Scarica il video del canale predefinito (MP4).

Imposta il tuo default di produzione in Informazioni sull'app. Le normali build di produzione possono lasciare defaultChannel non impostato, così puoi gestire il routing da Capgo.

2. Lascia che un dispositivo scelga un canale

Questa guida utilizza setChannel() e unsetChannel() da @capgo/capacitor-updater su Android e iOS; questi metodi non sono supportati nel browser. Utilizza il comportamento di local-channel disponibile in updater 5.34.0+, 6.34.0+, 7.34.0+, o 8.0.0+ per la major version del tuo plugin. Le versioni precedenti scrivevano un override del backend; quelle assegnazioni seguono le console e API sovrascrivono le regole di retention.

Un tester abilita gli aggiornamenti beta all'interno della tua app. La tua app chiama CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true }). Capgo verifica che beta consenta l'auto-assegnazione del dispositivo, quindi il plugin salva la scelta localmente per i futuri controlli di aggiornamento. Gli altri dispositivi mantengono il loro routing esistente.

Scarica il video sull'auto-assegnazione dei dispositivi (MP4).

Abilita Consenti ai dispositivi di dissociarsi/associarsi autonomamente sul canale di destinazione prima dell'uso setChannel(). Questa scelta locale non crea un override nella console. Su Android e iOS con updater 8.51.0 o versioni successive, persistDefaultChannelOnReinstall ha come default true, quindi la scelta persiste dopo la reinstallazione solo se il sistema operativo ripristina i dati dell'app e persistDefaultChannelOnReinstall rimane true. Chiama unsetChannel() per cancellare la scelta locale; le sovrascritture di console e API seguiranno comunque la precedenza indicata sotto.

3. Assegna un dispositivo dalla console

Nella console Capgo, apri App, seleziona la tua app, apri Dispositivi, e seleziona un dispositivo. Cambia il suo Override del canale a dev. Capgo ora instrada quel dispositivo verso dev, mentre il default cloud dell'app resta production.

Scarica il video del device override in console (MP4).

Usa un override per test mirati o supporto. Ha la priorità sul canale locale del dispositivo e sul predefinito cloud, a meno che non sia presente una mappatura forzata. Override da Console e API scade 90 giorni dopo l'ultima scrittura dell'override.

Pronto a provarlo? Crea un canale nella console, poi caricare un bundle per poterlo servire.

I canali non garantiscono la riservatezza

I canali controllano l'idoneità agli aggiornamenti, non la segretezza dei bundle. Anche se un canale è privato o l'auto-assegnazione è disabilitata, qualsiasi bundle non cifrato caricato su Capgo deve essere considerato un asset pubblico consegnato ai client. La crittografia protegge il percorso di distribuzione e l'autenticità degli aggiornamenti, ma i bundle distribuiti possono comunque essere decompilati dall'app distribuita con sufficiente sforzo, poiché la chiave pubblica fa parte del client. Vedi la crittografia Live Update per i dettagli.

Come un dispositivo sceglie un Channel (precedenza)

Quando un dispositivo verifica la presenza di aggiornamenti, Capgo decide quale canale utilizzare in questo ordine rigoroso (priorità più alta per prima):

1. Mappatura forzata del dispositivo (Dashboard) – Fissa manualmente un ID dispositivo specifico a un canale. Da usare per debug urgenti o test controllati con un singolo utente reale. Questa regola ha sempre la precedenza. Capgo rimuove la mappatura 90 giorni dopo l'ultima scrittura di override. Vedi Gli override di Console e API scadono dopo 90 giorni.
2. Override cloud (per-dispositivo) tramite Dashboard o API – Creato quando si modifica il canale del dispositivo nel dashboard o tramite API. Utile per utenti QA che passano tra canali feature / PR o per riprodurre un problema segnalato. La reinstallazione del binario non lo elimina; la cancellazione dell'override del dispositivo sì. Si applica la stessa retention di 90 giorni.
3. Plugin setChannel() canale locale – Creato quando l'app chiama setChannel() e il backend valida che il canale di destinazione consenta l'auto-assegnazione. Il canale selezionato viene salvato localmente su quel dispositivo, ha effetto immediato e non viene mostrato nell'UI di Device Override.

Cambio istantaneo del canale con setChannel()

A partire dalle versioni del plugin 5.34.0, 6.34.0, 7.34.0 o 8.0.0 (in base alla tua major version), setChannel() funziona diversamente: contatta il backend per validare che il canale sia consentito (verificando se l'auto-assegnazione è attiva per quel canale), quindi salva il canale localmente sul dispositivo come defaultChannel. Ciò significa che il nuovo canale diventa effettivo istantaneamente al prossimo controllo degli update, senza attendere la replica.

In precedenza, setChannel() salvava l'override del canale nel database backend (come le modifiche a Dashboard o API), e i dispositivi dovevano attendere la replicazione dei dati (fino a 2 minuti) prima che il nuovo canale venisse riconosciuto. Il nuovo comportamento legge solo dal backend (per la validazione) e salva localmente, rendendo il cambio di canale istantaneo.

Perché setChannel() è solo locale, non hai crea una voce Device Override nel dashboard Capgo. L'interfaccia Device Override mostra solo le override create dal dashboard o dalla API pubblica.

Nota: Anche se un canale viene disabilitato dopo essere stato impostato localmente, il backend continua a validare il canale durante i controlli di aggiornamento, garantendo così la sicurezza.

Importante: Quando le modifiche al canale vengono effettuate tramite il Dashboard o API, c'è comunque un ritardo di replica di fino a 2 minuti prima che tutti i server edge riflettano la modifica. Per un cambio canale immediato, usa setChannel() dalla tua app code: valida con il backend, quindi imposta il canale localmente per un effetto immediato.

4. Configurazione Capacitor defaultChannel (default build di test) – Se presente in capacitor.config.* e non esiste un canale force/override/locale, l'app si avvia su questo canale (es. beta, qa, pr-123). Pensato per TestFlight / build interne, in modo che i tester atterrino automaticamente su un canale pre-release. Le build di produzione in genere lasciano questo campo non impostato.
5. Canale predefinito di Cloud (percorso principale ~99% degli utenti) – Se imposti un canale predefinito nel dashboard, tutti gli utenti finali standard (senza force, senza override Dashboard/API, senza canale locale del plugin, senza defaultChannel nella config) si agganciano qui. Modificalo per distribuire o fare rollback istantaneamente, senza un nuovo binary. Se hai predefiniti specifici per piattaforma (ad esempio, uno solo per iOS, uno solo per Android, uno solo per Electron), ogni dispositivo atterra sul predefinito corrispondente alla sua piattaforma. Lasciare il predefinito cloud non impostato è consentito; in tal caso, il dispositivo deve corrispondere ai passaggi 1–4 per ricevere gli aggiornamenti.

Buona pratica:

• Tratta 1–4 come livelli di eccezione/test; quando imposti un default cloud, gli utenti reali dovrebbero confluire lì. Se scegli di non impostarne uno, decidi consapevolmente come gli utenti si collegano (di solito tramite defaultChannel nella config o negli override per dispositivo).
• Configura solo defaultChannel nei binari che distribuisci esplicitamente ai tester. Non impostarlo mantiene la logica di produzione centralizzata nel dashboard.
• Usa setChannel() con parsimonia in produzione—principalmente per QA o diagnostica mirata.

Se un canale è disabilitato per la piattaforma (toggle iOS/Android/Electron) quando altrimenti verrebbe scelto, il processo di selezione lo salta e passa al successivo nella lista.

Riassunto: Force > Dashboard/API Override > Plugin setChannel() canale locale > Config defaultChannel > Default di Cloudflare.

Gli override di Console e API scadono dopo 90 giorni

I mapping forzati e gli override dei canali Dashboard o Public API sono salvati come assegnazioni per singolo dispositivo in Capgo. Un job di pulizia elimina tali assegnazioni 90 giorni dopo l'ultima scrittura dell'override. Effettuare il check per un aggiornamento non resetta il timer. Solo riscrivendo l'override (o eliminandolo manualmente) si aggiorna il timestamp.

Questo non equivale a ritenzione dell'inventario dei dispositivi. Inventory rimuove i dispositivi che non si sono connessi a Capgo da 90 giorni. Override cleanup rimuove la mappatura anche se il dispositivo è ancora attivo.

Per un'assegnazione che non viene rimossa da questa pulizia:

• Imposta defaultChannel nella capacitor.config.* (sopravvive alla reinstallazione; richiede un nuovo binario nativo per modificarla in seguito).
• Chiama setChannel() dall'app. A partire dalle versioni 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 del plugin, tale assegnazione è locale e non viene rimossa da questa pulizia. Su Android e iOS con updater 8.51.0 o successivo, persistDefaultChannelOnReinstall ha come default true, quindi l'assegnazione può sopravvivere al reinstall solo se il sistema operativo ripristina i dati dell'app e persistDefaultChannelOnReinstall rimane true. Usa unsetChannel() per rimuoverla esplicitamente.

Il canale Dispositivi La tab del canale e la UI Override del dispositivo mostrano solo gli assignment console e Public API. Non elencano tutti i dispositivi del canale e non elencano gli setChannel() assignment locali.

Avviso di retention degli Override nella tab Devices del canale.

Comportamento predefinito del canale

Impostare un default cloud è opzionale, ma di solito funge da percorso catch-all per i nuovi dispositivi. Senza di esso, solo i dispositivi che corrispondono a mapping forzati, override o a una defaultChannel config di Capacitor riceveranno aggiornamenti. Quando scegli di impostare i default, tieni a mente questi pattern:

• Default singolo (il più comune) – Se un canale ha iOS, Android ed Electron abilitati, diventa l'unico default; qualsiasi dispositivo senza override si collegherà qui.
• Valori predefiniti specifici per piattaforma – Se dividi i canali per piattaforma (ad esempio, ios-production con solo iOS abilitato, android-production con solo Android abilitato, e electron-production con solo Electron abilitato), contrassegna ciascuno come predefinito per la sua piattaforma. I dispositivi iOS vanno al predefinito iOS, i dispositivi Android al predefinito Android, e le app Electron al predefinito Electron.

Ricorda che il default cloud e defaultChannel nella capacitor.config.* occupano entrambi lo stesso livello di decisione. Se imposti un default cloud, non devi duplicare il valore nella tua configurazione Capacitor: lascia defaultChannel vuoto per le build di produzione. Riserva defaultChannel per i binari che spedisci intenzionalmente a tester o QA quando vuoi che partano su un canale non di produzione, anche se il default cloud è diverso.

Puoi modificare i default in qualsiasi momento nel dashboard. Apri il canale, poi Gestisci nelle impostazioni dell'app, che ti porta a Informazioni sull'app. Il default non è più un toggle sulla pagina del canale. Quando cambi un default, i nuovi dispositivi rispettano immediatamente il nuovo routing e i dispositivi esistenti seguono le normali regole di precedenza la prossima volta che fanno check-in.

Configurazione di un Channel

Durante l'onboarding crei il primo channel (la maggior parte dei team lo chiama “Production”), ma nulla è bloccato: puoi rinominare o eliminare qualsiasi channel in qualsiasi momento. Per aggiungere altri channel in seguito:

1. Vai alla sezione “Channels” del dashboard Capgo
2. Fai clic sul pulsante “New Channel”
3. Inserisci un nome per il channel e fai clic su “Create”

I nomi dei channel possono essere quelli che preferisci. Una strategia comune è allineare i channel alle fasi di sviluppo, ad esempio:

• Development - per testare le Live Update su dispositivi locali o emulatori
• QA - per il team QA che verifica gli aggiornamenti prima del rilascio su larga scala
• Staging - per i test finali in un ambiente simile alla produzione
• Production - per la versione della tua app che gli utenti finali ricevono dagli app store

Configurare il Channel nella tua app

Con i channel creati, devi configurare la tua app per ascoltare il channel appropriato. In questo esempio, useremo il Development channel.

Apri il tuo capacitor.config.ts (o capacitor.config.json) file. Nella sezione plugins , imposta facoltativamente defaultChannel per build di test (interno / QA). Per i build di produzione, è preferibile ometterlo in modo che i dispositivi usino il Cloud Default, a meno che non venga esplicitamente sovrascritto.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Successivamente, compila la tua web app ed esegui npx cap sync per copiare il file di configurazione aggiornato nei tuoi progetti iOS, Android ed Electron. Se salti questo passaggio di sincronizzazione, i tuoi progetti nativi continueranno a utilizzare il channel per cui erano stati configurati in precedenza.

Attenzione

Ordine di selezione del channel: Force > Override dispositivo Dashboard/API > Plugin setChannel() canale locale > Config defaultChannel > Default di Cloudflare.

Usa defaultChannel solo nei build di test/interni; omettilo in produzione affinché gli utenti seguano il Cloud Default (se impostato) invece di duplicare il routing nella configurazione nativa.

Puoi comunque forzare (pin) un dispositivo o applicare un override in seguito: questi hanno la precedenza immediata sul valore della configurazione.

I nomi dei channel sono case sensitive.

Opzioni e strategie dei Channel

I Channel hanno diverse opzioni che controllano chi può ricevere gli aggiornamenti e come vengono distribuiti. Le più importanti sono di seguito. Puoi configurarle dall'app web, dal CLI o dalla API pubblica.

• Canale predefinito: Facoltativamente, indica il canale o i canali specifici per piattaforma a cui si collegano i nuovi dispositivi. Nella console si trova in App Information (Gestisci nelle impostazioni dell'app dalla pagina del canale). Consulta “Comportamento del canale predefinito” per gli scenari di routing.
• Filtri piattaforma: Abilita o disabilita la consegna a iOS, Android, o Electron dispositivi per canale.
• Disabilita auto downgrade sotto native: Impedisce l'invio di un aggiornamento quando la versione dell'app nativa del dispositivo è più recente del bundle del canale (ad esempio, dispositivo su 1.2.3 mentre il canale ha 1.2.2).
• Consenti build di sviluppo: Consente aggiornamenti alle build di sviluppo (utile per i test). CLI: --dev / --no-dev.
• Consenti build di produzione: consenti gli aggiornamenti alle build di produzione (store). Lascia attivo per i canali che servono utenti reali. CLI: --prod / --no-prod.
• Consenti emulatori: consenti gli aggiornamenti su emulatori/simulatori (utile per i test). CLI: --emulator / --no-emulator.
• Consenti dispositivi fisici: consenti gli aggiornamenti su telefoni e tablet reali. Lascia attivo per i canali di produzione. CLI: --device / --no-device.
• Consenti l'auto-assegnazione del dispositivo: permette all'app di passare a questo canale a runtime usando setChannel. Se disabilitato, setChannel fallirà per questo canale. CLI: --self-assign / --no-self-assign.
• Formato download: scegli se i dispositivi scaricano uno zip completo, solo i file delta modificati, o il meglio di entrambi (all, zip, delta, zip_from_builtin, delta_from_builtin). Vedi Formato download per il menu a tendina della console e quando ogni modalità è utile.

Rollout progressivi

Un canale può mantenere un bundle stabile mentre espone gradualmente un target di rollout separato a una coorte di dispositivi sticky. Puoi mettere in pausa, riprendere, promuovere, fare rollback e configurare una risposta automatica al fallimento senza cambiare il canale per tutti. Vedi Rollout progressivi per il modello di delivery, il workflow del dashboard, i campi API e i comandi CLI.

Disabilitare le strategie di Auto Update

Usa questa opzione per limitare i tipi di aggiornamenti che il canale distribuirà automaticamente. Opzioni:

• major: Blocca un bundle di destinazione la cui versione major è superiore alla baseline nativa del dispositivo (version_build). Esempio: 1.2.3 -> 2.0.0 viene bloccato; 1.2.3 -> 1.9.0 è consentito.
• minor: Blocca un bundle di destinazione la cui versione major o minor differisce da version_build. Esempio: 1.2.3 -> 1.3.0 viene bloccato; 1.2.3 -> 1.2.4 è consentito.
• patch: Modalità più restrittiva. Blocca qualsiasi modifica ai numeri major, minor o patch. Sono consentiti solo i cambiamenti di suffisso mentre MAJOR.MINOR.PATCH rimane identico. Esempi: 1.0.0-beta.1 -> 1.0.0-beta.2 è consentito, 1.0.0+build.1 -> 1.0.0+build.2 è consentito, 1.0.0 -> 1.0.1 è bloccato.
• metadata: richiede un metadata di versione minima di aggiornamento su ogni bundle. Configura tramite CLI usando --min-update-version oppure --auto-min-update-version. Se assente, il canale viene segnalato come non configurato e gli aggiornamenti verranno rifiutati finché non viene impostato.
• none: consente tutti gli aggiornamenti in base a compatibilità semver.

Queste strategie confrontano il bundle di destinazione del canale con la baseline nativa inviata come version_build, non con il bundle attualmente scaricato inviato come version_name.

Scopri dettagli ed esempi in Disable updates strategy su /docs/cli/commands/#disable-updates-strategy.

Esempio (CLI). Il canale deve già esistere (channel set does not create it):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

Usare setChannel() dalla tua app

Il @capgo/capacitor-updater metodo setChannel() consente alla tua app Android o iOS di cambiare canale in modo programmatico a runtime. È particolarmente utile per:

• Menu QA/debug in cui i tester possono cambiare canale
• Flussi di opt-in per i programmi beta
• Implementazioni di feature flag
• Scenari di A/B testing

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Come funziona setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Quando setChannel() viene chiamato:

1. Validazione backend (sola lettura): Viene inviata una richiesta al backend di Capgo per verificare che il canale sia consentito (controllo dei permessi di self-assignment)
2. Aggiornamento dello storage locale: Se la convalida va a buon fine, il canale viene salvato nella memoria locale del dispositivo come defaultChannel
3. Effetto immediato: Il prossimo controllo degli aggiornamenti utilizza immediatamente il nuovo canale (nessuna attesa per la replicazione)

Perché è importante: Nelle versioni precedenti, setChannel() salvava l'override del canale nel database backend (come le modifiche da Dashboard o API). I dispositivi dovevano attendere la replicazione backend (fino a 2 minuti) prima che la modifica del canale avesse effetto. Ora, setChannel() legge solo dal backend (per la convalida) e salva localmente, rendendo il cambio canale istantaneo.

Visibilità nel dashboard: Un canale impostato tramite il plugin non fa apparire il dispositivo come Device Override nell'interfaccia Capgo. Vengono elencati solo gli assegnamenti di canale creati dal dashboard o dalla API pubblica. Usa il dashboard o API quando serve un override visibile agli amministratori.

Nota sulla sicurezza: Anche se i permessi di un canale cambiano dopo l'impostazione locale (es. l'auto-assegnazione viene disabilitata), il backend continuerà a validare il canale durante i controlli di aggiornamento, garantendo la sicurezza.

Confronto dei metodi per cambiare canale:

Metodo	Tempo di effetto	Dove viene salvato	Visualizzato nell'interfaccia Device Override	Scade	Caso d'uso
setChannel() dal plugin	Istantaneo	Solo dispositivo (locale)	No	Nessuna scadenza automatica; elimina con unsetChannel() (la reinstallazione potrebbe conservarlo)	Cambio canale in-app avviato dall'utente
Override dispositivo dalla dashboard	Fino a 2 min	Database backend	Sì	90 giorni dall'ultima scrittura di override	Modifiche admin per dispositivi specifici
Assegnazione canale API	Fino a 2 min	Database backend	Sì	90 giorni dall'ultima scrittura di override	Integrazioni backend automatizzate

Per la migliore UX quando crei interfacce per il cambio di canale, usa sempre il setChannel() metodo.

Versioni minime per il cambio canale solo locale: 5.34.0, 6.34.0, 7.34.0, o 8.0.0 (in base alla tua major version). Ogni numero di minor version corrisponde allo stesso set di feature in tutte le major version (es. X.34.0 include le stesse feature sia che X sia 5, 6, 7 o 8). Vedi installazione del plugin per i tag delle versioni.

Assegnare un Bundle a un Channel

Per distribuire un live update, devi fare l'upload di un nuovo build del bundle JS e assegnarlo a un channel. Puoi farlo in un unico passaggio con Capgo CLI:

npx @capgo/cli@latest bundle upload --channel=Development

Questo comando carica gli asset web compilati e imposta il nuovo bundle come build attiva per il Development channel. Tutte le app configurate per monitorare quel channel riceveranno l'aggiornamento la prossima volta che verificheranno la presenza di aggiornamenti.

Puoi anche assegnare le build ai canali dalla sezione “Bundles” della dashboard Capgo. Clicca sull'icona del menu accanto a una build e seleziona “Assign to Channel” per scegliere il canale di quella build.

Versioning dei bundle e canali

È importante notare che i bundle in Capgo sono globali per la tua app, non specifici per singoli canali. Lo stesso bundle può essere assegnato a più canali.

Quando versionate i bundle, consigliamo di usare il semantic versioning con il Semver Tester di Capgo e identificatori pre-release per build specifiche del canale. Ad esempio, una release beta potrebbe essere versionata come 1.2.3-beta.1.

In CI, se la versione locale è già stata caricata, usa npx @capgo/cli@latest bundle upload --auto-bump (opzionalmente major, minor, patch/fix, metadata, o ai) in modo che CLI incrementi dal bundle collegato al canale finché non trova un nome libero. Con ai, Workers AI deduce il livello dal delta manifest tra locale e precedente (con fallback su patch in assenza di una versione precedente di Capgo). Non puoi combinarlo con --bundle. Consulta Integrazione CI/CD e il documentazione di CLI.

Questo approccio offre diversi vantaggi:

• Comunica chiaramente la relazione tra i build. 1.2.3-beta.1 è ovviamente una pre-release di 1.2.3.
• Permette di riutilizzare i numeri di versione tra i canali, riducendo la confusione.
• Consente percorsi di rollback chiari. Se devi fare rollback da 1.2.3, sai che 1.2.2 è la release stabile precedente.

Ecco un esempio di come allineare le versioni dei bundle a una configurazione tipica dei canali:

• Development canale: 1.2.3-dev.1, 1.2.3-dev.2, ecc.
• QA canale: 1.2.3-qa.1, 1.2.3-qa.2, ecc.
• Staging canale: 1.2.3-rc.1, 1.2.3-rc.2, ecc.
• Production canale: 1.2.3, 1.2.4, ecc.

Usare semver con identificatori pre-release è un approccio consigliato, ma non strettamente obbligatorio. La chiave è trovare uno schema di versioning che comunichi chiaramente le relazioni tra le tue build e sia in linea con il processo di sviluppo del tuo team.

Rollback di un Live Update

Se distribuisci un live update che introduce un bug o che comunque va annullato, puoi facilmente tornare a una build precedente. Dalla sezione “Channels” del dashboard:

1. Fai clic sul nome del channel su cui vuoi fare il rollback
2. Trova la build a cui vuoi tornare e clicca sull'icona della corona
3. Conferma l'azione

La build selezionata diventerà immediatamente di nuovo la build attiva per quel canale. Le app riceveranno la versione ripristinata la prossima volta che cercano un aggiornamento.

Automazione dei deployment

Per workflow più avanzati, puoi automatizzare i tuoi deployment live update come parte della tua pipeline CI/CD. Integrando Capgo nel tuo processo di build, puoi caricare automaticamente nuovi bundle e assegnarli ai canali ogni volta che fai push su determinati branch o crei nuove release.

Dai un'occhiata alla Integrazione CI/CD documentazione per saperne di più sull'automazione dei live updates Capgo.

PR preview con privilegi minimi

Usa un Anteprima App API key quando la CI richiede un canale temporaneo per pull request ma non deve gestire i canali main/default esistenti. La chiave rimane legata all'organizzazione e all'app selezionata; semplicemente non ha un ruolo a livello di organizzazione. Ogni canale di anteprima non pubblico che crea riceve i propri permessi di ciclo di vita automatici e specifici per il canale.

1. Fai creare a un amministratore dell'organizzazione una chiave API sicura limitata all'app di anteprima e seleziona Anteprima App. Consulta Chiavi API.
2. Usa un canale unico e non pubblico come pr-123. Non passare --default, --self-assign, opzioni di rollout o --delete-linked-bundle-on-upload.
3. Carica e promuovi il bundle della PR con un solo comando, poi elimina il canale e il bundle di proprietà quando la PR viene chiusa:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel crea un canale mancante, carica il bundle e lo promuove in un unico flusso. La pulizia è atomica e controllata tramite ownership: la chiave può eliminare solo un canale che ha creato e il relativo bundle non condiviso. Non può modificare, promuovere o eliminare un canale principale/default esistente, il canale di un'altra chiave di preview o il bundle di un'altra chiave.

Se i revisori necessitano di un code QR o di un URL di anteprima, un amministratore deve abilitare le anteprime per l'app:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Una chiave App Preview non può abilitare le anteprime da sola perché non ha il permesso app-settings. Nelle GitHub Actions, esegui i job di anteprima con segreti su pull_request, non pull_request_target, e limitali alle PR dello stesso repository con github.event.pull_request.head.repo.full_name == github.repository.

Deployment su un dispositivo

Ora che hai capito come funzionano i canali, sei pronto per distribuire live update sui dispositivi reali. Il processo di base è:

1. Installa Capgo SDK nella tua app
2. Configura l'app per ascoltare il canale desiderato
3. Carica una build e assegnala a quel canale
4. Avvia l'app e attendi l'aggiornamento!

Per una guida più dettagliata, consulta la Deploy di Live Updates guida. Buon aggiornamento!

Uso avanzato dei canali: segmentazione utenti

I canali non servono solo per le fasi di sviluppo. Sono uno strumento potente per la segmentazione degli utenti, che abilita funzionalità come:

• Feature flags per diversi livelli utente
• Test A/B
• Rollout graduale delle funzionalità
• Programmi di beta testing

Scopri come implementare questi casi d'uso avanzati nella nostra guida: Come segmentare gli utenti per piano e canali per feature flag e test A/B.

Continua da Channels

Se stai usando Canali per pianificare il routing dei canali e il rollout graduale, connettilo a Canali per i dettagli di implementazione nei Channels, Canali per i dettagli di implementazione nei Channels, Soluzione Beta Testing per il workflow del prodotto nella Beta Testing Solution, Soluzione Version Targeting per il workflow del prodotto nella Version Targeting Solution, e Capgo Environment Best Practices: Staging con un unico Mobile App ID per il contesto pratico in Capgo Environment Best Practices: Staging con un unico Mobile App ID.