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.

Has terminado onboardingAhora configura Capgo una vezDespués de eso, el trabajo diario es solo subir → probar → desplegar.

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

Lista de verificación de configuración única

Crear canales : elija el conjunto más pequeño que se adapte (consulte a continuación).
Establecer el canal de carga por defecto en configuración de la aplicación:
- Solo aplicación → production
- Equipo → development
Canal de producción: público encendido, autoconfiguración de dispositivo apagado, bloquear actualizaciones bajo nativo encendido, guardia de actualización automática encendida major.
Canal de prueba (development / staging: público apagado, dispositivo encendido por defecto para QA.
Subir desde CI con --delta (el checksum y las 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
```
El --bundle valor debe ser válido semantic versioning. Verifica antes de subir. Prueba SemVer antes de subir.
Despliega a producción solo después de probar, desde el panel de control o CLI.
Equipo y seguridad: invita una vez, permisos mínimos, 2FA para la organización, una API clave en CI.

Deja la cifrado, min_update_versionmetadata, y vista previa apagado no tienes una razón clara.

Elige tu tamaño

Sencillo: 1 aplicación, 1 canal: production

Equipo: development + production. Subir a dev, desplegar a prod.

Versiones nativas: agregar canales solo cuando sea necesario, por ejemplo. production-9.0 + test-9.0. Mantener a los usuarios del almacenamiento en el canal de producción principal.

Muchas aplicaciones: mismo modelo simple por aplicación (usualmente uno production cada una). No cree canales adicionales solo porque la organización es grande.

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

Nombre del paquete vs comentario

Los nombres de los paquetes son requerido 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.1o 1.8.0-20260629.42
Comentario = texto libre para humanos → commit abc1234 run 28059070270

Utiliza semver antes de la versión final 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 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 válidos semver y las subidas fallarán o comportarse de manera impredecible.

Coloca notas de versión en --comment, no en el nombre del paquete.

Consultar también versiones objetivo y versión de paquete.

Subir delta

--delta sube un archivo de manifiesto de modo que los dispositivos descarguen solo los archivos modificados en lugar del paquete completo cada vez. El checksum se calcula siempre automáticamente. No pasas una bandera de checksum.

Predeterminado: `--delta` (archivo de manifiesto + copia de seguridad en formato zip)

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

Esta es la configuración recomendada por defecto para la mayoría de las aplicaciones. Capgo almacena el manifiesto y mantiene el archivo zip completo como copia de seguridad. Es bueno cuando el costo de almacenamiento no es tu principal preocupación.

Ahorrando 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 quieres reducir el almacenamiento de __CAPGO_KEEP_0__ reduce Capgo storageCompromiso: sin la copia de seguridad del archivo zip en el servidor, te apoyas completamente en el camino del manifiesto. Omite

when you want to reduce __CAPGO_KEEP_0__ storage. Only the delta/manifest files are stored, not the full zip. Choose this for large apps or high upload volume where storage adds up. --delta-only a menos que realmente necesites las ahorras de almacenamiento.

No se requiere ninguna configuración de plugin adicional en el dispositivo. El actualizador lee el manifiesto 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
Esperando OTA antes de una nueva versión de tienda	Reconstruir y enviar la aplicación nativa después de agregar el plugin
Subir un paquete pero no desplegar a 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
Dispositivo autoconfigurado para producción	Apagado para producción, encendido para canales de prueba
Saltar `--delta`	Agregar `--delta` a subidas; utilice `--delta-only` solo cuando necesite ahorrar espacio de almacenamiento
Nombres de paquetes no semversión	Siga la semversión y valide en el prueba de SemVer
Cambiar el esquema de versionado con el tiempo	Mantener semver; usar etiquetas de pre-lanzamiento para ediciones adicionales (`1.8.0-20260629.1`)
Metadata / habilitado de vista previa sin razón	Desactivado por defecto

Conoce más

Canales Predeterminados, precedencia y enrutamiento.

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

CI/CD Automatizar subida y despliegue.

Paquetes Checksum, dependencias y metadatos.

Lista de verificación de configuración única