Saltare al contenuto
Capgo - Aggiornamenti in Tempo Reale per App Capacitor Capgo

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 aggiornamenti. Quando installa le Capgo Aggiornamenti in Tempo Reale SDK nel tuo app, qualsiasi binario nativo configurato per quel canale controlla le eventuali aggiornamenti ogni volta che l'app viene avviata. Puoi modificare il canale a cui si riferisce la costruzione in qualsiasi momento e puoi anche tornare a versioni precedenti se necessario.

Come un dispositivo sceglie un canale (precedenza)

Sezione intitolata “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 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 un utente. La reinstallazione del binario non lo cancella; eliminare l'ingresso del dispositivo fa lo stesso.
  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 mostrato nell'interfaccia di sovrascrittura del dispositivo.
  1. Capacitor config defaultChannel (costruzione di test predefinita) – Se presente in capacitor.config.* e non esiste un canale forzato/sovrascrittura locale, l'app inizia su questo canale (ad esempio, ). beta, qa, pr-123Inteso per le costruzioni di TestFlight / interne affinché i tester atterrino su un canale pre‑rilascio automaticamente. Le costruzioni di produzione lasciano spesso questo non impostato.
  2. Canale predefinito di Cloud (percorso principale ~99% degli utenti) – Se segni un canale predefinito nel pannello di controllo, tutti gli utenti normali (nessun forzo, nessuna sovrascrittura del pannello di controllo/API, nessun canale locale del plugin, nessuna configurazione predefinita del canale) si attaccano qui. Modificalo per distribuire o ritirare immediatamente—nessun nuovo binario. Se hai dei valori predefiniti specifici 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 di cloud non impostato è consentito; in quel caso il dispositivo deve corrispondere ai passaggi 1–4 per ricevere gli aggiornamenti.

Pratica consigliata:

  • Tratta 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).
  • Configura solo defaultChannel in binari che esporti esplicitamente ai tester. Lasciare in sospeso mantiene la logica di produzione centralizzata nel dashboard.
  • Usa setChannel() con parsimonia in produzione—principalmente per QA o diagnostica mirata.

Se un canale è disabilitato per la piattaforma (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

Sezione intitolata “Comportamento del canale predefinito”

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

  • Default unico (più comune) – Se un canale ha abilitato iOS, Android e Electron, diventa il default unico; qualsiasi dispositivo senza override si attaccherà qui.
  • Default 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 uno come default per la sua piattaforma. Gli iOS vanno al default iOS, gli Android vanno al default Android, e gli app Electron vanno al default Electron.

Ricorda che il default cloud e defaultChannel in capacitor.config.* occupano lo stesso livello di decisione. Se imposti un cloud predefinito, non hai bisogno di duplicare il valore nella tua Capacitor configurazione— defaultChannel lascia vuoto per le costruzioni di produzione. Riserva defaultChannel per i binari che intendi inviare intenzionalmente ai tester o QA quando desideri 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.

Configurazione di un Canale

Sottosezione intitolata “Configurazione di un Canale”

Durante l'acquisizione dei dati, 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”

Il nome del canale può essere qualsiasi cosa tu desideri. Una strategia comune è di sincronizzare i canali con le fasi di sviluppo, ad esempio:

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

Configurare il Canale nell'App

Sottosezione intitolata “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 affinché 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.
    },
  },
};

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 di cui erano precedentemente configurati.

Opzioni e strategie del canale

Sottosezione intitolata “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 in tempo reale utilizzando setChannelSe disabilitato, setChannel fallirà per questo canale.

Disabilita le strategie di aggiornamento automatico

Sottosezione intitolata “Disabilita le strategie di aggiornamento automatico”

Utilizza 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_buildEsempio: 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_buildEsempio: 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.

Queste strategie confrontano la bundle di destinazione del canale con la baseline nativa inviata come version_build, non la bundle scaricata correntemente inviata come version_name.

Impara i dettagli e gli esempi in Disable updates strategy alla pagina /docs/cli/commands/#disable-updates-strategy.

Esempio (CLI):

Finestra del terminale
# 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

Sezione intitolata “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
  • Implementazioni delle bandiere delle funzionalità
  • Scegli la versione 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
});

Assegnare un Bundle a un Canale

Sezione intitolata “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:

Finestra del terminale
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 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

Sezione intitolata “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 di la versioning semantico con Capgo’s Tester Semver e identificatori di rilascio prenotificati per i costrutti specifici del canale. Ad esempio, un rilascio beta potrebbe essere versionato come Questa approccio ha diversi benefici: 1.2.3-beta.1.

Comunica chiaramente la relazione tra i costrutti.

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

canale:

  • Development channel: 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 rilascio prenotificati è 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 processo di sviluppo del tuo team.

Ritornare all'aggiornamento in tempo reale

Sezione intitolata “Ritornare all'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 tornare a utilizzare
  2. Cerca la versione che desideri annullare e clicca sull'icona della corona Versione di rollback
  3. Conferma l'azione

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

Automazione delle distribuzioni

Sottosezione intitolata “Automazione delle distribuzioni”

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

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

Deploying to a Device

Sottosezione intitolata “Deploying to a Device”

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 Distribuzione Aggiornamenti Live guide. Buona fortuna con gli aggiornamenti!

Utilizzo avanzato dei canali: segmentazione degli utenti

Sottosezione intitolata “Utilizzo avanzato dei canali: segmentazione degli utenti”

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 funzionalità per diversi livelli di utenti
  • Test A/B
  • Rollout graduale di funzionalità
  • 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 funzionalità e i test A/B.

Continua da qui: Canali

Sottosezione intitolata “Continua da qui: Canali”

Se stai utilizzando Canali per pianificare la routing dei canali e il rollout graduale, connettilo con 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 Targeting della Versione per il flusso di lavoro del prodotto in Soluzione di Targeting della Versione, e Capgo Pratiche per l'ambiente di sviluppo: Staging con un ID di App Mobile Unico per il contesto pratico in Capgo Pratiche per l'ambiente di sviluppo: Staging con un ID di App Mobile Unico.