Canali

Un canale di aggiornamento Live punta a una specifica build di bundle JS del tuo app che verrà condivisa con qualsiasi dispositivo configurato per ascoltare quel canale per gli aggiornamenti. Quando installare le Capgo Aggiornamenti in Tempo Reale SDK nel tuo'applicazione, qualsiasi binario nativo configurato per quel canale controlla le eventuali aggiornamenti ogni volta che l'applicazione viene avviata. Puoi modificare il canale di costruzione a qualsiasi momento e puoi anche tornare a versioni precedenti se necessario.

Il Canale Non Fornisce Confidentialità

Il canale controlla l'accesso agli aggiornamenti, non la segretezza del pacchetto. Anche se un canale è privato o l'assegnazione auto è disabilitata, 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 distribuito con sufficiente sforzo perché la chiave pubblica fa parte del client. Vedi la crittografia degli Aggiornamenti in Tempo Reale per i dettagli.

Come un dispositivo sceglie un canale (precedenza)

Quando un dispositivo controlla un aggiornamento, Capgo decide quale canale utilizzare in questo ordine rigoroso (priorità più alta per prima):

1. La mappatura forzata del dispositivo (Dashboard) – Pina manualmente un ID dispositivo specifico a un canale. Utilizza per debug urgenti o test controllati con un singolo utente reale. Questo sempre vince.
2. OVERRIDE DEL CLOUD (per dispositivo) via Dashboard o API – Creato quando cambia il canale del dispositivo nel dashboard o via API. Utilizzare per gli utenti QA che passano tra i canali di feature / PR o per riprodurre un problema di utente. La reinstallazione del binario non lo cancella; eliminando l'ingresso del dispositivo.
3. Plugin setChannel() canale locale – Creato quando l'app chiama setChannel() e il backend verifica che il canale di destinazione consente l'assegnazione auto. Il canale selezionato viene memorizzato localmente su quel dispositivo, ha effetto immediatamente e non viene visualizzato nell'interfaccia di sovrascrittura del dispositivo.

Sostituzione del canale istantanea 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 è consentito (verificando 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 replica dei dati.

In precedenza, setChannel() salvava l'override del canale nel database backend (come Dashboard o API modifiche), e i dispositivi dovevano attendere la replica 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.

Poiché setChannel() è solo locale, non crea un'ingresso di Override del dispositivo nel __CAPGO_KEEP_0__ dashboard. L'interfaccia utente dell'Override del dispositivo mostra solo gli override creati dal dashboard o dal Public __CAPGO_KEEP_1__. create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

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

Importante: Quando si effettuano modifiche ai canali tramite il Pannello di controllo o API, c'è ancora un ritardo di replicazione di fino a 2 minuti prima che tutti i server di edge riflettano il cambiamento. Per un cambio di canale istantaneo, utilizzare setChannel() dal tuo app code—valida con il backend, quindi imposta il canale localmente per un effetto immediato.

4. Capacitor config defaultChannel (impostazione predefinita per build di test) – Se presente in capacitor.config.* e non esiste un canale forzato/sovrascrittura locale, l'app si avvia su questo canale (ad esempio, ). Inteso per i build di TestFlight / interni affinché i tester si trovino su un canale di anteprima automaticamente. I build di produzione lasciano spesso questo impostazione non impostata. beta, qa, pr-123Canale predefinito di Cloud (percorso principale ~99% degli utenti)
5. – Se segni un canale predefinito nel pannello di controllo, tutti gli utenti normali (nessun forzamento, nessuna sovrascrittura del pannello di controllo/__CAPGO_KEEP_0__, nessun canale locale del plugin, nessuna impostazione predefinita del config) si attaccano qui. Modificalo per distribuire o ritirare immediatamente—nessun nuovo file binario. Se hai impostazioni predefinite specifiche per piattaforma (ad esempio, uno solo per iOS, uno solo per Android, uno solo per Electron), ogni dispositivo si attacca al predefinito che corrisponde alla sua piattaforma. Lasciare il canale predefinito di Cloud non impostato è consentito; in quel caso il dispositivo deve corrispondere ai passaggi 1–4 per ricevere gli aggiornamenti. – If you mark a default channel in the dashboard, all normal end‑users (no force, no Dashboard/API override, no plugin local channel, no config defaultChannel) attach here. Change it to roll out or roll back instantly—no new binary. If you have platform-specific defaults (for example, one iOS-only, one Android-only, one Electron-only), each device lands on the default matching its platform. Leaving the cloud default unset is allowed; in that case the device must match on steps 1–4 to receive updates.

Pratica consigliata:

• Trattare 1–4 come eccezione / layer di testing; quando imposti un cloud predefinito, gli utenti reali dovrebbero flusso in esso. Se non scegli di impostarlo, essere deliberato su come gli utenti si attaccano (tipicamente via defaultChannel in configurazione o override per dispositivo).
• Configurare defaultChannel solo in binari che si esplicitamente spediscono ai tester. Lasciare in sospeso mantiene la logica di produzione centralizzata nel dashboard.
• Usare setChannel() sparso in produzione—principalmente per QA o diagnostica mirata.

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 > Dashboard/API Override > Plugin setChannel() canale locale > Config defaultChannel > Cloud Default.

Comportamento del canale predefinito

Immettere un valore predefinito per il cloud è facoltativo, ma di solito funge da percorso di default per i nuovi dispositivi. Senza uno, solo i dispositivi che corrispondono alle mappature forzate, agli override o a defaultChannel nel file di configurazione Capacitor riceveranno aggiornamenti. Quando scegli di segnalare i valori predefiniti, tieni presente:

• Valore predefinito singolo (più comune) – Se un canale ha abilitato iOS, Android e Electron, diventa il valore predefinito unico; qualsiasi dispositivo senza override si attaccherà qui.
• Valori predefiniti specifici per piattaforma – Se si suddivide 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), segnala ogni canale come valore predefinito per la sua piattaforma. Gli dispositivi iOS vanno al valore predefinito iOS, i dispositivi Android vanno al valore predefinito Android e le applicazioni Electron vanno al valore predefinito Electron.

Ricorda che il valore predefinito del cloud e defaultChannel in capacitor.config.* entrambi occupano lo stesso livello di decisione. Se imposti un cloud predefinito, non hai bisogno di duplicare il valore nella tua Capacitor configurazione—lascia defaultChannel vuoto per le costruzioni di produzione. Riserva defaultChannel per i binari che intendi spedire intenzionalmente ai tester o QA quando vuoi che inizino su un canale non di produzione anche se il cloud predefinito è diverso

Puoi modificare i valori predefiniti in qualsiasi momento nel pannello di controllo. Quando sostituisci un valore predefinito, i nuovi dispositivi rispettano le nuove impostazioni di routing immediatamente e i dispositivi esistenti seguono le regole di precedenza normali la prossima volta che si connettono

Impostazione di un Canale

Durante l'accesso iniziale 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 pannello di controllo Capgo
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 desideri. Una strategia comune è di sincronizzare i canali con le fasi di sviluppo, ad esempio:

• Development - per testare aggiornamenti live su dispositivi locali o emulatori
• QA - per il team di QA per verificare gli aggiornamenti prima della rilascio più ampio
• Staging - per il testing finale in un ambiente simile a produzione
• Production - per la versione dell'app che gli utenti finali ricevono dai negozi di app

Configurare il 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 sottosezione, impostare optionalmente il defaultChannel per test builds (internazionale / QA). Per le costruzioni di produzione, preferisci ometterlo in modo che i dispositivi utilizzino il Cloud Default a meno che non sia stato 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.
    },
  },
};

Prossimamente, 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 salti questo passaggio di sincronizzazione, i tuoi progetti nativi continueranno ad utilizzare il canale su cui erano configurati precedentemente.

Attenzione

Ordine di selezione del canale: Forza > Dashboard/API sovrascrittura del dispositivo > Plugin setChannel() canale locale > Config defaultChannel > Cloud Default.

Usa defaultChannel solo nelle costruzioni di test/internazionali; lascialo fuori per la produzione in modo che gli utenti seguano il Cloud Default (se impostato) invece di duplicare la routing nella configurazione nativa.

You potresti ancora forzare (bloccare) un dispositivo o applicare un sovrapposizione in un secondo momento—quelle sovrastano immediatamente il valore della 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 gli aggiornamenti sono consegnati. Le più importanti sono quelle elencate di seguito. Puoi configurarle dall'app web, dal CLI, o dal Public API.

• Canale predefinito: Opzionalmente segnala i canali o le canalizzazioni specifiche per piattaforma che i nuovi dispositivi si collegano a. Vedi “Comportamento del canale predefinito” per gli scenari di routing.
• Filtro per piattaforma: Abilita o disabilita la consegna a iOS, Android, o Electron dispositivi per canale.
• Disabilita l'autoabbassamento sotto nativo: Impedisce di inviare un aggiornamento quando la versione dell'app nativa del dispositivo è più recente della bundle del canale (ad esempio, dispositivo su 1.2.3 mentre il canale ha 1.2.2).
• Consenti edizioni di sviluppo: Consentire aggiornamenti alle edizioni di sviluppo (utili per la prova).
• Consenti dispositivi emulatori: Consentire aggiornamenti ai dispositivi emulatori/simulatori (utili per la prova).
• Consenti l'assegnazione del dispositivo: consente all'app di passare a questo canale in esecuzione utilizzando setChannel. Se disabilitato, setChannel fallirà per questo canale.

Disabilita le strategie di aggiornamento automatico

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

• maggiore: Blocca un pacchetto di destinazione la cui versione maggiore è superiore alla baseline nativa del dispositivo (version_build). Esempio: 1.2.3 -> 2.0.0 è bloccato; 1.2.3 -> 1.9.0 è consentito.
• minore: Blocca un pacchetto di destinazione la cui versione maggiore o minore differisce da version_build. Esempio: 1.2.3 -> 1.3.0 è bloccato; 1.2.3 -> 1.2.4 è consentito.
• patch: Modalità più rigorosa. Blocca qualsiasi modifica al numero di versione maggiore, minore o di patch. Sono consentite solo le modifiche ai suffissi 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: Richiedi una versione di aggiornamento minima nel metadati di ogni bundle. Configura tramite CLI utilizzando --min-update-version o --auto-min-update-version. Se mancante, il canale viene segnalato come non configurato e gli aggiornamenti saranno rifiutati fino a quando non viene impostato.
• nessuno: Consentire tutti gli aggiornamenti secondo la compatibilità di semver __CAPGO_KEEP_0__.

Queste strategie confrontano la bundle del canale di destinazione con la baseline nativa inviata come version_builde non la bundle attualmente scaricata inviata come version_name.

Scopri ulteriori dettagli e esempi nella strategia di disabilitazione degli aggiornamenti alla sezione /docs/cli/commands/#disable-updates-strategy.

Esempio (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

Utilizzando setChannel() dal tuo App

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

• Menu di QA/debug dove gli tester possono cambiare tra canali
• Flussi di opzione per il programma beta
• Eseguimento delle implementazioni delle bandiere di feature
• Scenari di test 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() è chiamato:

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

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

Visibilità del dashboard: Un canale impostato con il plugin non fa apparire il dispositivo come un Override del dispositivo nella Capgo UI. Solo le assegnazioni di canale create dal dashboard o dal Public API sono elencate lì. Utilizza il dashboard o API quando hai bisogno di un override visibile dagli amministratori.

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

Comparazione dei metodi di cambio del canale:

Metodo	Tempo di effetto	Salvati dove	Visualizzato nell'interfaccia di override del dispositivo	Utilizzo
setChannel() da plugin	istantaneo	Dispositivo solo (locale)	No	Switch di canale inizializzato dall'utente all'interno dell'app
Override del dispositivo nel pannello di controllo	Fino a 2 min	Database del backend	Sì	Modifiche iniziate dall'amministratore per dispositivi specifici
API assegnazione del canale	Fino a 2 min	Database del backend	Sì	Integrazioni di backend automatizzate

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

, o 5.34.0, 6.34.0, 7.34.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 dal fatto che X sia 5, 6, 7 o 8). Vedi 8.0.0 installazione del plugin plugin’s per etichette di versione.

Assegnare un Bundle a un Canale

Per distribuire un aggiornamento live, è 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. Gli app configurate per ascoltare quel canale riceveranno l'aggiornamento la prossima volta che controllano per uno.

Puoi anche assegnare le costruzioni ai canali dalla sezione “Bundles” del Capgo dashboard. Clicca l'icona del menu accanto a una costruzione e seleziona “Assegna a Canale” per scegliere il canale per quella costruzione.

Versionamento dei Bundle e Canali

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

When versioni i tuoi pacchetti, raccomandiamo l'uso di la versioning semantico con Capgo’s Tester Semver e identificatori di pre-uscita per costrutti specifici del canale. Ad esempio, una versione beta potrebbe essere versionata come 1.2.3-beta.1.

Questa approccio ha diversi benefici:

• Comunica chiaramente la relazione tra i costrutti. 1.2.3-beta.1 è ovviamente una versione pre-uscita di 1.2.3.
• Consente di riutilizzare i numeri di versione all'interno dei canali, riducendo la confusione.
• Abilita percorsi di rollback chiari. Se hai bisogno di tornare indietro da 1.2.3, sai che 1.2.2 è la versione stabile precedente.

Ecco un esempio di come potresti allineare le versioni dei tuoi pacchetti con un setup di canale tipico:

• 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-lancio è 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

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

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

La versione selezionata diventerà immediatamente la versione attiva per quel canale. Le app riceveranno la versione annullata la prossima volta che controllano gli aggiornamenti.

Automazione delle distribuzioni

Per flussi di lavoro più avanzati, è possibile automatizzare le distribuzioni live aggiornamenti come parte del proprio pipeline CI/CD. Integrando Capgo nel proprio processo di build, è possibile caricare automaticamente nuovi pacchetti e assegnarli ai canali ogni volta che si pubblicano determinate branch o si creano nuove release.

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

Deployare 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 una guida dettagliata, vedi il Distribuire Aggiornamenti Live guide. Buona fortuna!

Utilizzo avanzato dei canali: segmentazione degli utenti

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

• bandiere 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 bandiere di feature e i test A/B.

Continua da qui: i canali

i canali per pianificare la routing dei canali e il rollout a fasi, 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 per l'ambiente di produzione: Staging con un ID di App Mobile per il contesto pratico in Capgo Pratiche per l'ambiente di produzione: Staging con un ID di App Mobile.