Targeting di versione
Copia un prompt di configurazione con i passaggi di installazione e la guida markdown completa per questo plugin.
Questa guida spiega come consegnare automaticamente la versione bundle più recente compatibile agli utenti in base alla loro versione nativa dell'applicazione, simile all'approccio di Ionic AppFlowCiò garantisce una gestione degli aggiornamenti semplificata e un lancio più rapido, evitando problemi di compatibilità.
Panoramica
Sezione intitolata “Panoramica”Capgo's sistema di targeting delle versioni consente di:
- Invia automaticamente aggiornamenti compatibili ai utenti in base alla versione nativa dell'app
- Prevenire i cambiamenti che rompono l'applicazione da raggiungere versioni di app incompatibili
- Gestisci diverse versioni di app Contemporaneamente senza logica complessa
- Aggiorna senza problemi a specifici segmenti di utenti
Perché la Versione Targeting è Importante (Soprattutto per gli Utenti di AppFlow)
Perché la versione di destinazione è importante (soprattutto per gli utenti di AppFlow)Se sei familiare con Ionic AppFlow, sai quanto sia critico assicurarsi che gli utenti ricevano solo aggiornamenti compatibili. AppFlow ha automaticamente corrisposto live update bundle alle versioni native di app, impedendo che JavaScript incompatibile fosse consegnato alle versioni native più vecchie di code.
Capgo offre le stesse garanzie di sicurezza, con funzionalità aggiuntive:
- Controllo più granulare sulla corrispondenza delle versioni
- Strategie multiple (canali, semver, vincoli nativi)
- Migliore visibilità sulla distribuzione delle versioni
- API e CLI controllano insieme alla gestione del pannello
Questo approccio è particolarmente utile quando:
- Hai utenti su diverse versioni maggiori dell'app (ad esempio, v1.x, v2.x, v3.x)
- Hai bisogno di mantenere la compatibilità inversa mentre rilasci cambiamenti breaking
- Vuoi prevenire che i pacchetti più recenti rompano le code native più vecchie
- Stai migrando gli utenti gradualmente da una versione all'altra
- Stai migrando da AppFlow E vuoi mantenere la stessa sicurezza degli aggiornamenti
Come Funziona
Sezione intitolata “Come Funziona”Capgo utilizza un approccio multi-layered per abbinare gli utenti con aggiornamenti compatibili:
- Restrizioni di Versione Nativa: Prevenire i pacchetti da essere consegnati a versioni native incompatibili
- Routing per Canali: Inviare diverse versioni dell'applicazione a diversi canali di aggiornamento
- Controlli di Versioning Semantico: Bloccare automaticamente gli aggiornamenti ai confini di major/minor/patch
- Override a livello di dispositivo: Targetare dispositivi specifici o gruppi di utenti
Flusso di Abbinamento di Versione
Sezione intitolata “Flusso di Abbinamento di Versione”graph TD A[User Opens App] --> B{Check Device Override} B -->|Override Set| C[Use Override Channel] B -->|No Override| D{Check local plugin channel} D -->|setChannel value| E[Use local setChannel channel] D -->|No local channel| F{Check defaultChannel in App} F -->|Has defaultChannel| G[Use App's defaultChannel] F -->|No defaultChannel| H[Use Cloud Default Channel] C --> I{Check Version Constraints} E --> I G --> I H --> I I -->|Compatible| J[Deliver Update] I -->|Incompatible| K[Skip Update]Strategy 1: Routing della versione basato sul canale
Sezione intitolata “Strategy 1: Routing della versione basato sul canale”Questo è il metodo consigliato per gestire i cambiamenti di versione e le aggiornamenti di versione principale. È simile al modello di consegna di AppFlow.
Scenario di esempio
Sezione intitolata “Scenario di esempio”- App v1.x (100.000 utenti) →
productioncanale - App v2.x (50.000 utenti con modifiche di rottura) →
v2canale - App v3.x (10.000 utenti beta) →
v3canale
Implementazione
Sezione intitolata “Implementazione”Passo 1: Configura i canali per ogni versione maggiore
Sezione intitolata “Passo 1: Configura i canali per ogni versione maggiore”// capacitor.config.ts for version 1.x buildsimport { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = { appId: 'com.example.app', appName: 'Example App', plugins: { CapacitorUpdater: { autoUpdate: 'atBackground', defaultChannel: 'production', // or omit for default } }};
export default config;// capacitor.config.ts for version 2.x buildsconst config: CapacitorConfig = { appId: 'com.example.app', appName: 'Example App', plugins: { CapacitorUpdater: { autoUpdate: 'atBackground', defaultChannel: 'v2', // Routes v2 users automatically } }};// capacitor.config.ts for version 3.x buildsconst config: CapacitorConfig = { appId: 'com.example.app', appName: 'Example App', plugins: { CapacitorUpdater: { autoUpdate: 'atBackground', defaultChannel: 'v3', // Routes v3 users automatically } }};Passo 2: Crea canali
Sezione intitolata “Passo 2: Crea canali”# Create channels for each major versionnpx @capgo/cli channel add productionnpx @capgo/cli channel add v2npx @capgo/cli channel add v3
# Enable self-assignment so apps can switch channelsnpx @capgo/cli channel set production --self-assignnpx @capgo/cli channel set v2 --self-assignnpx @capgo/cli channel set v3 --self-assignPasso 3: Carica bundle specifici per versione
Sezione intitolata “Passo 3: Carica bundle specifici per versione”# For v1.x users (from v1-maintenance branch)git checkout v1-maintenancenpm run buildnpx @capgo/cli bundle upload --channel production
# For v2.x users (from v2-maintenance or main branch)git checkout mainnpm run buildnpx @capgo/cli bundle upload --channel v2
# For v3.x users (from beta/v3 branch)git checkout betanpm run buildnpx @capgo/cli bundle upload --channel v3Vantaggi
Sezione intitolata “Vantaggi”- Zero code modifiche - La routing del canale avviene automaticamente
- Separazione chiara - Ogni versione ha il proprio flusso di aggiornamento
- Targeting flessibile - Invia aggiornamenti a gruppi di versioni specifiche
- Rollout sicuro - Le modifiche breaking non raggiungono le versioni incompatibili
Strategia 2: Controlli di versioning semantico
Sezione intitolata “Strategia 2: Controlli di versioning semantico”Usa Capgo's funzionalità integrate controlli di versioning semantica per prevenire gli aggiornamenti oltre i confini delle versioni.
Disabilita Aggiornamento Automatico Tra Versioni Principali
Sezione intitolata “Disabilita Aggiornamento Automatico Tra Versioni Principali”# Create a channel that blocks major version updatesnpx @capgo/cli channel add stablenpx @capgo/cli channel set stable --disable-auto-update majorQuesta configurazione significa:
- Gli utenti con versione dell'app 1.2.3 riceveranno gli aggiornamenti fino a 1.9.9
- Utenti saranno NO ricezione della versione 2.0.0 automaticamente
- Preventa che i cambiamenti di base raggiungano le native più vecchie code
- La comparazione utilizza la linea di base nativa inviata come
version_build
Opzioni di controllo granulare
Sezione intitolata “Opzioni di controllo granulare”# Block target bundles outside the native major.minor line (1.2.x won't get 1.3.0)npx @capgo/cli channel set stable --disable-auto-update minor
# Block target bundles outside the exact native MAJOR.MINOR.PATCH core (1.2.3 won't get 1.2.4)npx @capgo/cli channel set stable --disable-auto-update patch
# Allow all updatesnpx @capgo/cli channel set stable --disable-auto-update noneStrategia 3: vincoli di versione nativa
Sezione intitolata “Strategia 3: vincoli di versione nativa”Specificare una versione minima di app nativa (min_update_version) su ogni bundle in modo che Capgo lo invii solo ai dispositivi con un binario nativo abbastanza nuovo.
Questo utilizza il canale ) più o--disable-auto-update metadata) plus --min-update-version or --auto-min-update-version on caricamento. Non c'è --native-version CLI flag.
Abilita la targeting dei metadati sul canale
Sottosezione intitolata “Abilita la targeting dei metadati sul canale”# one-time: require min_update_version metadata on uploads to this channelnpx @capgo/cli@latest channel set production --disable-auto-update metadataImposta una versione nativa minima all'upload
Sottosezione intitolata “Imposta una versione nativa minima all'upload”Quando si carica un bundle, passa la versione nativa più bassa che possa riceverlo:
# This bundle requires native version 2.0.0 or highernpx @capgo/cli@latest bundle upload \ --channel production \ --min-update-version "2.0.0"O lascia che Capgo stabilisca il tetto dalla compatibilità del pacchetto nativo:
npx @capgo/cli@latest bundle upload \ --channel production \ --auto-min-update-versiondettagli.
Sezioni intitolata “Casi d'uso”-
Sottosezione intitolata “Utilizzo”
Finestra del terminale # Bundle needs Camera plugin added in v2.0.0npx @capgo/cli@latest bundle upload \--channel production \--min-update-version "2.0.0" -
Modifiche native che rompono API
Finestra del terminale # Bundle uses new Capacitor 6 APIsnpx @capgo/cli@latest bundle upload \--channel production \--min-update-version "3.0.0" -
Migrazione graduale
Finestra del terminale # one-time: enable metadata gating on betanpx @capgo/cli@latest channel set beta --disable-auto-update metadata# Test bundle only on latest native versionnpx @capgo/cli@latest bundle upload \--channel beta \--min-update-version "2.5.0"
Strategia 4: Prevenzione del downgrade automatico
Sezione intitolata “Strategia 4: Prevenzione del downgrade automatico”Prevenire agli utenti di ricevere pacchetti più vecchi della loro versione nativa corrente.
Abilita nelle impostazioni dei canali
Sezione intitolata “Abilita nelle impostazioni del canale”Nella dashboard Capgo:
- Vai a Canali → Seleziona il tuo canale
- Enable “Disable auto downgrade under native”
- “Disabilita l'auto downgrade sotto nativo”
Ora tramite CLI:
npx @capgo/cli@latest channel set production --no-downgradeExample
Sezione intitolata “Esempio”- Dispositivo dell'utente: Versione nativa 1.2.5
- Bundle del canale: Versione 1.2.3
- Risultato: L'aggiornamento è bloccato (sarebbe una versione precedente)
Questo è utile quando:
- Gli utenti hanno installato manualmente una versione più recente dalla store delle app
- È necessario assicurarsi che gli utenti abbiano sempre le patch di sicurezza più recenti.
- Vuoi prevenire i bug di regressione
Schema 5: Targeting a livello di dispositivo
Sezione intitolata “Schema 5: Targeting a livello di dispositivo”Sovrascrivi l'assegnazione del canale per dispositivi o gruppi di utenti specifici.
Forzare Versione Specifica per Test
Sezione intitolata “Forzare Versione Specifica per Test”import { CapacitorUpdater } from '@capgo/capacitor-updater'
// Force beta testers to use v3 channelasync function assignBetaTesters() { const deviceId = await CapacitorUpdater.getDeviceId()
// Check if user is beta tester if (isBetaTester(userId)) { await CapacitorUpdater.setChannel({ channel: 'v3' }) }}Pannello di controllo Dispositivo Override
Sezione intitolata “Pannello di controllo Dispositivo Override”Nella Capgo dashboard:
- Vai a Dispositivi → Trova dispositivo
- Clicca Imposta canale o Imposta Versione
- Sostituisci con una versione specifica di canale o pacchetto
- Il dispositivo riceverà aggiornamenti dalla fonte sovrascritta
Flusso di lavoro completo AppFlow-Style
Sezione intitolata “Flusso di lavoro completo AppFlow-Style”Ecco un esempio completo che combina tutte le strategie:
1. Configurazione iniziale (App v1.0.0)
Sezione intitolata “1. Configurazione iniziale (App v1.0.0)”# Create production channel, then enable metadata min-version gatingnpx @capgo/cli@latest channel add productionnpx @capgo/cli@latest channel set production \ --disable-auto-update metadata \ --no-downgradeconst config: CapacitorConfig = { plugins: { CapacitorUpdater: { autoUpdate: 'atBackground', defaultChannel: 'production', } }};2. Rilascio Modifica Rilevante (App v2.0.0)
Sezione intitolata “2. Rilascio Modifica Rilevante (App v2.0.0)”# Create v2 channel for new versionnpx @capgo/cli@latest channel add v2npx @capgo/cli@latest channel set v2 \ --disable-auto-update metadata \ --no-downgrade \ --self-assign
# Create git branch for v1 maintenancegit checkout -b v1-maintenancegit push origin v1-maintenance// capacitor.config.ts for v2.0.0const config: CapacitorConfig = { plugins: { CapacitorUpdater: { autoUpdate: 'atBackground', defaultChannel: 'v2', // New users get v2 channel } }};3. Invia Aggiornamenti a Tutte le Versioni
Sezione intitolata “3. Invia Aggiornamenti a Tutte le Versioni”# Update v1.x users (bug fix)git checkout v1-maintenance# Make changesnpx @capgo/cli@latest bundle upload \ --channel production \ --min-update-version "1.0.0"
# Update v2.x users (new feature)git checkout main# Make changesnpx @capgo/cli@latest bundle upload \ --channel v2 \ --min-update-version "2.0.0"4. Monitora la distribuzione delle versioni
Sezione intitolata “4. Monitora la distribuzione delle versioni”Utilizza il Capgo dashboard per tracciare:
- Quanti utenti sono su v1 vs v2
- Tassi di adozione dei bundle per versione
- Errori o crash per versione
5. Deprecare la versione vecchia
Sezione intitolata “5. Deprecare la versione vecchia”Once v1 usage drops below threshold:
# Stop uploading to production channel# Optional: Delete v1 maintenance branchgit branch -d v1-maintenance
# Move all remaining users to default# (They'll need to update via app store)Precedenza del canale
Sezione intitolata “Precedenza del canale”Quando esistono più configurazioni di canale, Capgo utilizza questo ordine di precedenza:
- Override del dispositivo (Pannello di controllo o API) - Priorità più alta e visibile nell'interfaccia di Override del dispositivo
- Canale plugin locale via
setChannel()- Memorizzato sul dispositivo solo e non mostrato nell'interfaccia di Override del dispositivo - defaultChannel in capacitor.config.ts
- Canale predefinito (Impostazione Cloud) - Priorità più bassa
Pratiche Consigliate
Sezione intitolata “Pratiche Consigliate”1. Imposta sempre defaultChannel per le Versioni Principali
Sezione intitolata “1. Imposta sempre defaultChannel per le Versioni Principali”// ✅ Good: Each major version has explicit channel// v1.x → production// v2.x → v2// v3.x → v3
// ❌ Bad: Relying on dynamic channel switching// All versions → production, switch manually2. Utilizza la versione semantica
Sezione intitolata “2. Utilizza la versione semantica”# ✅ Good1.0.0 → 1.0.1 → 1.1.0 → 2.0.0
# ❌ Bad1.0 → 1.1 → 2 → 2.53. Mantieni rami separati
Sezione intitolata “3. Mantieni rami separati”# ✅ Good: Separate branches per major versionmain (v3.x)v2-maintenance (v2.x)v1-maintenance (v1.x)
# ❌ Bad: Single branch for all versions4. Testa prima della distribuzione
Sezione intitolata “4. Testa prima della distribuzione”# one-time: create beta and enable metadata gating# (production is set up in the complete workflow above)npx @capgo/cli@latest channel add betanpx @capgo/cli@latest channel set beta --disable-auto-update metadata
# Test on beta channel firstnpx @capgo/cli@latest bundle upload \ --channel beta \ --auto-min-update-version
# Monitor for issues, then promote to productionnpx @capgo/cli@latest bundle upload \ --channel production \ --auto-min-update-version5. Monitora la distribuzione delle versioni
Sezione intitolata “5. Monitora la distribuzione delle versioni”Controlla regolarmente la tua dashboard:
- Gli utenti stanno aggiornando a versioni native più recenti?
- Le vecchie versioni stanno ancora ricevendo un alto traffico?
- Dovresti deprecare i vecchi canali?
Confronto con Ionic AppFlow
Sezione intitolata “Confronto con Ionic AppFlow”Per le squadre che stanno migrando da Ionic AppFlowEcco come la Capgo gestisce la versione di destinazione.
| Feature | Ionic AppFlow | Capgo |
|---|---|---|
| Routing basato sulla versione | Routing automatico sulla versione nativa | Routing automatico via defaultChannel + strategie multiple |
| Versioning semantico | Sostegno base | Sostegno avanzato con --disable-auto-update (maggiore/minore/patch) |
| Restrizioni sulla versione nativa | Configurazione manuale nel pannello di controllo di AppFlow | Costruito in --min-update-version / --auto-min-update-version con canali di metadati |
| Gestione del canale | Interfaccia Web + CLI | Interfaccia Web + CLI + API |
| Override del dispositivo | Gestione del dispositivo a livello limitata | Controllo completo tramite Dashboard/API |
| Prevenzione della discesa automatica | Sì | Sì via --no-downgrade |
| Mantenimento di più versioni | Gestione manuale della branca/canale | Automatizzato con precedenza del canale |
| Auto-hosting | No | Sì (controllo completo) |
| Analisi delle versioni | Basi | Metriche dettagliate per versione |
Risoluzione Problemi
Sezione intitolata “Risoluzione Problemi”Utenti che non ricevono Aggiornamenti
Sezione intitolata “Utenti che non ricevono Aggiornamenti”Controlla i seguenti punti:
-
Assegnazione del Canale: Verifica che il dispositivo sia sul canale corretto
const channel = await CapacitorUpdater.getChannel()console.log('Current channel:', channel) -
Vincoli di Versione: Controlla se il pacchetto ha richieste di versione native
- Dashboard → Pacchetti → Controlla la colonna “Versione Nativa”
-
Impostazioni Semver: Verifica le impostazioni del canale
disable-auto-updateimpostazionefinestra del terminale npx @capgo/cli channel list -
Override dispositivo: Controlla se il dispositivo ha un override manuale
- Dashboard → Dispositivi → Cerca dispositivo → Verifica canale/versione
Bundle inviato alla versione sbagliata
Sottosezione intitolata “Bundle inviato alla versione sbagliata”- Recensisci defaultChannel: Assicurati di avere il canale corretto in
capacitor.config.ts - Verifica l'upload del pacchetto: Verifica che il pacchetto sia stato caricato sul canale inteso
- Ispeziona la versione minima dell'aggiornamento: Conferma
--min-update-version(o--auto-min-update-version: era impostato e il canale utilizza--disable-auto-update metadata
Modifiche Rilevanti che Affectano Versioni Antiche
Sezione intitolata “Modifiche Rilevanti che Affectano Versioni Antiche”- Soluzione immediata: Sovrascrivi dispositivi affetti con pacchetto sicuro
- Dashboard → Dispositivi → Selezione di massa → Imposta Versione
- Soluzione a lungo termineCreare canali versionati e mantenere rami separati
- PrevenzioneTestare sempre gli aggiornamenti su dispositivi rappresentativi prima della distribuzione
Migrazione da Ionic AppFlow
Sottosezione intitolata “Migrazione da Ionic AppFlow”Se stai migrando da Ionic AppFlowLa versione targeting funziona in modo molto simile a Capgo, con maggiore flessibilità:
Carta concettuale
Sottosezione intitolata “Carta concettuale”| AppFlow Concept | Corrispettivo di Capgo | Note |
|---|---|---|
| Canale di distribuzione | Capgo Canale | Lo stesso concetto, ma più potente |
| Versione nativa bloccata | --min-update-version / --auto-min-update-version | Possibilità di controllo più granulare |
| Priorità del canale | Precedenza del canale (override → cloud → default) | Precedenza più trasparente |
| Obiettivo di distribuzione | Canale + controlli semver | Sono disponibili diverse strategie |
| Canale di Produzione | production nome del canale (o qualsiasi altro nome) | Nominazione flessibile |
| Deploy con Git | Caricamento del pacchetto CLI dalla branca | Lo stesso workflow |
| Corrispondenza di versione automatica | defaultChannel + vincoli di versione | Rafforzato con strategie multiple |
Differenze chiave per gli utenti di AppFlow
Sottosezione intitolata “Differenze chiave per gli utenti di AppFlow”- Piu Controllo: Capgo offre diverse strategie (canali, semver, versione nativa) che possono essere combinate
- Visibilità MigliorataLa dashboard mostra la distribuzione delle versioni e gli eventuali problemi di compatibilità
- API Accesso: Controllo programmatico completo sulla versione di destinazione
- Auto-Hosting: Opzione per eseguire il proprio server di aggiornamento con la stessa logica di versione
Passaggi di Migrazione
: Sezione intitolata “Passaggi di Migrazione”- Mappa i canali AppFlow ai canali Capgo (di solito 1:1)
- Set
defaultChannelIniziacapacitor.config.tsper ogni versione maggiore - Configura le regole semver Se desideri il blocco automatico ai confini delle versioni
- Carica bundle specifici per versione utilizzando
--min-update-version(il canale deve utilizzare la strategia di metadati) - Monitora la distribuzione delle versioni in dashboard Capgo
Modelli avanzati
Sottosezione intitolata “Modelli avanzati”Esecuzione graduale di una versione
Sottosezione intitolata “Esecuzione graduale di una versione”// Gradually migrate v1 users to v2async function migrateUsers() { const deviceId = await CapacitorUpdater.getDeviceId() const rolloutPercentage = 10 // Start with 10%
// Hash device ID to get deterministic percentage const hash = hashCode(deviceId) % 100
if (hash < rolloutPercentage) { // User is in rollout group - migrate to v2 await CapacitorUpdater.setChannel({ channel: 'v2' }) }}Flag di feature per versione
Sottosezione intitolata “Flag di feature per versione”// Enable features based on native versionasync function checkFeatureAvailability() { const info = await CapacitorUpdater.getDeviceId() const nativeVersion = info.nativeVersion
if (compareVersions(nativeVersion, '2.0.0') >= 0) { // Enable features requiring v2.0.0+ enableNewCameraFeature() }}Test A/B tra versioni
Sottosezione intitolata “Test A/B tra versioni”// Run A/B tests within same native versionasync function assignABTest() { const nativeVersion = await getNativeVersion()
if (nativeVersion.startsWith('2.')) { // Only A/B test on v2 users const variant = Math.random() < 0.5 ? 'v2-test-a' : 'v2-test-b' await CapacitorUpdater.setChannel({ channel: variant }) }}Capgo offre diverse strategie per la consegna di aggiornamenti specifici per versione:
- Routing per canale: Separazione automatica della versione tramite
defaultChannel - Versionamento semantico: Prevenire gli aggiornamenti tra confini di versione maggiore/minore/patch
- Restrizioni native di versione: Richiedere la versione minima nativa per i pacchetti
- Prevenzione del downgrade automatico: Mai consegnare pacchetti più vecchi alle versioni native più nuove
- Override dispositivo: Controllo manuale per test e targeting
Combinando queste strategie, puoi raggiungere la consegna di aggiornamenti automatici con AppFlow con ancora più flessibilità e controllo. Scegli l'approccio che meglio si adatta al flusso di versioning e di distribuzione del tuo app.
Per ulteriori informazioni sui dettagli specifici:
- Guida alle modifiche significative - Strategia dettagliata di versioning dei canali
- Gestione dei canali - Riferimento completo di configurazione dei canali
- Comportamento degli aggiornamenti - Ritardi e condizioni native di versione
Continua da qui: Version Targeting
Sezione intitolata “Continua da Version Targeting”Se stai utilizzando Target Versionamento per pianificare la routing del canale e la distribuzione in fasi, connettilo con Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Soluzione di Test di Beta per il workflow del prodotto in Soluzione di Test di Beta, e Soluzione di Targeting della Versione per il workflow del prodotto in Soluzione di Targeting della Versione.