Canali

Un canale di aggiornamento in tempo reale punta a una specifica versione costruita del pacchetto JS del tuo app che verrà condivisa con qualsiasi dispositivo configurato per ascoltare quel canale per gli aggiornamenti. Quando installi il Capgo Aggiornamenti in tempo reale SDK nel tuo app, qualsiasi binario nativo configurato per quel canale controlla per gli aggiornamenti disponibili ogni volta che l'app viene avviata. Puoi modificare la versione a cui punta il canale in qualsiasi momento e puoi anche tornare a versioni precedenti se necessario.

I Canali Non Forniscono Confidentialità

I canali controllano l'accesso agli aggiornamenti, non la segretezza del pacchetto. Anche se un canale è privato o è disabilitata l'assegnazione auto, qualsiasi pacchetto non crittografato caricato su Capgo dovrebbe ancora essere trattato come un asset pubblico consegnato ai clienti. La crittografia protegge il percorso di consegna e l'autenticità degli aggiornamenti, ma i pacchetti consegnati possono ancora essere sottoposti a reverse engineering dal client con sufficiente sforzo perché la chiave pubblica fa parte del client. Vedi L'encryption degli aggiornamenti in tempo reale per i dettagli.

Come un dispositivo sceglie un canale (precedenza)

When a device checks for an update, Capgo decide quale canale utilizzare in questo ordine rigoroso (priorità più alta per prima):

1. Mapping dispositivo obbligatorio (Dashboard) – Pianifica manualmente un ID dispositivo specifico su un canale. Utilizza per debug urgenti o test controllati con un singolo utente reale. Questo sempre vince.
2. Override Cloud (per dispositivo) via Dashboard o API – Creato quando cambia il canale del dispositivo nel dashboard o via API. Utilizza per gli utenti QA che passano tra i canali di feature / PR o per riprodurre un problema di utente. Ristallando il binario non si cancella; eliminando l'ingresso dispositivo si cancella.

Switching canale istantaneo con setChannel()

A partire dalla versione del plugin 5.34.0, 6.34.0, 7.34.0 o 8.0.0 (in base alla tua versione maggiore), setChannel() funziona in modo diverso: contatta il backend per validare che il canale sia consentito (controlla se l'assegnazione auto è abilitata per quel canale), quindi memorizza il canale localmente sul dispositivo come defaultChannel. Ciò significa che il nuovo canale ha effetto istantaneamente per la prossima verifica degli aggiornamenti—nessuna attesa per la riproduzione.

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

Nota: Anche se un canale diventa non consentito dopo essere stato impostato localmente, il backend lo valuterà ancora durante le verifiche degli aggiornamenti, quindi la sicurezza è mantenuta.

Importante: Quando si effettuano modifiche ai canali tramite il Dashboard o API, è ancora presente un ritardo di riproduzione di fino a 2 minuti prima che tutti i server di edge riflettano il cambiamento. Per una scelta dei canali istantanea, utilizza setChannel() dal tuo app code—valida con il backend, quindi imposta il canale localmente per un effetto immediato.

3. Capacitor configurazione defaultChannel (costruzione di test predefinita) – Se presente in capacitor.config.* e non esiste una forza/override, l'app inizia su questo canale (ad esempio, ""). Inteso per le costruzioni di TestFlight / interne affinché i tester atterrino automaticamente su un canale pre‑rilascio. beta, qa, pr-123Canale predefinito Cloud (percorso principale ~99% degli utenti)
4. – Se segni un canale predefinito nel pannello di controllo, tutti gli utenti normali (nessuna forza, nessuna override, nessuna configurazione predefinitoChannel) si collegano qui. Cambialo per distribuire o ritirare immediatamente – nessun nuovo binario. Se hai impostazioni predefinite specifiche per piattaforma (ad esempio, uno iOS-only, uno Android-only, uno Electron-only), ogni dispositivo atterra sul predefinito che corrisponde alla sua piattaforma. Lasciare il canale predefinito cloud non impostato è consentito; in quel caso il dispositivo deve corrispondere ai passaggi 1–3 per ricevere aggiornamenti. Pratica consigliata:

Tratta 1–3 come layer di eccezione / di testing; quando imposti un canale predefinito cloud, gli utenti reali dovrebbero flusso in esso. Se non scegli di impostarlo, sii deliberato su come gli utenti si collegano (tipicamente via

• in configurazione o per dispositivo override). defaultChannel Configura solo
• in binari che spedisci esplicitamente ai tester. Lasciarlo non impostato mantiene la logica di produzione centralizzata nel pannello di controllo. defaultChannel – If present in
• Usa con parsimonia in produzione—principalmente per le prove di qualità o i diagnostici mirati. setChannel() Se un canale è disabilitato per la piattaforma (iOS/Android/Electron toggles) quando altrimenti sarebbe stato scelto, il processo di selezione lo ignora e continua nella lista.

Riassunto: Forza > Override > Config

> Impostazione predefinita Cloud. defaultChannel Comportamento predefinito del canale

Sottosezione intitolata “Comportamento predefinito del canale”

configurazione del __CAPGO_KEEP_0__ riceveranno aggiornamenti. Quando scegli di segnare i valori predefiniti, tieni presente: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• – Se un canale ha iOS, Android e Electron abilitati, diventa l'impostazione predefinita unica; qualsiasi dispositivo senza override si attaccherà qui. Impostazioni predefinita specifiche per piattaforma
• Use sparingly in production—mainly for QA or targeted diagnostics. – Se si suddividono 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), segnalare ogni uno come predefinito per la sua piattaforma. I dispositivi iOS vanno al default iOS, i dispositivi Android vanno al default Android, e le applicazioni Electron vanno al default Electron.

Ricordate che il default cloud e defaultChannel in capacitor.config.* entrambi occupano lo stesso livello di decisione. Se si imposta un default cloud, non è necessario duplicare il valore nella configurazione Capacitor — lasciare defaultChannel vuoto per le costruzioni di produzione. Riservare defaultChannel per i binari che si intendono spedire ai tester o QA quando si desidera che inizino su un canale non di produzione anche se il default cloud è diverso.

È possibile modificare i default in qualsiasi momento nel dashboard. Quando si scambia un default, i nuovi dispositivi rispettano le nuove impostazioni di routing immediatamente e i dispositivi esistenti seguono le normali regole di precedenza la prossima volta che si verificano.

Impostazione di un Canale

Durante l'onboarding crei il primo canale (la maggior parte delle squadre lo chiama “Produzione”), ma nulla è bloccato—puoi rinominare o cancellare qualsiasi canale in qualsiasi momento. Per aggiungere canali aggiuntivi in seguito:

1. Vai alla sezione “Canali” del Capgo dashboard
2. Clicca sul pulsante “Nuovo Canale”
3. Inserisci un nome per il canale e clicca su “Crea”

I nomi dei canali possono essere qualsiasi cosa tu voglia. Una strategia comune è di corrispondere i canali alle tue fasi di sviluppo, ad esempio:

• Development - per testare aggiornamenti live su dispositivi locali o emulatori
• QA - per il tuo team QA per verificare gli aggiornamenti prima di una maggiore diffusione
• Staging - per il test finale in un ambiente di produzione simile
• Production - per la versione del tuo app che gli utenti finali ricevono dai negozi di app

Configurazione del Canale nell'App

Con i canali creati, hai bisogno di configurare l'app per ascoltare il canale appropriato. In questo esempio, useremo il Development Canale.

Apre il tuo capacitor.config.ts (o capacitor.config.json) file. Sotto la plugins sezione, impostare optionalmente defaultChannel per costruzioni di test (interni / QA). Per le costruzioni di produzione, preferisci omettere questo valore in modo che i dispositivi utilizzino 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, costruisci il tuo app web e esegui npx cap sync per copiare il file di configurazione aggiornato nei tuoi progetti iOS, Android e Electron. Se omitti questo passaggio di sincronizzazione, i tuoi progetti nativi continueranno ad utilizzare il canale con cui erano precedentemente configurati.

Attenzione

Ordine della selezione del canale: Forza > Override (setChannel / dashboard) > Config defaultChannel > Impostazione predefinita Cloud.

Usa defaultChannel solamente nei costrutti di test/interni; lascialo fuori per la produzione affinché gli utenti seguano l'Impostazione predefinita Cloud (se impostata) invece di duplicare la routing nella configurazione nativa.

Potete comunque forzare (bloccare) un dispositivo o applicare un override in un secondo momento—quelli hanno la precedenza immediata sulla configurazione.

Il nome del canale è case sensitive.

Opzioni e strategie del canale

Il canale ha diverse opzioni che controllano chi può ricevere aggiornamenti e come vengono consegnati gli aggiornamenti. Le più importanti sono quelle elencate di seguito. Potete configurarle dall'app web, dal CLI, o dal Public API.

• Canale predefinito: Opzionalmente segnate i canali o le impostazioni del canale specifiche per i dispositivi nuovi che si connettono. Vedere “Comportamento del canale predefinito” per gli scenari di routing.
• Filtri di piattaforma: Attiva o disattiva la consegna a iOS, Android, o Electron dispositivi per canale.
• Disabilita l'auto downgrade sotto nativo: Impedisce di inviare un aggiornamento quando la versione dell'app nativa del dispositivo è più recente della versione del pacchetto del canale (ad esempio, dispositivo su 1.2.3 mentre il canale ha 1.2.2).
• Consenti aggiornamenti di build di sviluppo: Consentire aggiornamenti ai build di sviluppo (utile per la prova).
• Consenti dispositivi emulator: Consentire aggiornamenti ai dispositivi emulator/simulator (utile per la prova).
• Consenti l'assegnazione di dispositivo auto: Lascia che l'app passi a questo canale in esecuzione utilizzando setChannel. Se disabilitato, setChannel fallirà per questo canale.

Disabilita strategie di aggiornamento automatico

Usa questo per limitare quali tipi di aggiornamenti il canale consegnerà automaticamente. Opzioni:

• major: Blocca gli aggiornamenti intermajor (0.0.0 → 1.0.0). Gli aggiornamenti minori e di patch sono ancora consentiti.
• minor: Blocca gli aggiornamenti interminor (ad esempio, 1.1.0 → 1.2.0) e gli aggiornamenti maggiori. Gli aggiornamenti di patch sono ancora consentiti. Nota: non blocca 0.1.0 → 1.1.0.
• patch: Estremamente rigoroso. Consente solo l'aumento delle versioni di patch all'interno della stessa versione maggiore e minore. Esempi: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata: Richiede una versione minima di aggiornamento di metadati su ogni bundle. Configura tramite CLI usando --min-update-version o --auto-min-update-version. Se mancante, il canale viene segnalato come configurato in modo errato e gli aggiornamenti saranno rifiutati fino a quando non viene impostato.
• none: Consenti tutti gli aggiornamenti in base alla compatibilità di semver. Scopri di più dettagli e esempi nella strategia di disabilitazione degli aggiornamenti alla sezione /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy. Esempio (__CAPGO_KEEP_0__):.

Learn more details and examples in Disable updates strategy at /docs/cli/commands/#disable-updates-strategy.

Example (CLI):

# 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

Usando setChannel() dal tuo App

Il setChannel() metodo consente al tuo app di cambiare canale in modo programmatico durante l'esecuzione. Questo è particolarmente utile per:

• Menu di QA/debug dove gli tester possono cambiare tra canali
• Flussi di registrazione per il programma beta
• Implementazioni delle bandiere di feature
• Scenari di testing A/B

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() si chiama:

1. Validazione backend (lettura solo): Viene inviata una richiesta al backend Capgo per validare il canale è consentito (verificando le autorizzazioni di assegnazione auto)
2. Aggiornamento archiviazione locale: Se la validazione ha successo, il canale viene salvato nell'archiviazione locale del dispositivo come defaultChannel
3. Effetto immediato: La prossima verifica dell'aggiornamento utilizza il nuovo canale immediatamente (nessuna attesa per la replica)

Perché conta: In versioni precedenti, setChannel() salvava l'override del canale nel database backend (lo stesso di Dashboard o API modifiche). I dispositivi dovevano attendere la replica del backend (fino a 2 minuti) prima che il cambio del canale avesse effetto. Ora, setChannel() si legge solo dal backend (per la validazione) e si archivia localmente, rendendo i cambiamenti di canale istantanei.

Nota di sicurezza: Anche se i permessi di un canale cambiano dopo essere stati impostati localmente (ad esempio, l'auto-assegnazione è disabilitata), il backend verificherà ancora il canale durante le verifiche di aggiornamento, garantendo la sicurezza.

Confronto dei metodi di modifica del canale:

Metodo	Tempo di effetto	Persistente in	Utilizzo
setChannel() da plugin	Subito	Solo dispositivo (locale)	Modifica del canale iniziativa dell'utente all'interno dell'app
Override del dispositivo del pannello di controllo	Fino a 2 minuti	Database di backend	Modifiche iniziate dall'amministratore per dispositivi specifici
API assegnazione del canale	Fino a 2 min	Database di backend	Integrazioni backend automatizzate

Per l'esperienza utente migliore quando si costruisce UI di cambio canale, utilizzare sempre il metodo del plugin. setChannel() Metodo.

Versioni minime per il cambio canale locale solo: 5.34.0, 6.34.0, 7.34.0, o 8.0.0 (in base alla versione maggiore). Ogni numero di versione minore corrisponde allo stesso set di funzionalità in tutte le versioni maggiori (ad esempio, X.34.0 include le stesse funzionalità indipendentemente da X che sia 5, 6, 7 o 8). Vedi installazione del plugin per versioni dei tag.

Assegnare un Bundle a un Canale

Per distribuire un aggiornamento in tempo reale, è necessario caricare un nuovo build del bundle JS e assegnarlo a un canale. Ciò può essere fatto in un solo passo con il Capgo CLI:

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

Ciò caricherà i tuoi asset web costruiti e stabilirà il nuovo bundle come build attiva per il Development canale. Qualsiasi app configurata per ascoltare quel canale riceverà l'aggiornamento la prossima volta che controlla per uno.

Puoi anche assegnare i build ai canali dalla sezione “Bundles” del Capgo dashboard. Clicca l'icona del menu accanto a un build e seleziona “Assegna a Canale” per scegliere il canale per quel build.

Versionamento dei Bundle e Canali

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

When versioni i tuoi pacchetti, raccomandiamo l'uso della versioning semantico con __CAPGO_KEEP_0__’s Semver Tester e identificatori di pre-uscita per costruzioni specifiche del canale. Ad esempio, una versione beta potrebbe essere versionata come semantic versioning with Capgo’s Semver Tester Evidenzia chiaramente la relazione tra le costruzioni. 1.2.3-beta.1.

E' ovvio che è una versione pre-uscita di

• Consente di riutilizzare i numeri di versione all'interno dei canali, riducendo la confusione. 1.2.3-beta.1 Consente percorsi di rollback chiari. Se hai bisogno di tornare indietro da 1.2.3.
• sei a conoscenza che
• è la versione stabile precedente. 1.2.3Ecco un esempio di come potresti allineare le versioni dei tuoi pacchetti con un setup di canale tipico: 1.2.2 canale:

canale:

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

Utilizzo utilizzare semver con identificatori di versione pre-release è un approccio raccomandato, ma non strettamente richiesto. La chiave è trovare uno schema di versioning che comunichi chiaramente le relazioni tra le tue build e si allinei con il processo di sviluppo del tuo team.

Ritornare indietro in un aggiornamento in tempo reale

If si dispiega un aggiornamento live che introduce un bug o che deve essere annullato, puoi facilmente tornare a una versione precedente. Dalla sezione “Canali” del pannello di controllo:

1. Seleziona il nome del canale che desideri annullare
2. Trova la versione che desideri annullare e clicca sull'icona della corona
3. Conferma l'azione

La versione selezionata diventerà immediatamente la versione attiva per quel canale. Gli app saranno in grado di ricevere la versione annullata la prossima volta che controllano gli aggiornamenti.

Automazione delle distribuzioni

Per flussi di lavoro più avanzati, puoi automatizzare le distribuzioni live aggiornamenti come parte del tuo pipeline CI/CD. Integrando Capgo nel tuo processo di build, puoi caricare automaticamente nuove bundle e assegnarli ai canali ogni volta che puoi spingere su determinate branch o creare nuove release.

Esegui una visita al Integrazione CI/CD i documenti per imparare di più sull'automazione degli aggiornamenti live Capgo.

Distribuisci su un Dispositivo

Ora che hai capito i canali, sei pronto a iniziare a distribuire aggiornamenti live su dispositivi reali. Il processo base è:

1. Installa il Capgo SDK nel tuo app
2. Configura l'app per ascoltare il tuo canale desiderato
3. Carica un build e assegna il canale a quel build
4. Lancia l'app e attendi l'aggiornamento!

Per un walkthrough dettagliato, vedi il Distribuisci Aggiornamenti Live guide. Buon aggiornamento!

Utilizzo avanzato dei canali: Segmentazione degli utenti

i canali possono essere utilizzati per più di solo le fasi di sviluppo. Sono uno strumento potente per la segmentazione degli utenti, che consente di attivare funzionalità come:

• flag di feature per diversi livelli di utenti
• test A/B
• rollout di feature graduale
• programmi di test beta

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

Continua da qui: i canali

i canali per pianificare la routing dei canali e il rollout graduale, connettilo con Section titled “Continua da qui: i canali” Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Soluzione di Test Beta per il flusso di lavoro del prodotto in Soluzione di Test Beta, Soluzione di Targetizzazione della Versione per il flusso di lavoro del prodotto in Soluzione di Targetizzazione della Versione, e Capgo Pratiche di Miglioramento dell'ambiente: Staging con un ID di App Mobile Unico per il contesto pratico in Capgo Pratiche di Miglioramento dell'ambiente: Staging con un ID di App Mobile Unico.