Flusso di lavoro del canale Native + OTA

Un setup comune Capgo utilizza un dev canale di produzione production CI carica ogni bundle OTA su devpoi promuove a production quando siete pronti. Le squadre aggiungono spesso --fail-on-incompatible così il CI non può distribuire un live update che richiede nuovi pacchetti nativi code per errore.

Questa pagina risponde alla domanda di seguito: what do you do when you intenzionalmente avete bisogno di un bundle che è incompatibile con i pacchetti nativi attuali del canale?

Se avete bisogno del contesto sul perché Capgo confronta i pacchetti nativi, iniziate con Pacchetti nativi. Per una branca CI completa che sceglie OTA vs Capgo Build automaticamente, vedere Auto OTA o Pacchetti nativi.

Disegno raccomandato del canale

Questa guida presuppone che dev e production canali già esistono. Crea prima quelli necessari se necessario:

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

Chi lo riceve	Caricamento tipico	Build interni / QA
dev	Costruzioni interne / QA	Ogni push CI di JS (e basi native intenzionali)
production	Store users	Pubblicato o caricato solo quando pronto per la release

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

Ogni giorno OTA (mantieni la flag)

Quando il cambiamento è esclusivamente 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 prevenendo accidentalmente la deriva nativa. --auto-min-update-version è richiesta per ogni upload una volta che il canale utilizza il metadata strategia (consigliata di seguito). Se il canale non è abilitato metadata ancora, puoi omettere --auto-min-update-version finché non cambi.

Opzionale CI gate prima dell'upload:

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)

Aggiornamento nativo intenzionale (elimina la flag una volta)

Non puoi cannot caricare un bundle che richiede nuove code native mentre mantenendo --fail-on-incompatibleQuella bandiera esiste proprio per bloccare quel caso. Quando un plugin, la versione Capacitor, o un'altra dipendenza nativa è stata modificata di proposito:

1. Conseguiamo il binario corrispondente binario nativo (App Store / Play Store, o Capgo Costruzione).
2. Carica il bundle JS corrispondente without --fail-on-incompatible.
3. senza --auto-min-update-version con il canale attivo metadata tattica per cui i dispositivi ancora con la versione binaria vecchia non ricevono il nuovo pacchetto fino a quando non installano la nuova app.
4. Dopo quella caricata di base, inserisci --fail-on-incompatible Dopo quella caricamento di base, ripristiniamo --auto-min-update-version su OTA CI normale (e manteniamo 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

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

2. Invia il binario nativo

   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

3. Carica il baseline OTA corrispondente (senza --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 utilizzano quella base di riferimento.

4. Riprendi le upload OTA protette

   Rilasci JS-only successivi utilizzano entrambi i flag nuovamente:

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

Tip

Tratta l'upload di baseline nativa 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-incompatible, e su un metadata canale dovrebbe anche mantenere --auto-min-update-version.

FAQ

Puo mantenere --fail-on-incompatible e potrà comunque inviare un pacchetto nativo incompatibile?

No. Se i pacchetti nativi dell'upload differiscono dal pacchetto live del canale, il flag fallisce il comando di proposito. Per un aumento nativo intenzionale, omettere il flag in quell'upload (e utilizzare --auto-min-update-version quando puoi).

È corretto procedere con un upload senza il flag una sola volta?

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

Devo caricare dev prima, quindi 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 buono, 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?

La CI fallisce e Capgo non invia quel caricamento. È 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 applicato a quale job?

Percorso	Quando	Bandiera di caricamento
OTA	Solo JS; pacchetti nativi corrispondono al canale	--fail-on-incompatible + --auto-min-update-version Obbligatorio se il canale è su metadata)
Punto di riferimento nativo	Nuovo binario nativo + bundle JS corrispondente	No --fail-on-incompatible; conserva --auto-min-update-version

Relativo

Compatibilità nativa

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

Auto OTA o Nativo

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

Target di Versione

Canali, regole semver e strategia dei metadati per le aree di consegna.

CLI: pacchetto

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

Continua dal Flusso di Lavoro del Canale Nativo + OTA

Se stai utilizzando Flusso di canale nativo + OTA per mantenere le aggiornamenti live sicuri attraverso le rilasci native, connettilo con Compatibilità nativa per le regole di confronto del pacchetto, Auto OTA o Nativo per la branching di CI, Target di versione per i piani di metadati Capgo CLI riferimento del pacchetto __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ riferimento del pacchetto