Checklist de configuración inicial

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

¡Ya terminaste! onboarding. Ahora configura Capgo una vez. Después, el trabajo diario es solo subir → probar → desplegar.

Regla: los channels son carriles de release (development, production), no tickets, features o nombres de desarrolladores.

Checklist de configuración inicial

Crear channels: elige el conjunto más pequeño (ver abajo).
Configura el canal de upload por defecto en ajustes de la app:
- Solo la app → production
- Team → development
Canal de producción: public on, device self-set off, block updates under native on, auto-update guard on major.
Canal de test (development / staging): public off, device self-set on para QA.
Sube desde tu CI con --delta (el checksum y las dependencias nativas son automáticos):
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
```
El --bundle valor usar sea válido versionado semántico. Valídalo en el tester de SemVer antes de hacer el upload.
Desplegar a producción solo tras probarlo, desde el dashboard o CLI.
Equipo y seguridad: invita una vez, con permisos mínimos, 2FA para la org, una clave API en CI.

Deja el cifrado, min_update_version, los metadatos y la vista previa off a menos que tengas un motivo claro.

Elige tu plan

Simple: 1 app, 1 channel: production

Equipo: development + production. Sube a dev, despliega a prod.

Versiones Native: añade channels solo si es necesario, ej. production-9.0 + test-9.0. Mantén a los usuarios de la tienda en el canal de producción principal.

Muchas apps: mismo modelo simple por app (normalmente uno production cada una). No crees channels extra solo porque la org sea grande.

Ciclo de lanzamientos (opcional): staging → rc → production. El mismo template en cada app que lo necesite.

Nombre del bundle vs comentario

Los nombres de los bundles son obligatorios para seguir versionado semántico. Capgo usa semver para checks de compatibilidad, reglas de auto-update de canales y rollbacks. Valida cada nombre en el Tester de SemVer antes de subir.

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

Usa semver pre-release labels (la parte después de -) cuando lances muchos builds bajo el mismo MAJOR.MINOR.PATCH. Por ejemplo, mantén 1.8.0 y añade la fecha o el contador de build en el pre-release: 1.8.0-20260629.1, 1.8.0-beta.2. No inventes formatos personalizados como fix-login-bug o 2.5.2026062306. No son semver válidos y las subidas fallarán o se comportarán de forma impredecible.

Pon las release notes en --comment, no en el nombre del bundle.

Ver también segmentación por versión y versionado de bundles.

Subida delta

--delta subidas archivos delta así los dispositivos descargan solo los archivos cambiados en lugar del bundle completo cada vez. El checksum se calcula automáticamente; no necesitas pasar un flag de checksum.

Por defecto: `--delta` (archivos delta + backup zip)

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

Esta es la configuración recomendada para la mayoría de las apps. Capgo almacena los archivos delta y y mantiene el zip completo como backup. Los dispositivos con una versión de plugin antigua sin soporte para Delta usarán el zip. Ideal si el coste de almacenamiento no es tu prioridad.

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

Usa --delta-only cuando quieras reducir el almacenamiento de Capgo. Solo se guardan los archivos delta, no el zip completo. Úsalo en apps grandes o con mucho volumen de upload donde el espacio sea un problema.

Contraste: sin el backup del zip en el servidor, dependes totalmente de los archivos delta; los dispositivos con un plugin antiguo sin soporte para Delta no podrán actualizar. Omitir --delta-only a menos que realmente necesites ahorrar espacio.

No requiere configuración extra del plugin en el dispositivo. El updater lee la lista de archivos delta y descarga solo los archivos que cambiaron.

Flujo de trabajo diario

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

Errores comunes

Error	Solución
Esperar OTA antes de un nuevo release en la store	Reconstruye y lanza la app nativa tras añadir el plugin
Subir un bundle sin desplegarlo a un channel	Asigna el bundle a un channel (ej. `production`)
Un channel por feature, ticket o desarrollador	Usa solo lanes de release permanentes
Nombres de channel dinámicos en CI	Nombres fijos: `development`, `production`
Demasiados channels para una app sencilla	Empieza con 1-2 channels
Auto-configuración de dispositivo en producción	Desactivado en producción, activado en channels de test
Omitir `--delta`	Añadir `--delta` para subir; usa `--delta-only` solo cuando necesites ahorrar espacio
Nombres de bundle sin SemVer	Seguir versionado semántico y valida en el Tester de SemVer
Cambiar el esquema de versionado con el tiempo	Mantén SemVer; usa etiquetas pre-release para builds extra (`1.8.0-20260629.1`)
Metadata / preview activado sin motivo	Desactivado por defecto

Saber más

Canales Valores por defecto, precedencia y enrutamiento.

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

CI/CD Automatiza el upload y deploy.

Bundles Checksum, dependencias y metadatos.

Checklist de configuración inicial