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 confidenzialità

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 abbastanza 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 un dispositivo controlla un aggiornamento, Capgo decide quale canale utilizzare in questo ordine rigoroso (priorità più alta per prima):

1. Mapping dispositivo forzato (Dashboard) – Pianificare un ID dispositivo specifico su un canale. Utilizzare per debug urgenti o test controllati con un singolo utente reale.
2. Override Cloud (per dispositivo) via Dashboard o API – Creato quando cambiate 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 cancella questo; eliminare l'entry 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.

Switching del canale istantaneo con setChannel()

Dal plugin versione 5.34.0, 6.34.0, 7.34.0 o 8.0.0 (in base alla tua versione principale), setChannel() funziona in modo diverso: contatta il backend per validare che il canale sia 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 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.

Perché setChannel() è 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__. Nota: create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Importante: Quando le modifiche ai canali vengono apportate tramite il Dashboard o __CAPGO_KEEP_0__, 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, utilizza

dal tuo app __CAPGO_KEEP_0__—valida con il backend, quindi imposta il canale localmente per effetto immediato. Configurazione API setChannel() from your app code—it validates with the backend, then sets the channel locally for immediate effect.

4. Capacitor config defaultChannel e non esiste un canale di forza/override/locale, l'app inizia su questo canale (ad es. e capacitor.config.* __CAPGO_KEEP_0__ beta, qa, pr-123Inteso per TestFlight / costruzioni interne affinché i tester siano diretti automaticamente su un canale di anteprima.
5. Canale predefinito Cloud (percorso principale ~99% degli utenti) – Se segnala un canale predefinito nella dashboard, tutti gli utenti normali (nessun forzamento, nessuna sovrapposizione Dashboard/API, nessun plugin canale locale, nessuna configurazione defaultChannel) si attaccano qui. Cambialo per distribuire o ritirare immediatamente—nessun nuovo binario. Se hai impostazioni specifiche per piattaforma (ad esempio, uno iOS solo, uno Android solo, uno Electron solo), ogni dispositivo si attacca al default che corrisponde alla sua piattaforma. Lasciare il canale cloud predefinito non impostato è consentito; in quel caso il dispositivo deve corrispondere ai passaggi 1-4 per ricevere aggiornamenti.

Pratica consigliata:

• Tratta 1-4 come eccezioni / layer di testing; quando imposti un canale 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 Configura
• solo nei binari che spedisci esplicitamente ai tester. Lasciarlo non impostato mantiene la logica di produzione centralizzata nella dashboard. defaultChannel Usa
• con parsimonia in produzione—principalmente per QA o diagnostica mirata. setChannel() Se un canale è disabilitato per la piattaforma (iOS/Android/Electron toggle) quando altrimenti sarebbe stato scelto, il processo di selezione lo ignora e continua nella lista.

Riassunto: Forza > Sovrapposizione Dashboard/__CAPGO_KEEP_0__ > Plugin

Summary: Force > Dashboard/API Override > Plugin setChannel() canale locale > Config defaultChannel > Impostazione predefinita di Cloud.

Comportamento del canale predefinito

Impostare un'impostazione predefinita per il cloud è facoltativo, ma serve spesso come percorso di default per i nuovi dispositivi. Senza una impostazione predefinita, solo i dispositivi che corrispondono alle mappature forzate, agli override o a defaultChannel nel Capacitor config riceveranno aggiornamenti. Quando scegli di segnalare impostazioni predefinite, tieni presente:

• Impostazione predefinita singola (più comune) – Se un canale ha abilitato iOS, Android e Electron, diventa l'impostazione predefinita unica; qualsiasi dispositivo senza override si attaccherà qui.
• Impostazioni predefinite specifiche per piattaforma – Se si suddivide i canali per piattaforma (ad esempio, ios-production con abilitato solo iOS, android-production con abilitato solo Android, e electron-production con solo Electron abilitato, segnala ciascuno come predefinito per la sua piattaforma. Gli dispositivi iOS vanno al default iOS, gli Android vanno al default Android e le applicazioni Electron vanno al default Electron.

Ricorda che il cloud predefinito 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 ai tester o QA quando desideri che inizino su un canale non di produzione anche se il cloud predefinito è diverso.

Puoi modificare i predefiniti in qualsiasi momento nel pannello di controllo. Quando scambi un 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.

Configurazione 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 pannello di controllo Capgo
2. Clicca sul pulsante “Nuovo Canale”
3. Inserta un nome per il canale e clicca su "Crea"

Il nome del canale può essere qualsiasi cosa tu voglia. Una strategia comune è di corrispondere i canali alle tue fasi di sviluppo, ad esempio:

• Development - per le aggiornamenti live sulle dispositivi locali o sugli emulatori
• QA - per il tuo team di QA per verificare gli aggiornamenti prima della loro pubblicazione più ampia
• Staging - per il testing 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

Dopo aver creato i canali, devi configurare l'app per ascoltare il canale appropriato. In questo esempio, useremo il Development canale.

Apre il tuo capacitor.config.ts (o capacitor.config.jsonAttenzione, file. Sotto plugins sezione, opzionalmente impostare defaultChannel per le costruzioni di test (interno / QA). Per le costruzioni di produzione, preferire l'omissione affinché 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.
    },
  },
};

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

Attenzione

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

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

È comunque possibile forzare (bloccare) un dispositivo o applicare un sovrapposizione in un secondo momento—quelle hanno la precedenza immediata sulla configurazione.

Il nome del canale è case sensitive.

Opzioni e strategie dei canali

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. È possibile configurarle dall'app web, dal CLI, o dal Public API.

• Canale predefinito: Opzionalmente segnala i canali o le configurazioni specifiche per piattaforma ai nuovi dispositivi che si connettono. Consulta la sezione “Comportamento del canale predefinito” per gli scenari di routing.
• Filtro per piattaforma: Attiva o disattiva la consegna a iOS, Androido 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 canale (ad esempio, dispositivo su 1.2.3 mentre il canale ha 1.2.2).
• Consenti gli aggiornamenti dei build di sviluppo: Consentire gli aggiornamenti ai build di sviluppo (utile per le prove).
• Consenti ai dispositivi emulator: Consentire gli aggiornamenti ai dispositivi emulator/simulator (utile per le prove).
• Consenti l'assegnazione di dispositivo auto: Consente all'app di passare a questo canale in esecuzione utilizzando __CAPGO_KEEP_0__. setChannelSe disabilitato, __CAPGO_KEEP_1__ fallirà per questo canale. setChannel Disabilita le strategie di aggiornamento automatico

Sezione intitolata “Disabilita le strategie di aggiornamento automatico”

maggiore: Blocca una versione di destinazione di bundle la cui versione maggiore è superiore alla baseline nativa del dispositivo (

• Ad esempio:version_buildè bloccato; 1.2.3 -> 2.0.0 Disabilita le strategie di aggiornamento automatico 1.2.3 -> 1.9.0 è consentito.
• minore: Blocca un bundle 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 cambiamento al numero di versione maggiore, minore o di patch. Sono consentiti solo 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.
• metadati: Richiede una versione di aggiornamento minima dei metadati su ogni bundle. Configura tramite CLI utilizzando --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: Consentire tutti gli aggiornamenti in base alla compatibilità di semver Queste strategie confrontano il pacchetto di destinazione del canale con il baseline nativo inviato come.

, non il pacchetto scaricato correntemente inviato come version_buildScopri i dettagli e gli esempi in Disabilita gli aggiornamenti strategia a /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy. version_name.

Esempio (cli):

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

Sezione intitolata “Utilizzando setChannel() dal tuo App”

The setChannel() Il metodo consente all'app di cambiare dinamicamente canale in esecuzione. Questo è particolarmente utile per:

• Menu di debug/QA dove gli tester possono cambiare tra canali
• Flussi di registrazione al 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() è chiamato:

1. Validazione backend (solo lettura): Viene inviata una richiesta al backend Capgo per verificare se il canale è consentito (controllando 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 immediato: La prossima verifica dell'aggiornamento utilizza il nuovo canale immediatamente (nessuna attesa per la riproduzione)

Perché conta: : In versioni precedenti, setChannel() salvava l'override del canale nel database backend (lo stesso di API o le modifiche del Dashboard). 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 nel 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 dell'aggiornamento, garantendo la sicurezza.

Confronto dei metodi di modifica del canale:

Metodo	Tempo di effetto	Persistente in	Visualizzato nel dispositivo Override UI	Utilizzo del caso
setChannel() da plugin	Istantaneo	Solo dispositivo (locale)	No	Modifica del canale da parte dell'utente all'interno dell'app
Dashboard di override del dispositivo	Fino a 2 min	Database del backend	Sì	Modifiche iniziate dall'amministratore per dispositivi specifici
Assegnazione del canale API	Fino a 2 min	Database del backend	Sì	Integrazioni backend automatizzate

Per l'esperienza utente migliore quando si costruisce UI per la commutazione dei canali, utilizzare sempre il metodo del plugin. setChannel() Versioni minime per la commutazione dei canali solo locale:

Minimum versions for local-only channel switching: 5.34.0, 6.34.0, 7.34.0o (a seconda della tua versione principale). Ogni numero di versione minore corrisponde allo stesso set di funzionalità in tutte le versioni principali (ad esempio, X.34.0 include lo stesso set di funzionalità, indipendentemente da se X è 5, 6, 7 o 8). Vedi 8.0.0 installazione del plugin per le etichette delle versioni. Assegnare un Bundle a un Canale

Sottosezione intitolata “Assegnare un Bundle a un Canale”

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

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

canale. Gli app configurati per ascoltare quel canale riceveranno l'aggiornamento la prossima volta che controllano per uno. Development È anche possibile assegnare i build ai canali dalla sezione “Bundles” del __CAPGO_KEEP_0__ dashboard. Clicca sull'icona del menu accanto a un build e seleziona “Assegna a Canale” per scegliere il canale per quel build.

You can also assign builds to channels from the “Bundles” section of the Capgo dashboard. Click the menu icon next to a build and select “Assign to Channel” to choose the channel for that build.

Eseguire la versioning dei bundle e dei canali

E' 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 versioni i tuoi bundle, consigliamo di utilizzare la versioning semantico con Capgo’s Tester Semver e identificatori di pre-uscita per le costruzioni specifiche dei canali. Ad esempio, una versione beta potrebbe essere versionata come 1.2.3-beta.1.

Questa approccio ha diversi vantaggi:

• Evidenzia chiaramente la relazione tra le costruzioni. 1.2.3-beta.1 E' ovvio che è una 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 a cosa ti riferisci 1.2.2 è la versione stabile precedente.

Ecco un esempio di come potresti allineare le versioni del tuo bundle 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.

Utilizzando 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 al tuo processo di sviluppo del team.

Ritornare indietro in un Aggiornamento in Tempo Reale

Clicca sul nome del canale che vuoi tornare indietro

1. Trova la build che vuoi annullare e clicca sull'icona della corona
2. Ritorna la build
3. La build selezionata diventerà immediatamente la build attiva per quel canale. Gli app riceveranno la versione ritornata la prossima volta che controllano per un aggiornamento.

Automatizzare le Distribuzioni

Sezione intitolata “Automatizzare le Distribuzioni”

Capgo

Ecco il modo di fare. Integrazione CI/CD Consultate le doc per imparare di più su come automatizzare gli aggiornamenti Capgo in tempo reale.

Eseguire il Deploy su un Dispositivo

Ora che hai capito i canali, sei pronto a iniziare a eseguire gli aggiornamenti in tempo reale su dispositivi reali. Il processo base è:

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

Per un walkthrough dettagliato, consulta la sezione Eseguire Aggiornamenti in Tempo Reale 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:

• Bandiere di feature per diversi livelli di utenti
• Test A/B
• Eseguire il rilascio di feature graduali
• 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: canali

Se stai utilizzando Canali per pianificare la routing dei canali e la distribuzione in fase di staging, connettilo con Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Soluzione di testing beta per il workflow del prodotto in Soluzione di testing beta, Soluzione di targeting versione per il workflow del prodotto in Soluzione di targeting versione, e Capgo Pratiche di ambiente ottimali: Staging con un ID di app mobile unico per il contesto pratico in Capgo Pratiche di ambiente di miglioramento: Stagione con un ID di App Mobile unico.