Native + Flusso di lavoro di canale OTA

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

Questa pagina risponde alla domanda di seguito: cosa fare quando tu intenzionalmente hai bisogno di un bundle che è incompatibile 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 dev e production Canali già esistenti. 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 in linea su quel canale. Se differiscono, l'upload esce con codice di uscita non zero e nulla viene spedito.

Ogni giorno OTA (mantieni la bandiera)

Quando la modifica è 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 blocca il drift nativo accidentale. --auto-min-update-version è richiesto per ogni upload dopo che il canale utilizza la metadata la strategia (consigliata di seguito). Se il canale non è ancora stato configurato, puoi omettere metadata finché non lo attiverai. --auto-min-update-version Porta facoltativa prima dell'upload:

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)

Sottosezione intitolata “Aggiornamento nativo intenzionale (elimina la flag una volta)”

tu context: frammento di testo HTML da una stringa di Capgo UI più lunga (chiave padre `you_definition`). Pagina/area: Sito web di marketing di Capgo. Ruolo: Paragrafo di marketing o legale lungo. Visualizzato in: pagina disclaimer.astro, pagina return.astro. Chiave di messaggio `you_definition` (Definizione di Tu). 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 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 quel caricamento 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 controlli utilizzano tale baseline.

4. Riprendi le salite protette OTA

   Rilasci JS-only successivi 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 di baseline nativa come un lavoro di CI dedicato (o un passo 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 il canale dovrebbe anche mantenere --auto-min-update-version.

Domande frequenti

Posso mantenere --fail-on-incompatible e comunque inviare un pacchetto non compatibile con la nativa?

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 fallire CI in caso di deriva nativa accidentale.

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 è in vita 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 bundle 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 su 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)
Basis nativa	Nuovo binario nativo + bundle JS corrispondente	No --fail-on-incompatible; conserva --auto-min-update-version

Relazioni

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 in modo che CI sceglie la strada giusta.

Target di Versione

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

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 il branching del CI Versione di destinazione per i pavimenti di metadati, e il Capgo CLI riferimento del pacchetto per le bandiere di upload