Flusso di lavoro di Native + Canale OTA

Un setup comune Capgo utilizza un canale di sviluppo canale di produzione canale di produzione canale. Le CI caricano ogni bundle OTA in devpoi lo promuovono a production quando sei pronto. Le squadre aggiungono spesso --fail-on-incompatible così che la 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 è incompatibile con i pacchetti nativi del canale corrente?

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 esistono 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 dello store	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 canaleSe differiscono, l'upload esce con codice di uscita non zero e nulla viene spedito.

Ogni giorno OTA (mantieni la flag)

Quando il cambiamento è 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 blocca la deriva nativa accidentale. --auto-min-update-version è richiesto per ogni caricamento dopo che il canale utilizza la metadata strategia (consigliata di seguito). Se il canale non è ancora attivo, puoi omettere metadata fino a quando non cambi. --auto-min-update-version Porta facoltativa di CI 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 “Sollevamento nativo intenzionale (elimina la bandiera una volta)”

definire il significato di 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 bundle JS senza --fail-on-incompatible.
3. Preferisci --auto-min-update-version con il canale sul metadata strategy in modo che i dispositivi ancora sul vecchio binario non ricevano il nuovo bundle fino a quando non installano la nuova app.
4. Dopo quella caricata 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 anche quel canale riceve 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 bundle 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 le verifiche utilizzano quel 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 spruzzate nel lavoro OTA di default. Il lavoro di default dovrebbe sempre mantenere --fail-on-incompatible, e su un metadata il canale dovrebbe anche mantenere --auto-min-update-version.

Domande frequenti

Posso mantenere --fail-on-incompatible e comunque inviare un pacchetto non compatibile nativo?

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 --auto-min-update-version quando puoi).

È una procedura di upload unico senza la flag la soluzione giusta?

Sì. Quello è il modo supportato per avanzare la base nativa del canale dopo aver spedito un nuovo binario. Mantenere la flag su ogni altro upload OTA per far fallire CI anche il drift nativo accidentale.

Devo caricare su dev in primo luogo, poi production?

Sì, se corrisponde al tuo processo. Esegui le stesse regole per canale: il controllo di compatibilità è contro ciò che è attualmente disponibile sul canale di destinazione. Promuovi o ricarica su production solo dopo dev sembra tutto a posto, 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 bundle nativo con la flag ancora attiva?

Il CI fallisce e Capgo non invia quel caricamento. Questo è l'esito atteso. 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 Richiesto se il canale è abilitato metadata)
Punto di riferimento nativo	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 per i dispositivi incompatibili.

Auto OTA o Nativa

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

Target di versione

contexto: Pagina/area: Pagina di marketing delle soluzioni Capgo. Ruolo: Intestazione di sezione o pagina. Visualizzato in: pagina soluzioni/version-targeting.astro. Chiave di messaggio `solutions_version_targeting_title` (Titolo delle soluzioni per la versione). | Pagina/area: Pagina di marketing delle soluzioni Capgo. Ruolo: Etichetta di UI breve o elemento di navigazione. Visualizzato in: pagina soluzioni/version-targeting.astro. Chiave di messaggio `solutions_version_targeting` (Soluzioni per la versione).

CLI: bundle

__CAPGO_KEEP_0__: bundle

Riferimento per l'upload, la compatibilità, il tipo di rilascio e le relative bandiere.

Se stai utilizzando Native + OTA Channel Workflow per mantenere aggiornate le live updates attraverso le rilasci native, collega Native Compatibility per le regole di confronto dei pacchetti Auto OTA o Native per la gestione delle branch di CI Versione di destinazione context: Pagina/area: Pagina di marketing delle soluzioni Capgo. Ruolo: Intestazione di sezione o pagina. Visualizzato in: pagina soluzioni/version-targeting.astro. Chiave di messaggio `solutions_version_targeting_title` (Titolo delle soluzioni di versione). | Pagina/area: Pagina di marketing delle soluzioni Capgo. Ruolo: Etichetta di navigazione breve o elemento UI. Visualizzato in: pagina soluzioni/version-targeting.astro. Chiave di messaggio `solutions_version_targeting` (Soluzioni di versione targeting) Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ riferimento del pacchetto di bundle