Canali

Un canale Live Update punta a una specifica build del bundle JS della tua app, che verrà condivisa con tutti i dispositivi configurati per ascoltare quel canale in cerca di aggiornamenti. Quando installa il SDK di Capgo Live Updates nell'app, ogni binario nativo configurato su quel canale cercherà aggiornamenti all'avvio. Puoi cambiare il build a cui punta un canale in qualsiasi momento e, se necessario, effettuare il rollback a versioni precedenti.

Canali in azione

Pensa a un canale come a un puntatore nominativo verso un update: production può servire la tua app rilasciata mentre beta serve i tester. Questi tre brevi video mostrano come un dispositivo finisca su un canale. Ognuno ha musica di sottofondo opzionale e senza parlato; le spiegazioni qui sotto coprono gli stessi passaggi.

1. Usa il canale di default

Un dispositivo che esegue v1.1.0 richiede un update a Capgo. Senza un canale assegnato al dispositivo o configurato nell'app, Capgo controlla il default nel cloud, production, e restituisce il suo 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 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 lato backend; queste assegnazioni seguono le regole di ritenzione dell'override della console e di API.

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 permette l'auto-assegnazione del dispositivo, quindi il plugin salva la scelta localmente per i futuri controlli di aggiornamento. Gli altri dispositivi mantengono il 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 precedenza sul canale locale del dispositivo e sul default cloud, salvo la presenza di un mapping forzato. Override della Console e di API scadono 90 giorni dopo l'ultimo override scritto.

Pronto a provarlo? Crea un canale nella console, poi fai l'upload di un bundle per poterlo servire.

I canali non garantiscono la riservatezza

I canali controllano l'idoneità degli update, non la segretezza del bundle. Anche se un canale è privato o l'auto-assegnazione è disabilitata, qualsiasi bundle non criptato caricato su Capgo deve essere considerato un asset pubblico consegnato ai client. La crittografia protegge il percorso di consegna e l'autenticità degli update, ma i bundle distribuiti possono comunque essere sottoposti a reverse engineering dall'app con sufficiente impegno, 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 cerca un aggiornamento, Capgo decide quale canale utilizzare seguendo questo ordine rigoroso (dal più prioritario):

1. Mappatura forzata del dispositivo (Dashboard) – Assegna manualmente un ID dispositivo specifico a un canale. Utile per debugging urgente o test controllati su un singolo utente reale. Questa opzione ha sempre la precedenza. Capgo rimuove la mappatura 90 giorni dopo l'ultima modifica. Vedi Gli override di Console e API scadono dopo 90 giorni.
2. Override Cloud (per dispositivo) via Dashboard o API – Viene creato quando cambi il canale del dispositivo nella dashboard o tramite API. Ideale per utenti QA che passano tra canali feature/PR o per riprodurre bug. La reinstallazione del binario non lo rimuove; bisogna eliminare l'override del dispositivo. Si applica la stessa retention di 90 giorni.
3. Plugin setChannel() canale locale – Viene creato quando l'app chiama setChannel() e il backend valida che il canale target permetta l'auto-assegnazione. Il canale selezionato viene salvato localmente sul dispositivo, ha effetto immediato e non appare nella UI 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() l'override del canale veniva salvato nel database del backend (come le modifiche su Dashboard o API) e i dispositivi dovevano attendere la replica dei dati (fino a 2 minuti) prima di riconoscere il nuovo canale. 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 nella dashboard di Capgo. L'interfaccia Device Override mostra solo gli override creati tramite dashboard o il API pubblico.

Nota: Anche se un canale viene disabilitato dopo essere stato impostato localmente, il backend ne verificherà comunque la validità durante i controlli di aggiornamento, garantendo la sicurezza.

Importante: Quando le modifiche ai canali vengono effettuate tramite Dashboard o API, è presente ancora un ritardo di replica fino a 2 minuti prima che tutti gli edge server riflettano il cambiamento. Per un cambio di canale istantaneo, usa setChannel() dal code della tua app: valida con il backend e poi imposta il canale localmente per un effetto immediato.

4. Configurazione Capacitor defaultChannel (build di test predefinita) – Se presente in capacitor.config.* e non esiste un canale force/override/local, l'app si avvia su questo canale (es. beta, qa, pr-123). Pensato per TestFlight / build interne, così i tester atterrano automaticamente su un canale pre-release. Le build di produzione solitamente lo lasciano non impostato.
5. Canale Cloud Default (percorso primario ~99% degli utenti) – Se imposti un canale di default nella dashboard, tutti gli utenti finali (senza force, senza override Dashboard/API, senza canale locale del plugin o config defaultChannel) si collegano qui. Cambialo per rilasciare o fare il rollback istantaneamente, senza nuovi binari. Se hai default specifici per piattaforma (es. uno solo per iOS, uno per Android, uno per Electron), ogni dispositivo atterrerà sul default corrispondente alla sua piattaforma. È possibile lasciare il cloud default non impostato; in tal caso, il dispositivo deve corrispondere ai passaggi 1–4 per ricevere gli update.

Best practice:

• Considera i passaggi 1–4 come livelli di eccezione / testing; quando imposti un cloud default, gli utenti reali dovrebbero confluirvi. Se scegli di non impostarne uno, decidi con cura come gli utenti si collegano (tipicamente tramite defaultChannel in config or per-device overrides).
• Configura solo defaultChannel solo nelle build che spedisci esplicitamente ai tester. Lasciarlo non impostato mantiene la logica di produzione centralizzata nella 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 dispositiviL'inventario rimuove i dispositivi che non si connettono a Capgo da 90 giorni. L'override di cleanup rimuove il mapping anche se il dispositivo è ancora attivo.

Per un'assegnazione che non viene rimossa da questo cleanup:

• Imposta defaultChannel nella capacitor.config.* (sopravvive alla reinstallazione; richiede un nuovo native binary per essere modificata in seguito).
• Chiama setChannel() dall'app. Con il plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 e successivi, l'assegnazione è locale e non viene rimossa da questo cleanup. Su Android e iOS con updater 8.51.0 e successivi, persistDefaultChannelOnReinstall ha come default true, quindi l'assegnazione può sopravvivere alla reinstallazione solo quando 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.
• Default 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), imposta ciascuno come default per la sua piattaforma. I dispositivi iOS useranno il default iOS, quelli Android il default Android e le app Electron il default Electron.

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

Puoi cambiare i default in qualsiasi momento nella dashboard. Apri il canale, poi Gestisci nelle impostazioni dell'app, che ti porta a Informazioni sull'app. Il default non è più un toggle nella pagina del canale. Quando cambi il default, i nuovi dispositivi seguono subito il nuovo routing e i dispositivi esistenti seguono le normali regole di precedenza al prossimo check-in.

Configurazione di un Channel

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

1. Vai alla sezione “Channels” della dashboard di Capgo
2. Clicca sul pulsante “New Channel”
3. Inserisci un nome per il canale e clicca su “Create”

I nomi dei canali possono essere scelti liberamente. Una strategia comune è associare i canali alle fasi di sviluppo, come ad esempio:

• Development - per testare le Live Update su dispositivi locali o emulatori
• QA - per permettere al team QA di verificare gli update prima del rilascio
• Staging - per i test finali in un ambiente simile alla produzione
• Production - per la versione dell'app che gli utenti finali scaricano dagli app store

Configurare il Channel nella tua app

Una volta creati i canali, devi configurare la tua app per ascoltare il canale corretto. In questo esempio useremo il Development canale.

Apri il tuo file capacitor.config.ts (o capacitor.config.json) file. Sotto la plugins sezione, puoi impostare opzionalmente defaultChannel per build di test (interno / QA). Per i build di produzione, è meglio ometterlo così i dispositivi useranno il Cloud Default, a meno di override espliciti.

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, builda la tua web app ed esegui npx cap sync per copiare il file di config aggiornato nei tuoi progetti iOS, Android ed Electron. Se salti questo step di sync, i tuoi progetti nativi continueranno a usare il canale precedentemente configurato.

Attenzione

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

Usa defaultChannel solo nei build test/internal; omettilo in produzione per far seguire agli utenti il Cloud Default (se impostato) invece di duplicare il routing nella config nativa.

Puoi comunque forzare (pin) un dispositivo o applicare un override in seguito: questi sovrascriveranno immediatamente il valore della config.

I nomi dei canali sono case-sensitive.

Opzioni e strategie dei Channel

I canali offrono diverse opzioni per controllare chi riceve gli aggiornamenti e come vengono erogati. Le principali sono elencate qui sotto. Puoi configurarle tramite la web app, la CLI o la API pubblica.

• Canale di default: Opzionalmente, 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 “Default Channel Behavior” per gli scenari di routing.
• Filtri per piattaforma: Abilita o disabilita l'invio a iOS, Android, o Electron dispositivi per canale.
• Disabilita auto downgrade sotto native: Impedisce l'invio di un aggiornamento se la versione native dell'app sul dispositivo è più recente del bundle del canale (ad esempio, dispositivo alla 1.2.3 mentre il canale ha la 1.2.2).
• Permetti development builds: Consente aggiornamenti alle development builds (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, esponendo gradualmente un target di rollout separato a un gruppo di dispositivi (sticky cohort). Puoi mettere in pausa, riprendere, promuovere, fare rollback e configurare una risposta automatica in caso di errore senza cambiare il canale per tutti gli utenti. Vedi Rollout progressivi per il modello di delivery, il workflow della dashboard, i campi API e i comandi CLI.

Disabilitare le strategie di Auto Update

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

• major: Blocca un bundle target 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 target la cui versione major o minor differisce da version_build. Esempio: 1.2.3 -> 1.3.0 è bloccato; 1.2.3 -> 1.2.4 è consentito.
• patch: Modalità più restrittiva. Blocca ogni modifica a major, minor o patch. Sono ammessi 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 metadati minimi della versione di update su ogni bundle. Configura tramite CLI usando --min-update-version o --auto-min-update-version. Se mancanti, il canale viene contrassegnato come misconfigurato e gli update saranno rifiutati finché non impostati.
• none: Consente tutti gli update in base alla compatibilità semver.

Queste strategie confrontano il bundle target del canale con la baseline native inviata come version_build, non con l'attuale bundle scaricato inviato come version_name.

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

Esempio (CLI). Il canale deve già esistere (channel set non lo crea automaticamente):

# 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() permette alla tua app Android o iOS di cambiare canale programmaticamente 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 validazione passa, il canale viene salvato nello storage locale del dispositivo come defaultChannel
3. Effetto istantaneo: Il controllo dell'aggiornamento successivo utilizzerà subito il nuovo canale (senza attendere la replica)

Perché è importante: Nelle versioni precedenti, setChannel() salvava l'override del canale nel database backend (come le modifiche via Dashboard o API). I dispositivi dovevano attendere la replica del backend (fino a 2 minuti) prima che il cambio canale fosse effettivo. Ora, setChannel() legge solo dal backend (per la validazione) e lo memorizza localmente, rendendo il cambio canale istantaneo.

Visibilità nella Dashboard: Un canale impostato tramite il plugin non fa apparire il dispositivo come Device Override nell'interfaccia Capgo. Solo gli assegnamenti di canale creati dalla dashboard o dal API pubblico sono elencati lì. Usa la dashboard o API quando serve un override visibile agli admin.

Nota sulla sicurezza: Anche se i permessi di un canale cambiano dopo essere stati impostati localmente (es. l'auto-assegnazione viene disabilitata), il backend convaliderà comunque il canale durante i controlli di aggiornamento, garantendo la sicurezza.

Confronto tra i metodi di cambio canale:

Metodo	Tempo di effetto	Dove viene salvato	Mostrato nella UI Device Override	Scadenza	Caso d'uso
setChannel() dal plugin	Istantaneo	Solo dispositivo (locale)	No	Nessuna scadenza automatica; cancella con unsetChannel() (la reinstallazione potrebbe mantenerlo)	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 caricherà i tuoi asset web e imposterà il nuovo bundle come build attiva per il Development canale. Qualsiasi app configurata per ascoltare quel canale riceverà l'aggiornamento al prossimo controllo.

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

Versioning dei Bundle e Canali

È importante notare che i bundle in Capgo sono globali per l'app, non specifici per singolo canale. Lo stesso bundle può essere assegnato a più canali.

Quando versioni i tuoi bundle, ti consigliamo di usare il semantic versioning con il Semver Tester di Capgo e identificatori pre-release per build specifiche del canale. Ad esempio, una versione 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) quindi la CLI avanza dal bundle collegato al canale finché non trova un nome libero. Con ai, Workers AI deduce il livello dal delta tra il manifest locale e quello precedente (o ripiega su patch senza una versione Capgo precedente). Non è possibile 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 è chiaramente una pre-release di 1.2.3.
• Permette di riutilizzare i numeri di versione tra i canali, riducendo la confusione.
• Permette percorsi di rollback chiari. Se devi effettuare il 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 un setup tipico 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 obbligatorio. L'importante è trovare uno schema di versionamento che comunichi chiaramente le relazioni tra i tuoi build e si allinei al processo di sviluppo del tuo team.

Rollback di un Live Update

Se distribuisci un live update che introduce un bug o che deve essere annullato, puoi effettuare facilmente il rollback a un build precedente. Dalla sezione “Channels” della dashboard:

1. Clicca sul nome del channel che vuoi riportare indietro
2. Trova il build a cui vuoi tornare e clicca sull'icona della corona
3. Conferma l'azione

Il build selezionato diventerà immediatamente il build attivo per quel channel. Le app riceveranno la versione oggetto di rollback al prossimo controllo di aggiornamento.

Automazione dei Deployment

Per workflow più avanzati, puoi automatizzare i deployment di 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 il push su determinati branch o crei nuove release.

Consulta la Integrazione CI/CD documentazione per saperne di più sull'automazione dei Capgo live updates.

PR preview con privilegi minimi

Usa una Anteprima App chiave API quando la CI necessita di un canale temporaneo per ogni pull request, ma non deve gestire i canali main/default esistenti. La chiave rimane legata all'organizzazione proprietaria e all'app selezionata; semplicemente non ha alcun ruolo a livello di organizzazione. Ogni canale di preview non pubblico creato riceve una propria autorizzazione di lifecycle automatica, limitata al singolo canale.

1. Fai creare a un amministratore dell'organizzazione una chiave API sicura, limitata all'app di preview, 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 autonomamente poiché non ha i permessi per le impostazioni dell'app. In GitHub Actions, esegui i job di preview che contengono secret su pull_request, non pull_request_target, e limitandoli alle PR nello stesso repository con github.event.pull_request.head.repo.full_name == github.repository.

Deploy su un dispositivo

Ora che conosci i canali, sei pronto per iniziare a distribuire live updates su dispositivi reali. Il processo base è:

1. Installa Capgo SDK nella tua app
2. Configura l'app per ascoltare il canale desiderato
3. Fai l'upload di un build e assegnalo a quel canale
4. Avvia l'app e attendi l'update!

Per una guida più dettagliata, consulta la Deploy di Live Updates guide. 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, permettendo funzionalità come:

• Feature flag per diversi livelli di utenza
• A/B testing
• Rollout graduale delle feature
• 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 A/B testing.

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.