Native + Flusso di lavoro del canale OTA

Un setup comune Capgo utilizza un canale di sviluppo canale di produzione canale di produzione canale. Il CI carica ogni bundle OTA su devpoi promuove su production quando sei pronto. Le squadre aggiungono spesso --fail-on-incompatible così che il CI non possa inviare un aggiornamento live che richiede nuovi pacchetti nativi code per errore.

Questa pagina risponde alla domanda di seguito: cosa fai quando tu intenzionalmente hai bisogno di un bundle che non è compatibile con i pacchetti nativi attuali del canale?

Se hai bisogno del contesto sul perché Capgo confronta i pacchetti nativi, inizia con Compatibilità Nativa. Per una branca CI completa che sceglie OTA vs Capgo Build automaticamente, vedi Auto OTA o Nativa.

Disegno di canale raccomandato

Questa guida assume che il dev e production i canali esistano già. Crea prima se necessario:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

Canale	Chi lo riceve	Caricamento tipico
dev	Costruzioni interne / QA	Ogni push CI di JS (e basi native intenzionali)
production	Utenti del negozio	Promosso o caricato solo quando pronto per la release

--fail-on-incompatible è una buona impostazione per entrambi i canali per ogni giorno OTA caricamenti. Si confrontano i pacchetti nativi nel bundle che stai caricando contro il bundle attualmente live su quel canale. Se differiscono, l'upload esce con un codice di uscita non zero e nulla viene spedito.

Ogni giorno OTA (mantieni la bandiera)

Quando la modifica è solo JavaScript e i pacchetti nativi corrispondono al canale:

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible evita il drift nativo accidentale. --auto-min-update-version è richiesto per ogni caricamento dopo che il canale utilizza il metadata la strategia (consigliata di seguito). Se il canale non è ancora attivo, puoi omettere metadata finché non cambi. --auto-min-update-version Porta facoltativa prima del caricamento:

Finestra del terminale

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

Sezione intitolata “Aumento nativo intenzionale (elimina la bandiera una volta)”

potresti Non puoi caricare un bundle che richiede una nuova code nativa mentre mantiene --fail-on-incompatibleQuel flag esiste per bloccare proprio quel caso. Quando un plugin, Capacitor versione o altra dipendenza nativa è stata modificata di proposito:

1. Invia il matching binario nativo (App Store / Play Store, o Capgo Build).
2. Carica il matching JS bundle senza --fail-on-incompatible.
3. Preferisci --auto-min-update-version con il canale sul metadata strategia in modo che i dispositivi ancora sul vecchio binario non ricevano il nuovo bundle fino a quando non installano la nuova app.
4. Dopo quell'upload di base, metti --fail-on-incompatible tornare su OTA CI normale (e mantenere --auto-min-update-version mentre il canale rimane su metadata).

1. Una volta per canale: abilitare la gating dei metadati

   npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

   Ripetere per dev se quel canale riceve anche basi native intenzionali. Dopo questo cambio, ogni upload al canale deve includere --auto-min-update-version o --min-update-version.

2. o

   Invia il binario nativo

3. Costruisci e invia l'app iOS/Android che include i nuovi plugin o le modifiche native. Fino a quando gli utenti non installano quel binario, non possono eseguire in modo sicuro un pacchetto che dipende da quei pacchetti nativi. --fail-on-incompatible)

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --auto-min-update-version

   Questo registra i nuovi pacchetti nativi sul canale. In seguito bundle releaseType / --fail-on-incompatible controlla che punto di riferimento.

4. Riprendi le pubblicazioni OTA protette

   Le successive rilasci solo JS utilizzano entrambi i flag di nuovo:

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --fail-on-incompatible \
     --auto-min-update-version

Suggerimento

Tratta l'upload del baseline nativo come un lavoro di CI dedicato (o un passaggio di rilascio manuale), non come un'eccezione che sprighi nel lavoro OTA di default. Il lavoro di default dovrebbe sempre mantenere --fail-on-incompatiblee, e metadata il canale dovrebbe mantenere anche --auto-min-update-version.

Domande frequenti

Sottotitolo della sezione intitolata "Domande frequenti" --fail-on-incompatible Posso mantenere

Sottotitolo della sezione intitolata "Posso mantenere --fail-on-incompatible e comunque inviare un pacchetto non compatibile nativo?" --auto-min-update-version No. Se i pacchetti nativi dell'upload differiscono dal pacchetto live del canale, la flag fallisce il comando di proposito. Per un aumento nativo intenzionale, omettere la flag su quell'upload (e utilizzare

quando puoi).

Sottotitolo della sezione intitolata "È una procedura di upload unico senza la flag la soluzione giusta?"

Se devo caricare su dev prima, poi production?

Sì, se corrisponde al tuo processo. Esegui le stesse regole per canale: il controllo di compatibilità è contro ciò che è live sul canale di destinazione. Promuovi o ricarica su production solo dopo dev sembra bene, e utilizza un caricamento di baseline nativa (senza --fail-on-incompatible) su ogni canale che richiede i nuovi pacchetti nativi registrati.

Cosa succede se carico il nuovo pacchetto nativo con la flag ancora attiva?

La CI fallisce e Capgo non invia quel caricamento. Quello è l'esito previsto. O il cambiamento era accidentale (correggi i pacchetti nativi e riprova come OTA), o era intenzionale (utilizza la via nativa sopra).

Quale flag va associata a quale job?

Percorso	Quando	Carica le flag
OTA	Solo JS; i pacchetti nativi corrispondono al canale	--fail-on-incompatible + --auto-min-update-version (obbligatorio se il canale è su metadata)
Baseline nativa	Nuovo binario nativo + bundle JS corrispondente	No --fail-on-incompatible; conserva --auto-min-update-version

Collegamenti

Compatibilità nativa

Come Capgo rileva la deriva dei pacchetti nativi e cosa significa incompatibilità per i dispositivi.

Auto OTA o Nativa

Cavo bundle releaseType in GitHub Azioni o GitLab affinché il CI sceglie la strada giusta.

Target di versione

context

CLI: bundle

__CAPGO_KEEP_0__: bundle

Riferimento per l'upload, la compatibilità, releaseType e le relative flag.

Se stai utilizzando Native + Flusso di lavoro OTA per mantenere aggiornate le live updates in modo sicuro attraverso le rilasci native, collega il Compatibilità Nativa per le regole di confronto dei pacchetti, Auto OTA o Nativa per la gestione delle branch di CI, Target di Versione context Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ riferimento del pacchetto bundle