Canales

Un canal de actualización en vivo apunta a una construcción de paquete JS específica de tu aplicación que se compartirá con cualquier dispositivo configurado para escuchar ese canal para actualizaciones. Cuando instales el Capgo canal de actualizaciones SDK en tu aplicación, cualquier binario nativo configurado a ese canal verificará actualizaciones disponibles cada vez que se lance la aplicación. Puedes cambiar la construcción a la que apunta el canal en cualquier momento y también puedes retroceder a versiones anteriores si es necesario.

No se proporciona confidencialidad con los canales

Los canales controlan la elegibilidad de actualizaciones, no la secrecía de paquetes. Incluso si un canal es privado o se ha deshabilitado la autoasignación, cualquier paquete no cifrado subido a Capgo todavía debe tratarse como un activo público entregado a los clientes. La cifrado protege el camino de entrega y la autenticidad de actualizaciones, pero los paquetes enviados todavía pueden ser descompuestos con suficiente esfuerzo porque la clave pública forma parte del cliente. Consulta la cifrado de actualizaciones en vivo para obtener más detalles.

How un dispositivo elige un canal (precedencia)

Cuando un dispositivo verifica una actualización, Capgo decide qué canal usar en este orden estricto (prioridad más alta primero):

1. Asignación de dispositivo forzada (Panel de control) – Pinar un ID de dispositivo específico a un canal. Utilice para depuración urgente o pruebas controladas con un solo usuario real. Esto siempre gana.
2. Supervisión de nube (por dispositivo) a través del Panel de control o API – Creado cuando cambie el canal del dispositivo en el panel de control o a través de API. Utilice para usuarios de QA que cambian entre canales de características / PR o para reproducir un problema de usuario. Reinstalar el binario no elimina esto; eliminar la entrada de dispositivo lo hace.
3. Plugin setChannel() canal local – Creado cuando la aplicación llama setChannel() y el servidor de backend valida que el canal objetivo permite la asignación automática. El canal seleccionado se almacena localmente en ese dispositivo, tiene efecto instantáneo y no se muestra en la interfaz de usuario de la sobrescritura de dispositivo.

Cambiar de canal instantáneamente con setChannel()

A partir de la versión del plugin 5.34.0, 6.34.0, 7.34.0 o 8.0.0 (dependiendo de su versión principal), setChannel() funciona de manera diferente: se contacta con el backend para validar que el canal esté permitido (verificando si la autoasignación está habilitada para ese canal), luego se almacena el canal localmente en el dispositivo como defaultChannelEsto significa que el nuevo canal tiene efecto instantáneamente para la próxima verificación de actualizaciones—sin tener que esperar a la replicación.

Anteriormente, setChannel() guardó la sobrescritura del canal en la base de datos del backend (como la consola o API cambios), y los dispositivos tuvieron que esperar a que se replicara la información (hasta 2 minutos) antes de que se reconociera el nuevo canal. El nuevo comportamiento solo lee desde el backend (para la validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos.

Porque setChannel() es solo local, no crea una entrada de sobrescritura de dispositivo en la Capgo consola. La interfaz de usuario de la sobrescritura de dispositivo solo muestra sobrescripciones creadas desde la consola o el Public API.

Nota: Incluso si un canal se vuelve prohibido después de establecerse localmente, el backend aún validará el canal durante las comprobaciones de actualización, por lo que se mantiene la seguridad.

Importante: Cuando se realizan cambios de canal a través de la Consola o API, todavía hay un retraso de replicación de hasta 2 minutos antes de que todos los servidores de borde reflejen el cambio. Para cambiar de canal de manera instantánea, utilice setChannel() desde tu aplicación code—valida con el backend, luego establece el canal localmente para un efecto inmediato.

4. Capacitor config defaultChannel (configuración de compilación de prueba por defecto) – Si está presente en capacitor.config.* y no existe un canal de fuerza/override/local, la aplicación comienza en este canal (por ejemplo, beta, qa, pr-123). Se destina a versiones de prueba / internas para que los probadores aterricen automáticamente en un canal de pre-lanzamiento. Las versiones de producción suelen dejar esto sin configurar.
5. Canal por defecto de la nube (ruta principal ~99% de usuarios) – Si marca un canal por defecto en la consola, todos los usuarios normales (sin fuerza, sin sobreescribir el Dashboard/API, sin canal local de plugin, sin configuración defaultChannel) se unen aquí. Cambiarlo para desplegar o retroceder instantáneamente—sin nueva binaria. Si tiene valores por defecto específicos de plataforma (por ejemplo, uno solo para iOS, uno solo para Android, uno solo para Electron), cada dispositivo aterriza en el valor por defecto que coincide con su plataforma. Dejar el canal por defecto de la nube sin configurar está permitido; en ese caso, el dispositivo debe coincidir con los pasos 1–4 para recibir actualizaciones.

Buen práctica:

• Trate a 1–4 como capas de excepción / pruebas; cuando establezca un canal por defecto, los usuarios reales deben fluir hacia él. Si no elige configurarlo, sea deliberado sobre cómo los usuarios se unen (normalmente mediante defaultChannel en la configuración o por sobreescripciones por dispositivo).
• Solo configure defaultChannel en binarios que envíe explícitamente a los probadores. Dejarlo sin configurar mantiene la lógica de producción centralizada en la consola.
• Use setChannel() con moderación en producción—principalmente para pruebas de QA o diagnósticos dirigidos.

If un canal está deshabilitado para la plataforma (iOS/Android/Electron toggles) cuando de lo contrario sería elegido, el proceso de selección lo salta y continúa hacia abajo en la lista.

Resumen: Force > Panel de control/API Override > Plugin setChannel() canal local > Configuración defaultChannel > Por defecto de Cloud.

Comportamiento por defecto del canal

Establecer un valor por defecto en la nube es opcional, pero suele servir como el camino de respaldo para nuevos dispositivos. Sin uno, solo los dispositivos que coinciden con las asignaciones forzadas, las sobrescripciones o un defaultChannel en la configuración Capacitor recibirán actualizaciones. Cuando elijas marcar valores por defecto, ten en cuenta estos patrones:

• Valor por defecto único (más común) – Si un canal tiene iOS, Android y Electron habilitados, se convierte en el valor por defecto único; cualquier dispositivo sin sobrescripciones se unirá aquí.
• Valores por defecto específicos de plataforma – Si divide los canales por plataforma (por ejemplo, ios-production With solo iOS habilitado, android-production With solo Android habilitado, y electron-production Con solo Electron habilitado), marquen cada uno como el predeterminado para su plataforma. Los dispositivos iOS van a la configuración predeterminada de iOS, los dispositivos Android van a la configuración predeterminada de Android, y las aplicaciones Electron van a la configuración predeterminada de Electron.

Recuerde que la configuración por defecto de la nube y defaultChannel en capacitor.config.* ambos ocupan el mismo nivel de decisión. Si establece una configuración por defecto de la nube, no necesita duplicar el valor en su configuración Capacitor—deje defaultChannel vacío para ediciones de producción. Reserve defaultChannel para binarios que envíe intencionalmente a los probadores o QA cuando desee que comiencen en un canal no de producción aunque la configuración por defecto de la nube sea diferente.

Puede cambiar las configuraciones por defecto en cualquier momento en la consola. Cuando intercambie una configuración por defecto, los nuevos dispositivos siguen la nueva ruta de inmediato y los dispositivos existentes siguen las reglas de precedencia normales la próxima vez que se conecten.

Configuración de un Canal

Durante el proceso de incorporación, crea el primer canal (la mayoría de los equipos lo llaman “Producción”), pero nada está bloqueado—puede renombrar o eliminar cualquier canal en cualquier momento. Para agregar canales adicionales más tarde:

1. Ir a la sección de “Canales” del panel de control Capgo
2. Haga clic en el botón “Nuevo Canal”
3. Ingrese un nombre para el canal y haga clic en “Crear”

Los nombres de los canales pueden ser cualquier cosa que desee. Una estrategia común es coincidir los canales con las etapas de desarrollo, como:

• Development - para probar actualizaciones en vivo en dispositivos locales o emuladores
• QA - para que su equipo de QA verifique las actualizaciones antes de una mayor difusión
• Staging - para la prueba final en un entorno de producción similar
• Production - para la versión de la aplicación que los usuarios finales reciben desde las tiendas de aplicaciones

Configuración del Canal en la Aplicación

Con los canales creados, necesita configurar su aplicación para escuchar el canal adecuado. En este ejemplo, usaremos el Development canal.

Abra su capacitor.config.ts (o capacitor.config.json) archivo. Bajo la plugins sección, configúrelo opcionalmente defaultChannel para edición de pruebas (interna / QA). Para ediciones de producción, prefiere omitirlo para que los dispositivos utilicen el valor por defecto de Cloud a menos que se haya sobrescrito explícitamente.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Siguiente, construya su aplicación web y ejecute npx cap sync para copiar el archivo de configuración actualizado a sus proyectos de iOS, Android y Electron. Si omite este paso de sincronización, sus proyectos nativos seguirán utilizando el canal en el que estaban configurados anteriormente.

Advertencia

Orden de selección de canales: Fuerza > Panel/API dispositivo de sobrescritura > Plugin setChannel() canales locales > Config defaultChannel > Por defecto de Cloud.

Usar defaultChannel solo en compilaciones de prueba/internas; déjelo fuera para producción para que los usuarios sigan el Por defecto de Cloud (si está configurado) en lugar de duplicar la ruta en la configuración nativa.

Puede forzar (fijar) un dispositivo o aplicar una sobrescritura más tarde—esas lo superan inmediatamente al valor de la configuración.

Los nombres de los canales son sensibles a mayúsculas y minúsculas.

Opciones y estrategias de canales

Los canales tienen varias opciones que controlan quién puede recibir actualizaciones y cómo se entregan las actualizaciones. Los más importantes están a continuación. Puede configurar estos desde la aplicación web, el CLI, o el API público.

• Canales por defecto: Opcionalmente marque los canales o canales específicos de plataforma que los dispositivos nuevos se unen a. Consulte “Comportamiento de canales por defecto” para escenarios de ruta.
• Filtros de plataforma: Habilitar o deshabilitar la entrega a iOS, Androido dispositivos por canal. Electron Desactivar la actualización automática bajo nativo: Evita enviar una actualización cuando la versión nativa del dispositivo es más nueva que la versión del paquete del canal (por ejemplo, dispositivo en 1.2.3 mientras que el canal tiene 1.2.2).
• Permitir actualizaciones de compilaciones de desarrollo: (útil para pruebas).
• Permitir dispositivos de emulación: (útil para pruebas).
• Permitir autoasignación de dispositivos: permite al aplicativo cambiar a este canal en tiempo de ejecución usando
• Si se desactiva, setChannelfallará para este canal. setChannel Despliegue progresivo

Título de la sección “Despliegue progresivo”

Despliegue progresivo o dispositivos por canal. para el modelo de entrega, flujo de trabajo de la consola, API campos y CLI comandos.

Deshabilitar estrategias de actualización automática

Use esto para restringir qué tipos de actualizaciones el canal entregará automáticamente. Opciones:

• mayor: Bloquea un paquete objetivo cuya versión mayor es mayor que la base nativa del dispositivo (version_build). Ejemplo: 1.2.3 -> 2.0.0 está bloqueado; 1.2.3 -> 1.9.0 está permitido.
• menor: Bloquea un paquete objetivo cuya versión mayor o menor difiere de version_build. Ejemplo: 1.2.3 -> 1.3.0 está bloqueado; 1.2.3 -> 1.2.4 está permitido.
• patch: Modo más estricto. Bloquea cualquier cambio a un número mayor, menor o de parche. Solo se permiten cambios de sufijo mientras MAJOR.MINOR.PATCH stays identical. Ejemplos: 1.0.0-beta.1 -> 1.0.0-beta.2 is allowed, 1.0.0+build.1 -> 1.0.0+build.2 is allowed, 1.0.0 -> 1.0.1 is bloqueado.
• metadata: Requiere una versión de actualización mínima de metadatos en cada paquete. Configure mediante CLI usando --min-update-version o --auto-min-update-version. Si falta, el canal se marca como configurado incorrectamente y las actualizaciones serán rechazadas hasta que se establezca.
• none: Permitir todas las actualizaciones según la compatibilidad de semver Estas estrategias comparan el paquete de destino del canal contra la base nativa enviada como.

y no el paquete descargado actualmente enviado como version_build, not the current downloaded bundle sent as version_name.

Obtenga más detalles y ejemplos en la estrategia de deshabilitar actualizaciones en /docs/cli/commands/#disable-updates-strategy.

Ejemplo (CLI):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Usando setChannel() desde Tu Aplicación

El setChannel() El método permite que su aplicación cambie programáticamente entre canales en tiempo de ejecución. Esto es particularmente útil para:

• Menús de QA/debug donde los probadores pueden cambiar entre canales
• Flujos de inscripción de programa beta
• Implementaciones de banderas de características
• Escenarios de pruebas A/B

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

¿Cómo funciona setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)?

Cuándo setChannel() se llama:

1. Validación de backend (solo lectura): Se envía una solicitud al backend de Capgo para validar que el canal esté permitido (verificando permisos de autoasignación)
2. Actualización de almacenamiento local: Si la validación pasa, el canal se guarda en el almacenamiento local del dispositivo como defaultChannel
3. Efecto instantáneo: La próxima verificación de actualizaciones utiliza el nuevo canal de inmediato (sin esperar a la replicación)

¿Por qué importa esto: In versiones antiguas, setChannel() guardó la sobrescritura del canal en la base de datos del backend (lo mismo que los cambios en la consola o API). Los dispositivos tenían que esperar a la replicación del backend (hasta 2 minutos) antes de que el cambio de canal tuviera efecto. Ahora, setChannel() solamente lee del backend (para la validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos.

Visibilidad de la consola: Un canal configurado con el plugin no hace que el dispositivo aparezca como una sobrescritura de dispositivo en la Capgo UI. Solo las asignaciones de canal creadas desde la consola o el Public API se muestran allí. Utilice la consola o API cuando necesite una sobrescritura visible para administradores.

Nota de seguridad: Incluso si los permisos de un canal cambian después de ser configurados localmente (por ejemplo, la autoasignación está deshabilitada), el backend validará el canal durante las comprobaciones de actualización, asegurando la seguridad.

Comparación de métodos de cambio de canal:

Método	Tiempo de efecto	Persistido en	Mostrado en la UI de sobrescritura de dispositivo	Uso de caso
setChannel() desde plugin	Instantáneo	Dispositivo solo (local)	No	Cambio de canal iniciado por el usuario en la aplicación
Overshadow de dispositivo en la consola	Hasta 2 min	Base de datos de backend	Sí	Cambios administrados para dispositivos específicos
API asignación de canal	Hasta 2 min	Base de datos de backend	Sí	Integraciones de backend automatizadas

Para obtener la mejor experiencia del usuario al crear interfaces de usuario de cambio de canal, siempre utilice el método del plugin: setChannel() método.

Versiones mínimas para el cambio de canal solo local: 5.34.0, 6.34.0, 7.34.0, o 8.0.0 (dependiendo de su versión principal). Cada número de versión menor corresponde al mismo conjunto de características en todas las versiones principales (por ejemplo, X.34.0 incluye las mismas características independientemente de que X sea 5, 6, 7 o 8). Consulte instalación del plugin para etiquetas de versión.

Asignar un paquete a un canal

Para desplegar una actualización en vivo, debes subir una nueva compilación de JS y asignarla a un canal. Puedes hacer esto en un paso con el Capgo CLI:

npx @capgo/cli@latest bundle upload --channel=Development

Esto subirá tus activos web compilados y establecerá el nuevo paquete como la compilación activa para el Development canal. Cualquier aplicación configurada para escuchar ese canal recibirá la actualización la próxima vez que busque una.

Puedes asignar builds a canales desde la sección “Paquetes” del Capgo dashboard. Haz clic en el icono de menú junto a un build y selecciona “Asignar a canal” para elegir el canal para ese build.

Versión de paquetes y canales

Es importante tener en cuenta que los paquetes en Capgo son globales para tu aplicación, no específicos de canales individuales. El mismo paquete puede asignarse a múltiples canales.

Al versionar tus paquetes, recomendamos utilizar la versión semántica con el Capgo’s Tester de Semver y sus identificadores de prelanzamiento para ediciones específicas de canal. Por ejemplo, una versión de beta podría estar versionada como 1.2.3-beta.1.

Esta aproximación tiene varios beneficios:

• Comunica claramente la relación entre las ediciones. 1.2.3-beta.1 obviamente es una versión de prelanzamiento de 1.2.3.
• Permite reutilizar números de versión en diferentes canales, reduciendo la confusión.
• Hace posible caminos de rollback claros. Si necesitas retroceder desde 1.2.3, sabes 1.2.2 es la versión estable anterior.

Aquí tienes un ejemplo de cómo podrías alinear tus versiones de paquetes con una configuración típica de canal:

• Development canal: 1.2.3-dev.1, 1.2.3-dev.2, etc.
• QA canal: 1.2.3-qa.1, 1.2.3-qa.2, etc.
• Staging canal: 1.2.3-rc.1, 1.2.3-rc.2, etc.
• Production canal: 1.2.3, 1.2.4Usando

con identificadores de prelanzamiento es un enfoque recomendado, pero no estrictamente necesario. La clave es encontrar un esquema de versionado que comunique claramente las relaciones entre tus compilaciones y se alinee con el proceso de desarrollo de tu equipo. Revertir una Actualización en Vivo Sección titulada “Revertir una Actualización en Vivo”

Si despliegas una actualización en vivo que introduce un error o necesita ser revertida, puedes revertir fácilmente a una compilación anterior. Desde la sección “Canales” de la consola:

Revertir una Actualización en Vivo

1. Si despliegas una actualización en vivo que introduce un error o necesita ser revertida, puedes revertir fácilmente a una compilación anterior. Desde la sección “Canales” de la consola:
2. Encuentre la compilación que desea revertir y haga clic en el icono de la corona
3. Confirmar la acción

La compilación seleccionada se convertirá inmediatamente en la compilación activa para ese canal nuevamente. Las aplicaciones recibirán la versión revertida la próxima vez que revisen actualizaciones.

Automatización de Despliegues

Para flujos de trabajo más avanzados, puede automatizar sus despliegues de actualizaciones en vivo como parte de su pipeline de CI/CD. Al integrar Capgo en su proceso de compilación, puede subir automáticamente nuevos paquetes y asignarlos a canales cada vez que pulse en ciertas ramas o cree nuevas versiones.

Ver más sobre Integración de CI/CD consulte los docs para aprender más sobre la automatización de actualizaciones en vivo de Capgo.

Previsualizaciones de PR con privilegios mínimos

Utilice una Vista de Aplicación API clave cuando CI necesita una canal temporal por solicitud de extracción, pero no debe gestionar canales existentes principales/por defecto. La clave permanece vinculada a la organización propietaria y la aplicación seleccionada; simplemente no tiene un papel organizativo. Cada canal de vista previa no público que cree recibe sus propias permisos de ciclo de vida automáticos, canal-escopados.

1. Tenga un administrador de la organización que cree una clave API segura limitada a la aplicación de vista previa y seleccione Vista de Aplicación. Consulte API Claves.
2. Utilice un canal único, no público como pr-123. No pase --default, --self-assign, opciones de lanzamiento o --delete-linked-bundle-on-upload.
3. Suba y promueva el paquete de solicitud de extracción en una sola orden, luego elimine el canal y el paquete propiedad cuando se cierre la solicitud de extracción:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel crea un canal faltante, sube el paquete y lo promociona en un flujo. La limpieza es atómica y verificada por propiedad: la clave puede eliminar solo un canal que creó y su paquete vinculado, no compartido. No puede cambiar, promover o eliminar un canal principal/por defecto existente, un canal de otra clave de vista previa o un paquete de otra clave.

Si los revisores necesitan un código QR code o una URL de vista previa, un administrador debe habilitar las vistas previas una vez para la aplicación:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Una clave de vista previa de aplicación no puede habilitar las vistas previas ella misma porque no tiene permiso de configuración de aplicación. En GitHub Actions, ejecuta trabajos de vista previa con secretos en pull_request, no pull_request_target, y restringe a PRs de la misma repositorio con github.event.pull_request.head.repo.full_name == github.repository.

Desplegar a un dispositivo

Ahora que entiendes los canales, estás listo para empezar a desplegar actualizaciones en vivo a dispositivos reales. El proceso básico es:

1. Instala el Capgo SDK en tu aplicación
2. Configura la aplicación para escuchar el canal deseado
3. Carga una compilación y asigna a ese canal
4. Lanza la aplicación y espera a la actualización!

Para una guía detallada, consulta el Actualización en vivo manual. ¡Feliz actualizando!

Uso avanzado de canales: Segmentación de usuarios

Los canales se pueden utilizar para más que solo las etapas de desarrollo. Son una herramienta poderosa para la segmentación de usuarios, lo que permite características como:

• Banderas de características para diferentes niveles de usuarios
• Pruebas A/B
• Despliegue gradual de características
• Programas de pruebas beta

Aprende a implementar estos casos de uso avanzados en nuestra guía: Cómo segmentar a los usuarios por plan y canales para banderas de características y pruebas A/B.

Sigue adelante desde Canales

Si estás utilizando Canales para planificar la ruta de los canales y el despliegue en etapas, conecta Canales con Canales para obtener detalles de implementación en Canales, y Solución de Pruebas Beta para el flujo de trabajo del producto en Solución de Pruebas Beta, Solución de Enfoque de Versión para el flujo de trabajo del producto en Solución de Enfoque de Versión, y Capgo Prácticas de Entorno: Etapa con un ID de Aplicación Móvil para el contexto práctico en Capgo Prácticas de Entorno: Etapa con un ID de Aplicación Móvil.