Canali

Un canale Live Update punta a una specifica versione costruita del pacchetto JS del tuo app che verrà condivisa con qualsiasi dispositivo configurato per ascoltare quel canale per le aggiornamenti. Quando installi il Capgo Live Updates SDK nel tuo app, qualsiasi binario nativo configurato per quel canale controlla per aggiornamenti disponibili ogni volta che l'app viene avviata. Puoi modificare la versione a cui un canale punta 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 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 con abbastanza sforzo perché la chiave pubblica fa parte del client. Vedi Live Update crittografia per i dettagli.

Come un dispositivo sceglie un canale (precedenza)

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

1. Mapping dispositivo obbligatorio (Dashboard) – Pianifica un ID dispositivo specifico su un canale. Utilizza per debug urgenti o test controllati con un singolo utente reale. Questo vince sempre. Capgo rimuove la mappatura 90 giorni dopo l'ultima scrittura di override. Console e API gli override scadono dopo 90 giorni.
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. La reinstallazione del binario non lo cancella; la cancellazione dell'override del dispositivo lo fa. Applica la stessa conservazione dei 90 giorni.
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 override del dispositivo.

Sostituisci il canale istantaneamente 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 principale), setChannel() funziona in modo diverso: contatta il backend per verificare se il canale è consentito (controlla se l'assegnazione auto è abilitata per quel canale), quindi memorizza il canale localmente sul dispositivo come defaultChannelQuesto significa che il nuovo canale ha effetto istantaneamente per la prossima verifica degli aggiornamenti—nessuna attesa per la replica.

In precedenza, setChannel() ha salvato 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 di canale istantanee.

Poiché setChannel() è locale solo, funziona solo localmente not creare un'entry di Override dispositivo nel Capgo dashboard. La UI di Override dispositivo mostra solo gli override creati dal dashboard o dal Public API.

Note: Anche se un canale diventa disabilitato dopo essere stato impostato localmente, il backend continuerà comunque a validare il canale durante le verifiche degli aggiornamenti, mantenendo così la sicurezza.

Important: When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() dalla tua app code—verifica con il backend, quindi imposta il canale localmente per un effetto immediato.

4. configurazione di Capacitor defaultChannel __CAPGO_KEEP_1__ – Se presente in capacitor.config.* e non esiste alcun canale forzato/override/locale, l'applicazione parte su questo canale (ad esempio) beta, qa, pr-123Inteso per TestFlight / edizioni interne, i tester vengono automaticamente indirizzati a un canale di anteprima. Le edizioni di produzione lasciano questo campo invariato.
5. Canale di default Cloud (percorso principale ~99% degli utenti) – Se segni un canale di default nel pannello di controllo, tutti gli utenti normali (nessun forzamento, nessuna sovrascrittura del pannello di controllo/API, nessun plugin locale, nessuna configurazione predefinita per il canale) si attaccano qui. Cambialo per distribuire o ritirare immediatamente—nessun nuovo binario. Se hai impostazioni predefinite 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 di default cloud non impostato è consentito; in quel caso il dispositivo deve corrispondere ai passaggi 1-4 per ricevere aggiornamenti.

Pratica consigliata:

• Tratta 1-4 come livelli di eccezione/test; quando imposti un canale di default cloud, gli utenti reali dovrebbero flusso in esso. Se non lo imposti, sii deliberato su come gli utenti si attaccano (di solito tramite) defaultChannel in configurazione o sovrascritture per dispositivo)
• Solo configurare defaultChannel Nelle versioni binarie che esplicitamente si distribuiscono ai tester. Lasciarlo non impostato 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 > Impostazione Cloud predefinita.

Console e API override scadono dopo 90 giorni

Le mappature forzate e le sovrapposizioni del Dashboard o del canale pubblico API sono memorizzate come assegnamenti per dispositivo in Capgo. Un lavoro di pulizia elimina quegli assegnamenti. 90 giorni dopo l'ultima scrittura di sovrascrittura. Verificarsi per un aggiornamento non resetta quel cronometro. Solo la scrittura della sovrascrittura di nuovo (o cancellandola da te stesso) cambia la data.

Ciò non è lo stesso di inventario di dispositiviL'inventory elimina i dispositivi che non si sono connessi a Capgo da 90 giorni. L'override cleanup elimina la mappatura anche se il dispositivo è ancora attivo.

Per un'assegnazione che non viene eliminata da questa pulizia:

• Imposta defaultChannel in capacitor.config.* (sopravvive alla reinstallazione; richiede un nuovo binario nativo per cambiare in seguito).
• Call setChannel() from the app. On plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 and later, that assignment is local and is not removed by this cleanup. Reinstalling the app clears it, so the app must call setChannel() se ancora desideri quella canale.

Dispositivi Devices tab and the device Override UI only list console and Public API assignments. They do not list every device on the channel, and they do not list local setChannel() __CAPGO_KEEP_0__

Nota di retenzione personalizzata per la scheda dispositivi del canale.

Comportamento del canale predefinito

Impostare un default cloud è facoltativo, ma serve spesso come percorso di default per i nuovi dispositivi. Senza uno, solo i dispositivi che corrispondono alle mappature forzate, alle sovrascritture o a una defaultChannel Nelle impostazioni di configurazione del Capacitor riceveranno aggiornamenti. Quando scegli di segnalare i valori predefiniti, tieni presente questi pattern:

• Default unico (più comune) – Se un canale ha abilitato iOS, Android e Electron, diventa il default unico; qualsiasi dispositivo senza sovrascritture 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 canale come default per la sua piattaforma. Gli dispositivi iOS vanno al default iOS, i dispositivi Android vanno al default Android e le applicazioni Electron vanno al default Electron.

Ricorda che il cloud predefinito e defaultChannel in capacitor.config.* Se entrambi occupano lo stesso livello di decisione. Se imposti un valore predefinito cloud, non devi duplicare il valore nella tua configurazione Capacitor. defaultChannel Vuoto per costruzioni di produzione. Riserva defaultChannel Puoi modificare i valori predefiniti in qualsiasi momento nel pannello di controllo. Apri il canale, quindi

Puoi modificare i valori predefiniti in qualsiasi momento nel pannello di controllo. Apri il canale, quindi , che ti porta aInformazioni sull'app Informazioni sull'app. The default is no longer a toggle on the channel page. When you swap a default, new devices obey the new routing immediately and existing devices follow the normal precedence rules the next time they check in.

Sezione intitolata “Configurazione di un Canale”

Durante l'attivazione crei il primo canale (la maggior parte delle squadre lo chiama “Produzione”), ma nulla è bloccato—puoi rinominare o eliminare 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 canvari di canale possono essere qualsiasi cosa desideriate. Una strategia comune è allineare i canali alle vostre fasi di sviluppo, ad esempio:

• Development - per testare gli aggiornamenti live sulle dispositivi locali o sugli emulatori
• QA per la verifica da parte della vostra squadra QA prima della versione più ampia
• Staging per test finali in un ambiente simile a quello di produzione
• Production - per la versione dell'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.

Apri il tuo capacitor.config.ts o ( capacitor.config.jsonsezione, configurare optionalmente plugins sezione, eventualmente impostata defaultChannel for build test (Interno / QA). Per le build di produzione, preferisci ometterlo in modo che i dispositivi utilizzino il Cloud Default a meno che non venga sovrascritto esplicitamente.

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.
    },
  },
};

Costrui il tuo'app web e esegui npx cap sync to copy the updated config file to your iOS, Android, and Electron projects. If you skip this sync step, your native projects will continue to use whichever channel they were previously configured for.

Attenzione

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

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

Potete comunque forzare (bloccare) un dispositivo o applicare un sovrascrittura in seguito—quelle hanno la precedenza immediata sul valore di 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. Potete configurarle dall'app web, dal CLI, o dal Public API.

• Canale predefinito: Opzionalmente segnala i canali o le piattaforme specifiche che i nuovi dispositivi si connettono. In console, questo vive nelle Informazioni sull'app ("Configura le impostazioni dell'app da pagina del canale). Vedi “Comportamento del canale predefinito” per scenari di routing.
• Filtri di 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 nativa dell'app 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: Consentisci gli aggiornamenti alle edizioni di sviluppo (utili per la prova). CLI: --dev / --no-dev.
• Consenti edizioni di produzione: Consentisci gli aggiornamenti alle edizioni di produzione (magazzino). Lascia questo abilitato per i canali che servono utenti reali. CLI: --prod / --no-prod.
• Consenti dispositivi emulatori: Consentisci gli aggiornamenti ai dispositivi emulatori/simulatore (utili per la prova). CLI: --emulator / --no-emulator.
• Consenti dispositivi fisici: Consentisci gli aggiornamenti a telefoni e tablet reali. Lascia questo abilitato per i canali di produzione. CLI: --device / --no-device.
• Allow device self-assignment: Lets the app switch to this channel at runtime using setChannel. Se disabilitato, setChannel fallirà per questo canale. CLI: --self-assign / --no-self-assign.
• Formato di download: scegli se i dispositivi scaricano un file zip completo, solo i file delta modificati o il meglio di entrambi (all, zip, delta, zip_from_builtin, delta_from_builtin) Vedi Formato di download per il menu a discesa del console e quando ogni modalità è utile.

Rullaggi progressivi

A channel can keep a stable bundle while gradually exposing a separate rollout target to a sticky device cohort. You can pause, resume, promote, roll back, and configure an automatic failure response without switching the channel for everyone. See Rullaggi progressivi Per il modello di consegna, flusso di lavoro del dashboard, campi API e comandi CLI.

Disabilita strategie di aggiornamento automatico

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

• maggiore: Blocca un pacchetto di destinazione con una versione maggiore del suo baseline nativo 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 con una versione maggiore o minore rispetto a 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 maggiore, minore o di patch. Sono consentite solo modifiche ai suffissi 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: Richiedere una versione di aggiornamento minima per ogni bundle. Configurare tramite CLI usando --min-update-version o --auto-min-update-versionSe manca, il canale viene segnalato come non configurato e gli aggiornamenti saranno rifiutati fino a quando non viene impostato.
• nessuno: Consentire tutti gli aggiornamenti secondo compatibilità semver.

Queste strategie confrontano il bundle di destinazione del canale con la baseline nativa inviata come version_builde non il bundle scaricato corrente inviato come version_name.

Scopri di più dettagli e esempi nella strategia di disabilitazione degli aggiornamenti in /docs/cli/commands/#disable-updates-strategy.

Esempio (CLI). Il canale deve già esistere (channel set Non crea (it):

# 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

Utilizzo di setChannel() dal tuo App

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

• Menu di QA/debug dove gli tester possono cambiare tra canali
• Flussi di opzione 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
});

How funziona setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Quando setChannel() viene chiamato:

1. Validazione backend (solo lettura): Viene inviata una richiesta al backend Capgo per verificare se il canale è 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 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 cambiamento del canale avesse effetto. Ora, setChannel() Legge solo dal backend (per la validazione) e memorizza localmente, rendendo le transizioni tra canali istantanee.

Visibilità del dashboard: Un canale impostato con il plugin non fa apparire il dispositivo come un Override del dispositivo nella UI di Capgo. Solo le assegnazioni di canale create dal dashboard o dal Public API sono elencate lì. Utilizza il dashboard o il 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 mantenuta.

Comparazione dei metodi di modifica del canale:

Metodo	Tempo di effetto	Persistente in	Mostrato nell'UI Override del dispositivo	Scade	Utilizzo
setChannel() da plugin	Instantaneo	Solo dispositivo (locale)	No	No (fino a quando non cambi o reinstalli)	Switch channel in-app da parte dell'utente
Override dispositivo dashboard	Fino a 2 minuti	Database backend	Sì	90 giorni dopo l'ultima scrittura di override	Modifiche iniziate dall'amministratore per dispositivi specifici
canale di assegnazione API	Massimo 2 min	database del backend	Sì	90 giorni dopo l'ultima sovrascrittura scritta	Integrazioni di backend automatizzate

Per una migliore esperienza utente quando si costruiscono UI per la selezione dei canali, utilizzare sempre il plugin. setChannel() method.

Versioni minime per il passaggio di canale esclusivamente locale: 5.34.0, 6.34.0, 7.34.0, or 8.0.0 (depending on your major version). Each minor version number corresponds to the same feature set across all major versions (e.g., X.34.0 includes the same features whether X is 5, 6, 7, or 8). See installazione del plugin per tag di versione.

Assegnare un Bundle a un Canale

Per distribuire un live update, è 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 “Bundle” del dashboard Capgo. 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 di la versioning semantico con Capgo’s Tester Semver E identificatori di pre-uscita per edizioni specifiche del canale. Ad esempio, una versione beta potrebbe essere versionata come 1.2.3-beta.1.

In CI, se la versione locale era già caricata, utilizzare npx @capgo/cli@latest bundle upload --auto-bump (facoltativamente major, minor, patch/fix, metadata, o ai) in modo che CLI aumenti dal pacchetto collegato del canale fino a trovare un nome libero. Con ai, Workers AI inferisce il livello dal manifesto locale vs precedente delta (ricade su patch con nessuna versione precedente Capgo). Non è possibile combinarlo con --bundle. Vedi Integrazione CI/CD e il riferimento a CLI.

Questa approccio ha diversi vantaggi:

• Comunica chiaramente la relazione tra le build. 1.2.3-beta.1 è ovviamente una versione pre-rilascio di 1.2.3.
• Consente di riutilizzare i numeri di versione across canali, riducendo la confusione.
• Abilita percorsi di rollback chiari. Se hai bisogno di tornare indietro da 1.2.3sei 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.2, ecc.
• 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 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 con il processo di sviluppo del tuo team.

Ritornare indietro a Live Update

Se hai distribuito una live update che introduce un bug o che altrimenti ha bisogno di essere annullato, puoi facilmente tornare indietro a una versione precedente. Dalla sezione “Canali” della dashboard:

1. Clicca il nome del canale che desideri tornare indietro
2. Trova la versione di costruzione che desideri ripristinare e clicca sull'icona della corona
3. Conferma l'azione

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

Automazione delle distribuzioni

Per flussi di lavoro avanzati, puoi automatizzare le tue distribuzioni live update come parte del tuo pipeline CI/CD. Integrando Capgo nel tuo processo di costruzione, puoi caricare automaticamente nuovi pacchetti e assegnarli ai canali ogni volta che puochi su certi rami o creare nuove versioni.

Ecco i canali Integrazione CI/CD docs to learn more about automating Capgo live updates.

Previsioni di PR con privilegi minimi

Usa un Anteprima dell'app API chiave quando il CI ha bisogno di una canale temporaneo per ogni richiesta di pull, ma non deve gestire i canali esistenti principali/definitivi. La chiave rimane legata all'organizzazione proprietaria e all'app selezionata; essa semplicemente non ha alcun ruolo organizzativo. Ogni canale di anteprima non pubblico che crea riceve le proprie autorizzazioni di ciclo di vita automatiche, scoping per canale.

1. Hai un amministratore dell'organizzazione creare una chiave sicura API limitata all'app di anteprima e selezionare Anteprima dell'appVedi API Chiavi.
2. Hai un canale unico, non pubblico come pr-123Non passare --default, --self-assign, opzioni di rilascio o --delete-linked-bundle-on-upload.
3. Carica e promuovi il bundle PR con un comando, poi elimina il canale e il bundle di proprietà quando il PR si chiude.

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 pacchetto e lo promuove in un flusso unico. La pulizia è atomica e controllata dall'accesso: la chiave può cancellare solo un canale che ha creato e il suo pacchetto correlato, non condiviso. Non può modificare, promuovere o cancellare un canale principale/di default esistente, un canale di anteprima di un'altra chiave o un pacchetto di un'altra chiave.

Se i revisori hanno bisogno di un QR code o di una URL di anteprima, un amministratore deve abilitare le anteprime una volta 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

Un codice App Preview non può abilitare anteprime da solo perché non dispone delle autorizzazioni per le impostazioni dell'app. In GitHub azioni, esegui i lavori di anteprima con segreti. pull_request, non pull_request_target, e limitali a PRs con repository stesso con github.event.pull_request.head.repo.full_name == github.repository.

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 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, consulta il Aggiornamenti in Tempo Reale guide. Buon aggiornamento!

Utilizzo avanzato dei canali: segmentazione degli utenti

I canali possono essere utilizzati per più di solo fasi di sviluppo. Sono uno strumento potente per la segmentazione degli utenti, consentendo funzionalità come:

• Flag di funzionalità per diversi livelli di utenti
• Test A/B
• Rollout graduale delle 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 feature e il testing A/B.

Continua da Canali

Se stai utilizzando Canali connettilo per pianificare la routing del canale e la distribuzione in fasi Canali per i dettagli di implementazione nei canali, Canali per i dettagli di implementazione nei 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 nella Version Targeting Solution, e Capgo Pratiche per l'ambiente: Staging con un ID di App Mobile per il contesto pratico in Capgo Pratiche per l'ambiente: Staging con un ID di App Mobile.