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 onboarding. Ahora configura 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 verificación de configuración única

Crear canales: elija el conjunto más pequeño que se adapte (consulte a continuación).
Establecer 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, dispositivo autoconfigurado apagado, bloquear actualizaciones bajo nativo encendido, guardia de actualización automática encendida major.
Canal de prueba (development / staging: público apagado, dispositivo autoconfigurado encendido para QA.
Subir desde CI con --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
```
La --bundle debe ser válido semantic versioning . Valídalo en elprueba SemVer antes de subir. Despliega a producción solo después de probar, desde la
. . dashboard o CLI.
Equipo y seguridad: invitar una vez, menos permisos, 2FA para la organización, una API clave en CI.

Cifrado de salida, min_update_version, metadatos y vista previa desactivado a menos que tenga una razón clara.

Elige tu tamaño

Simple: 1 app, 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 almacen en el canal de producción principal.

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

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

Nombre de paquete vs comentario

Los nombres de paquetes son necesarios para seguir la versión semántica. Capgo utiliza semver para comprobaciones de compatibilidad, reglas de actualización automática de canales 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 etiqueta previa etiquetas (la parte después de -) cuando envíes muchas versiones bajo el mismo MAJOR.MINOR.PATCH. Por ejemplo, mantén 1.8.0 y agrega la fecha o contador de construcción en la etiqueta previa: 1.8.0-20260629.1, 1.8.0-beta.2. No inventen formatos personalizados como fix-login-bug o 2.5.2026062306. Los semvers no válidos y las subidas fallarán o comportarseán de manera inesperada.

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

Consulte también la versión de destino y la versión del paquete.

Sube delta

--delta sube un delta manifesto de esta manera los dispositivos descargan solo los archivos modificados en lugar de la versión completa cada vez. El checksum se calcula automáticamente siempre. No pasas una bandera de checksum.

Predeterminado: `--delta` (manifesto + 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 manifesto y mantiene la copia completa en formato zip como copia de seguridad. Bueno cuando el costo de almacenamiento no es tu principal preocupación.

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 quieras reducir el __CAPGO_KEEP_0__ almacenamiento reduce Capgo storageCompromiso: sin el respaldo de zip en el servidor, dependes completamente del camino de manifest. Saltar

a menos que realmente necesites las ahorras de almacenamiento --delta-only No se requiere ninguna configuración de plugin adicional en el dispositivo. El actualizador lee el manifest y descarga solo los archivos modificados

Consejo

Flujo diario

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

Errores comunes

Error	Solución
Esperando actualizaciones OTA antes de una nueva versión de tienda	Reconstruir y enviar la aplicación nativa después de agregar el plugin
Subiendo un paquete pero no desplegando 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
Configuración de dispositivo autoestable en producción	Apagado para producción, encendido para canales de prueba
Saltando `--delta`	Agregar `--delta` para subir archivos; use `--delta-only` solo cuando necesites ahorrar espacio de almacenamiento
Nombres de paquetes no semver	Sigue la versión semántica y valida en el Prueba de SemVer
Cambiar el esquema de versionado con el tiempo	Mantén semver; usa etiquetas de versión prelanzada para ediciones adicionales (`1.8.0-20260629.1`)
Metadatos / habilitado sin razón	Dejarlo desactivado por defecto

Aprende más

Canales Defaults, precedencia y enrutamiento.

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

Integración CI/CD Automatice el subir y desplegar.

Paquetes Checksum, dependencias y metadatos.

Lista de verificación de configuración única