Saltar al contenido

Canales

Un canal de actualizaciones 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 de actualizaciones. Cuando instales el canal de actualizaciones Capgo de 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.

Cómo un dispositivo elige un canal (precedencia)

Sección titulada “Cómo un dispositivo elige un canal (precedencia)”

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

  1. Asignación forzada de dispositivo (Panel de control) – Asignar manualmente 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 o PR o para reproducir un problema de usuario. Reinstalar el binario no elimina la entrada; eliminar la entrada del dispositivo sí.
  1. Capacitor config defaultChannel (configuración de compilación de prueba) – Si está presente en capacitor.config.* y no existe una fuerza/override, la aplicación arranca en este canal (por ejemplo, ). beta, qa, pr-123Intendido para compilaciones de prueba / compilaciones internas para que los probadores aterricen en un canal de pre-lanzamiento automáticamente. Las compilaciones de producción suelen dejar esto sin configurar.
  2. Canal predeterminado de Cloud (ruta principal ~99% de usuarios) – Si marca un canal predeterminado en la consola, todos los usuarios normales (sin fuerza, sin sobreescribir, sin configuración predeterminada de canal) se unen aquí. Cambiarlo para desplegar o retroceder instantáneamente—sin nuevo binario. Si tiene valores predeterminados específicos de plataforma (por ejemplo, uno solo para iOS, uno solo para Android, uno solo para Electron), cada dispositivo se une al valor predeterminado que coincida con su plataforma. Dejar el canal predeterminado de Cloud sin establecer está permitido; en ese caso, el dispositivo debe coincidir en los pasos 1–3 para recibir actualizaciones.

Práctica recomendada:

  • Trate a 1–3 como capas de excepción / pruebas; cuando establezca un canal predeterminado, los usuarios reales deben fluir hacia él. Si no elige establecer uno, sea deliberado sobre cómo los usuarios se unen (normalmente a través de defaultChannel en la configuración o por sobreescribir por dispositivo).
  • Solo configure defaultChannel en binarios que envíe explícitamente a los probadores. Dejarlo sin establecer 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.

Si un canal está deshabilitado para la plataforma (iOS/Android/Electron) cuando de lo contrario se elegiría, el proceso de selección lo ignora y continúa con la lista.

Resumen: Fuerza > Sobreescribir > Config defaultChannel > Canal predeterminado de Cloud.

Establecer un valor de canal por defecto en la nube es opcional, pero suele servir como ruta de respaldo para nuevos dispositivos. Sin uno, solo los dispositivos que coincidan 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 de canal por defecto único (más común) – Si un canal tiene habilitado iOS, Android y Electron, se convierte en el valor por defecto único; cualquier dispositivo sin sobrescripciones se unirá aquí.
  • Valores de canal por defecto específicos de plataforma – Si divide los canales por plataforma (por ejemplo, ios-production con solo iOS habilitado, android-production con solo Android habilitado, y electron-production con solo Electron habilitado), marca cada uno como el valor por defecto para su plataforma. Los dispositivos iOS van a la configuración de valor por defecto de iOS, los dispositivos Android van a la configuración de valor por defecto de Android y las aplicaciones Electron van a la configuración de valor por defecto de Electron.

Recuerda que el valor de canal por defecto en la nube y defaultChannel In ambas ocupan la misma capa de decisión. Si estableces un valor por defecto en la nube, no necesitas duplicar el valor en tu configuración de __CAPGO_KEEP_0__ —deja capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel para binarios que envíes intencionalmente a los probadores o QA cuando desees que comiencen en un canal no de producción aunque el valor por defecto de la nube sea diferente. defaultChannel Puedes cambiar los valores por defecto en cualquier momento en la consola. Cuando intercambies un valor por defecto, los dispositivos nuevos obedecen las nuevas reglas de enrutamiento de inmediato y los dispositivos existentes siguen las reglas de precedencia normales la próxima vez que se conecten.

Configuración de un Canal

Dirígete a la sección “Canales” de la consola de __CAPGO_KEEP_0__

  1. Go to the “Channels” section of the Capgo dashboard
  2. Ingresa un nombre para el canal y haz clic en “Crear”
  3. Los nombres de los canales pueden ser cualquier cosa que desees. Una estrategia común es que los canales se ajusten a las etapas de desarrollo, como:

__CAPGO_KEEP_0__

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

Una vez creados los canales, 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. En la sección plugins opcionalmente establezca defaultChannel para edificios de pruebas (interno / QA). Para edificios de producción, prefiere omitirlo para que los dispositivos utilicen el Cloud Default 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.
},
},
};

A continuación, 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 salta este paso de sincronización, sus proyectos nativos seguirán utilizando el canal en el que estaban configurados anteriormente.

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. Puedes configurar estos desde la aplicación web, el CLI, o el Public API.

  • Canal predeterminado: Opcionalmente marca los canales o las configuraciones de plataforma que los nuevos dispositivos se unen a. Consulta “Comportamiento del canal predeterminado” para escenarios de routing.
  • Filtros de plataforma: Habilita o deshabilita la entrega a iOS, Androiddispositivos por canal. Electron Deshabilitar 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 de paquete del canal (por ejemplo, dispositivo en 1.2.3 mientras que el canal tiene 1.2.2).
  • Permitir compilaciones de desarrollo: Permite actualizaciones a compilaciones de desarrollo (útil para la prueba).
  • Permitir compilaciones de desarrollo: Permite actualizaciones a compilaciones de desarrollo (útil para la prueba).
  • Permitir dispositivos de emulación: Permite actualizaciones a emuladores/simuladores (útil para pruebas).
  • Permitir autoasignación de dispositivo: Deja que la aplicación cambie a este canal en tiempo de ejecución utilizando setChannel. Si se deshabilita, setChannel fallará para este canal.

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

  • mayor: Bloquear actualizaciones cruzadas de mayor versión (0.0.0 → 1.0.0). Se permiten actualizaciones menores y parches.
  • menor: Bloquear actualizaciones cruzadas de versión menor (por ejemplo, 1.1.0 → 1.2.0) y mayores. Se permiten actualizaciones de parches. Nota: no bloquea 0.1.0 → 1.1.0.
  • parche: Muy estricto. Sólo permite aumentar versiones de parche dentro del mismo mayor y menor. Ejemplos: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
  • metadatos: Requiere una versión mínima de actualización de metadatos en cada paquete. Configure mediante CLI utilizando --min-update-version o --auto-min-update-version. Si no está configurado, el canal se marca como configurado incorrectamente y se rechazarán las actualizaciones hasta que se establezca.
  • none: Permitir todas las actualizaciones según la compatibilidad de semver Obtenga más detalles y ejemplos en la estrategia de deshabilitar actualizaciones en /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy..

Ejemplo (cli):

Example (CLI):

Copiar a portapapeles
# 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

Sección titulada “Usando setChannel() desde Tu Aplicación”

El

método permite que tu aplicación cambie programáticamente entre canales en tiempo de ejecución. Esto es particularmente útil para: setChannel() Menús de QA/debugeo donde los probadores pueden cambiar entre canales

  • The
  • Flujos de inscripción en el 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
});

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

Integraciones de backend automatizadas
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 canales. Cualquier aplicación configurada para escuchar ese canal recibirá la actualización la próxima vez que revisen una.

Puedes asignar compilaciones a canales desde la sección “Paquetes” del panel de control Capgo. Haz clic en el icono de menú junto a una compilación y selecciona “Asignar a Canal” para elegir el canal para esa compilación.

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 Tester de Semver de Capgo y identificadores de pre-lanzamiento para compilaciones específicas de canales. Por ejemplo, un lanzamiento beta podría versionarse como 1.2.3-beta.1.

Esta aproximación tiene varios beneficios:

  • Comunica claramente la relación entre compilaciones. 1.2.3-beta.1 obviamente es una versión previa de 1.2.3.
  • permite reutilizar números de versión en diferentes canales, reduciendo la confusión.
  • permite 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 las versiones de tu paquete con un conjunto típico de canales:

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

Usando La utilización de identificadores de versión pre-establecidos con semver 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

Haga clic en el nombre del canal que desea revertir

  1. Encuentre la compilación que desea revertir y haga clic en el icono de la corona
  2. Revertir compilación Confirmar la acción
  3. Revertir una Actualización en Vivo

The selected build will immediately become the active build for that channel again. Apps will receive the rolled back version the next time they check for an update.

Para flujos de trabajo más avanzados, puede automatizar sus despliegues de actualizaciones en vivo como parte de su pipeline 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.

Consulte los Integración de CI/CD docs para obtener más información sobre la automatización de actualizaciones en vivo de Capgo.

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

  1. Instale el Capgo SDK en su aplicación
  2. Configure la aplicación para escuchar su canal deseado
  3. Subir una compilación y asignarla a ese canal
  4. Lanzar la aplicación y esperar la actualización!

Para una guía detallada, consulte el Implementación de Actualizaciones en Vivo manual. ¡Feliz actualizando!

Uso avanzado de canales: Segmentación de usuarios

Sección titulada “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
  • Despliegues graduales 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.

Si estás utilizando Canales para planificar la ruta de los canales y la implementación de un lanzamiento escalonado, conecta con Canales para obtener detalles de implementación en Canales, Canales para obtener detalles de implementación en Canales, Solución de Pruebas Beta para el flujo de trabajo del producto en la Solución de Pruebas Beta, Solución de Enfoque de Versión para el flujo de trabajo del producto en la 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.