Lista de verificación de configuración única

Copie un prompt de configuración con los pasos de instalación y la guía de markdown completa para este plugin.

Ha terminado de configuraciónAhora configure Capgo una vez. Después de eso, el trabajo diario es solo subir → probar → desplegar.

Regla: los canales son rama de lanzamiento (development, production), no tickets, características o nombres de desarrolladores.

Lista de comprobación de configuración única

Crear canales: elija el conjunto más pequeño que se adapte (ver abajo).
Establecer canal de carga predeterminado en Configuración de la aplicación:
- Solo aplicación → production
- Equipo → development
Canales de producción: Enciende público, apaga dispositivo, bloquea actualizaciones nativas, activa guardia de actualización automática major.
Canales de prueba (development / staging) encendido público, dispositivo autoencendido para pruebas.
Subir desde CI con --delta (checksum y dependencias nativas son automáticas):
Copiar a portapapeles
```
npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta
```
El --bundle debe ser una versión semántica válida. Validate it in the Validarlo en el tester de SemVer
antes de subirlo. Despliegue a producción dashboard o CLI.
Equipo y seguridad: invitar una vez, menos permisos 2FA para la organización, una clave API en CI.

Dejar la cifrado, min_update_version, metadatos y vista previa apagado a menos que tenga una razón clara.

Elige tu tamaño

Sencillo: 1 aplicación, 1 canal: production

Equipo: development + production. Cargar en dev, desplegar en prod.

Versiones nativasAgregar canales solo cuando sea necesario, por ejemplo. production-9.0 + test-9.0Mantenga a los usuarios del almacén en el canal principal de producción.

Many apps: mismo modelo simple por aplicación (usualmente uno production each). No crear canales adicionales solo porque la organización es grande.

Tren de lanzamiento (opcional): staging → rc → production. Mismo template en cada aplicación que lo necesite.

Nombre de paquete vs comentario

Los nombres de paquetes son obligatorios para seguir la versión semántica.Capgo utiliza semver para comprobaciones de compatibilidad, reglas de actualización automática de canal y retrocesos. Verifique cada nombre en el Prueba de SemVer antes de subir.

Nombre = semver desde CI, por ejemplo. 1.8.0, 1.8.0-beta.1, o 1.8.0-20260629.42
Comentario = texto libre para humanos → commit abc1234 run 28059070270

Usar semver pre-release ) cuando envíes muchos builds bajo el mismo -) cuando envíes muchos builds bajo el mismo MAJOR.MINOR.PATCHPor ejemplo, mantenga 1.8.0 y agregar la fecha o contador de compilación en la versión de prueba: 1.8.0-20260629.1, 1.8.0-beta.2No inventes formatos personalizados como. fix-login-bug or 2.5.2026062306no son válidos semver y las subidas fallarán o comportarse de manera impredecible.

Coloque notas de lanzamiento en --comment, no en el nombre del paquete.

Ver también versión de destino y contexto de versión del paquete.

subida delta

--delta subidas archivos delta de esta manera los dispositivos descargan solo los archivos modificados en lugar de descargar el paquete completo cada vez. El checksum se calcula automáticamente siempre. No pasa una bandera de checksum.

Predeterminado: `--delta` (archivos delta + copia de seguridad en zip)

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --delta

This is the recommended default for most apps. Capgo stores the delta files y keeps the full zip as a backup. Devices on an old plugin version without Delta support use the zip. Good when storage cost is not your main concern.

Ahorro de almacenamiento: `--delta-only`

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta-only

Usar --delta-only cuando desees reducir el almacenamiento de Capgo .Solo se almacenan los archivos delta, no el zip completo. Elija esta opción para aplicaciones grandes o un alto volumen de subida donde el almacenamiento suma.

Compromiso: sin el respaldo del archivo zip en el servidor, dependes completamente de los archivos delta, y los dispositivos con una versión antigua del plugin sin soporte para Delta no pueden actualizar. Saltar --delta-only a menos que realmente necesites las ahorras de almacenamiento.

No se requiere ninguna configuración adicional del plugin en el dispositivo. El actualizador lee la lista de archivos delta y descarga solo los archivos modificados.

Flujo de trabajo diario

Upload to development (--delta)
  → test
  → deploy to production
  → don't touch channel settings again

Errores comunes

Error	Solución
Expecting OTA before a new store release	Reconstruir y enviar la aplicación nativa después de agregar el plugin
Subir un paquete pero no desplegarlo en un canal	Asignar el paquete a un canal (por ejemplo `production`)
Canales por característica, boletín, o desarrollador	Utilice solo carriles de liberación permanentes
Nombres de canales CI dinámicos	Nombres fijos: `development`, `production`
Demasiados canales para una aplicación simple	Comience con 1-2 canales
Dispositivo autoconfigurado en producción	Apagado para producción, encendido para canales de prueba
Saltar `--delta`	Agregar `--delta` para subidas; utilice `--delta-only` solo cuando necesite ahorrar almacenamiento
Nombres de paquetes no semver	Sigue y valida en el prueba de SemVer SemVer tester
Cambiar esquema de versionado con el tiempo	Keep semver; use pre-release labels for extra builds (`1.8.0-20260629.1`)
Metadata / vista previa habilitada sin motivo	Más información

Aprende más

Aprende más Preferencias, precedencia y enrutamiento.

Actualizaciones delta ¿Por qué y cómo usar --delta.

CI/CD Automatizar subida y despliegue.

Paquetes Checksum, dependencias y metadatos.