Flujo de trabajo de canal nativo + OTA

Una configuración común de Capgo utiliza un dev canal y un production El CI sube cada paquete OTA a dev, luego promueve a production cuando estés listo. Los equipos suelen agregar --fail-on-incompatible No puede que el CI envíe un live update que requiere nuevos code nativos por error.

Esta página responde a la siguiente pregunta: ¿Qué haces cuando tú intencionalmente necesitas un paquete que es incompatible con los paquetes nativos del canal actual?

Si necesitas la información de fondo sobre por qué Capgo compara paquetes nativos, comienza con Compatibilidad nativa. Para una rama de CI completa que elija OTA vs Capgo Build automáticamente, vea Auto OTA o Nativo.

Diseño recomendado del canal

Esta guía asume que dev y production canales ya existen. Crea primero si es necesario:

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

Canal	¿Quién lo obtiene	¿Quién lo obtiene
dev	Ediciones internas / de pruebas	Cada empuje de CI de JS (y baselines nativas intencionales)
production	Store users	Solo promocionado o subido cuando esté listo para su lanzamiento

--fail-on-incompatible es un buen valor por defecto en ambos canales para actualizaciones diarias de OTAsubidas de OTA diarias. Compara los paquetes nativos en el paquete que estás subiendo contra el paquete actualmente vivo en ese canal. Si difieren, la carga se sale con cero y nada se envía.

Actualización OTA diaria (mantén la bandera)

Cuando el cambio es solo JavaScript y los paquetes nativos coinciden con el canal:

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

--fail-on-incompatible evita el desplazamiento nativo accidental. --auto-min-update-version es necesario en cada carga una vez que el canal utilice la metadata estrategia (recomendada a continuación). Si el canal no está en metadata todavía, puedes omitir --auto-min-update-version hasta que cambies.

Opcional puente de CI antes de subir:

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)

Empujón nativo intencional (elimina la bandera una vez)

Usted cannot subir un paquete que necesita una nueva code nativa mientras se mantiene --fail-on-incompatibleEsa bandera existe para bloquear exactamente ese caso. Cuando un plugin, la versión Capacitor, o otra dependencia nativa cambia a propósito:

1. Envíe la correspondiente Envíe el binario nativo correspondiente (App Store / Tienda de aplicaciones, o) Capgo Construcción).
2. Subir el paquete JS correspondiente sin --fail-on-incompatible.
3. Preferir --auto-min-update-version con el canal en la metadata estrategia para que los dispositivos que aún están en la versión antigua no reciban el nuevo paquete hasta que instalen la nueva aplicación.
4. Después de ese subida de base, poner --fail-on-incompatible de nuevo en CI OTA normal (y mantener --auto-min-update-version mientras el canal sigue en metadata).

1. Una vez por canal: habilitar la mediateca de control

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

   Repetir para dev si ese canal también recibe baselines nativas intencionales. Después de este cambio, cada carga en el canal debe incluir --auto-min-update-version o --min-update-version.

2. Envíe el binario nativo

   Build and submit the iOS/Android app that includes the new plugins or native changes. Until users install that binary, they cannot safely run a bundle that depends on those native packages.

3. Upload the matching OTA baseline (no --fail-on-incompatible)

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

   Este registra los nuevos paquetes nativos en el canal. Más tarde bundle releaseType / --fail-on-incompatible verifica que utilice esa referencia base.

4. comprobaciones utilizan esa base.

   Reanude subidas de actualizaciones OTA protegidas

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

Consejo

Trate la carga de base nativa como un trabajo de CI dedicado (nota: no como excepción que agregas a la tarea de actualización por defecto. La tarea por defecto siempre debe mantener) --fail-on-incompatible, y en un metadata canal también debe mantener --auto-min-update-version.

FAQ

Puedo mantener --fail-on-incompatible y seguir empujando un paquete incompatible nativamente?

No. Si los paquetes nativos del archivo subido difieren de la versión en vivo del canal, la bandera hace fallar el comando a propósito. Para un aumento de la plataforma nativa intencional, omita la bandera en ese archivo de subida (y utilice --auto-min-update-version cuando puedas).

¿Es un subida única sin la bandera la aproximación correcta?

Yes. That is the supported way to advance the channel’s native baseline after you ship a new binary. Keep the flag on every other OTA upload so accidental native drift still fails CI.

primero, luego dev primero, luego production?

Sí, si eso coincide con tu proceso. Ejecuta las mismas reglas por canal: la comprobación de compatibilidad es contra lo que está vivo en el canal objetivo. Promueve o re-sube a production sólo después de dev mira bien, y utiliza una carga nativa de base (sin --fail-on-incompatible) en cada canal que necesita los nuevos paquetes nativos registrados.

¿Qué pasa si subo el nuevo paquete nativo con la bandera todavía activa?

La CI falla y Capgo no envía esa carga. Eso es el resultado esperado. O el cambio fue accidental (corrige los paquetes nativos y vuelve a intentarlo como OTA), o fue intencional (usa el camino nativo anterior).

¿Cuál bandera va en qué trabajo?

Ruta	Cuándo	Banderas de carga
OTA	JS solo; paquetes nativos coinciden con el canal	--fail-on-incompatible + --auto-min-update-version (requerido si el canal está en metadata)
Base nativa	Nueva binaria nativa + paquete de JS coincidente	No --fail-on-incompatible; mantener --auto-min-update-version

Relacionado

Compatibilidad nativa

Cómo Capgo detecta el desplazamiento de paquetes nativos y qué significa incompatible para dispositivos.

Auto OTA o Nativa

Wire bundle releaseType encaja en GitHub Acciones o GitLab para que CI elija el camino correcto.

Versión de destino

Canales, reglas de semver y la estrategia de metadatos para piso de entrega.

CLI: paquete

Referencia para subir, compatibilidad, tipo de lanzamiento y banderas relacionadas.

Sigue adelante desde el flujo de trabajo de canal nativo + OTA

Si estás utilizando Flujo de trabajo de canal nativo + OTA to keep live updates safe across native releases, connect it with Compatibilidad nativa para las reglas de comparación de paquetes, Auto OTA o Nativa para la rama de CI, Objetivo de Versión para los suelos de metadatos, y el Capgo CLI referencia de paquete __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ referencia del paquete