Lista de verificación de configuración única

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

Has terminado onboarding. Ahora configura Capgo una vez. Después de eso, el trabajo diario es solo subir → probar → desplegar.

Rule: canales son rutas de lanzamiento ("development, productionno boletos, características o nombres de desarrolladores.

Lista de verificación de configuración única.

Crear canales.Elige el conjunto más pequeño que se adapte (ver abajo).
Establecer el canal de carga predeterminado. in configuración de la aplicación:
- App → Solo production
- Equipo → development
Canal de producción: public on, device self-set off, block updates under native on, auto-update guard on major.
Canal de prueba (development / staging): público apagado, dispositivo autoconfigurado para pruebas.
Subir desde CI context --delta (checksum y dependencias nativas son automáticas):
ventana de terminal
```
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
```
The --bundle value context ser válido versionamiento semántico. Verifica antes de subir. SemVer tester antes de subir.
Despliega a producción solo después de probar, desde la dashboard o CLI.
Equipo y seguridad: invita una vez, con permisos mínimos 2FA para la organización, una clave API en CI.

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

Elige tu tamaño

Simple: 1 aplicación, 1 canal: production

Equipo: development + productionCargar a dev, desplegar a prod.

Versiones nativasAgregar canales solo cuando sea necesario, por ejemplo. production-9.0 + test-9.0: agregar canales solo cuando sea necesario, por ejemplo.

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

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

Nombre del paquete vs comentario

Los nombres de los paquetes son obligatorio de seguir versión semántica.Capgo utiliza semver para comprobaciones de compatibilidad, reglas de actualización automática de canal y retrocesos. Valida 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 etiquetas (la parte después de -) cuando envíes muchos builds bajo el mismo MAJOR.MINOR.PATCH. Por ejemplo, mantén 1.8.0 y agrega la fecha o contador de compilación en la versión de lanzamiento: 1.8.0-20260629.1, 1.8.0-beta.2. No inventes formatos personalizados como fix-login-bug o 2.5.2026062306No son válidos semver y las subidas fallarán o comportarse de manera impredecible.

Coloque notas de lanzamiento en --commentColoca notas de lanzamiento en

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

subida de Delta

--delta subidas archivos de Delta de esta manera, los dispositivos descargan solo los archivos modificados en lugar de la versión completa del paquete cada vez. El checksum se calcula automáticamente siempre. No se pasa un flag de checksum.

Predeterminado: `--delta` (delta archivos + 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 deseas reducir __CAPGO_KEEP_0__ almacenamiento reducir el almacenamiento CapgoSolo 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.

Trade-off: without the zip backup on the server, you rely fully on delta files, and devices on an old plugin version without Delta support cannot update. Skip --delta-only a menos que realmente necesites ahorro de almacenamiento.

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

comportamiento.

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

Copiar al portapapeles

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`)
Canal por característica, ticket o desarrollador	Usar solo vías de liberación permanentes
Nombres de canales de CI dinámicos	Nombres fijos: `development`, `production`
Demasiados canales para una aplicación simple	Comience con 1-2 canales
El dispositivo se configura automáticamente en producción	Apagado para producción, encendido para canales de prueba
Saltar `--delta`	Agregar `--delta` Agregar a subidas; utilice `--delta-only` only when you need to save storage
Nombres de paquetes no semversión	Siga versionamiento semántico y valide en el Prueba de SemVer
Cambiar el esquema de versionado con el tiempo	Mantén semver; utiliza etiquetas de versión prelanzada para builds adicionales ("`1.8.0-20260629.1`)
Metadata / habilitado para vista previa sin razón	Dejarlo fuera por defecto

Aprende más

Canales Defaults, precedencia y enrutamiento.

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

CI/CD Automatizar la carga y el despliegue.

Paquetes Checksum, dependencias y metadatos.

Lista de verificación de configuración única