Saltar al contenido
Capgo - Actualizaciones en vivo para aplicaciones Capacitor Capgo

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 instale las Capgo Actualizaciones en vivo SDK en su aplicación, cualquier binario nativo configurado para ese canal verificará las actualizaciones disponibles cada vez que se lance la aplicación. Puede cambiar el canal de construcción que apunta en cualquier momento y también puede 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 forzosa de dispositivo (Panel de control) – Asigne 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. Overscrito en la nube (por dispositivo) a través de la consola o API – Se crea cuando cambias el canal del dispositivo en la consola o a través de API. Utilízalo para usuarios QA que cambian entre canales de características/PR o para reproducir un problema de usuario. Reinstalar el binario no lo elimina; eliminar la entrada del dispositivo lo hace.
  3. Plugin setChannel() canal local – Se crea cuando la aplicación llama setChannel() y el 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 dispositivos.
  1. Capacitor de configuración defaultChannel (configuración de compilación de prueba por defecto) – Si está presente en capacitor.config.* y no existe un canal forzado/override/local, la aplicación arranca en este canal (por ejemplo, ). Se destina a compilaciones de prueba / internas para que los probadores aterricen en un canal de prelanzamiento automáticamente. Las compilaciones de producción suelen dejar esto sin configurar. beta, qa, pr-123Canal por defecto de Cloud (ruta principal ~99% de usuarios)
  2. – Si marca un canal por defecto en la consola de administración, todos los usuarios normales (sin forzar, sin sobreescribir con la consola/__CAPGO_KEEP_0__, 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 Cloud sin configurar está permitido; en ese caso, el dispositivo debe coincidir con los pasos 1-4 para recibir actualizaciones. API

Mejores prácticas:

  • Traten a 1–4 como excepciones / capas de prueba; cuando establezcan una configuración por defecto en la nube, los usuarios reales deberían fluir hacia ella. Si no eligen establecer una, sean deliberados sobre cómo los usuarios se unen (normalmente a través de defaultChannel en la configuración o sobrescripciones por dispositivo).
  • Sólo configuren defaultChannel en binarios que envíen explícitamente a los probadores. Dejarlo sin configurar mantiene la lógica de producción centralizada en la consola.
  • Utilicen 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 toggles) cuando de lo contrario se elegiría, el proceso de selección lo omite y continúa hacia abajo en la lista.

Resumen: Obligación > Consola/API Sobreescritura > Plugin setChannel() canal local > Config defaultChannel > Configuración por defecto de la nube.

Comportamiento por defecto del canal

Sección titulada “Comportamiento del canal predeterminado”

Establecer un valor por defecto en la nube es opcional, pero suele servir como ruta de escape 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 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 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 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.

Recuerda que el valor por defecto en la nube y defaultChannel en capacitor.config.* ocupan la misma capa de decisión. Si estableces un valor por defecto en la nube, no necesitas duplicar el valor en tu Capacitor configuración—deja defaultChannel vacío para compilaciones de producción. Reserve defaultChannel para binarios que envías intencionalmente a los probadores o QA cuando quieres que comiencen en un canal no de producción aunque el valor por defecto en la nube sea diferente.

Puedes cambiar los valores por defecto en cualquier momento en la consola. Cuando cambias un valor por defecto, los dispositivos nuevos siguen 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

Sección titulada “Configuración de un Canal”

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

  1. Ve a la sección “Canales” de la consola Capgo
  2. Haz clic en el botón “Nuevo Canal”
  3. Ingresa un nombre para el canal y haz clic en “Crear”

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:

  • 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

Configuración del Canal en su Aplicación

Sección titulada “Configuración del Canal en su Aplicación”

Una vez creados sus canales, necesita configurar su aplicación para escuchar el canal apropiado. 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 pruebas de compilación (internas / QA). Para compilaciones de producción, prefiere omitirla para que los dispositivos utilicen el valor por defecto de Cloud a menos que se sobrescriba 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.
    },
  },
};

En primer lugar, 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.

Opciones y estrategias de canal

Sección titulada “Opciones y estrategias de canal”

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 Public API.

  • Canal predeterminado: Opcionalmente marque el canal o los canales específicos de plataforma que los dispositivos nuevos se unen a. Consulte “Comportamiento del canal predeterminado” para escenarios de enrutamiento.
  • Filtros de plataforma: Habilitar o deshabilitar la entrega a dispositivos iOS, Android, o Electron dispositivos por canal.
  • 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 del canal (por ejemplo, dispositivo en 1.2.3 mientras que el canal tiene 1.2.2).
  • Permitir actualizaciones de compilaciones de desarrollo: Permitir actualizaciones a compilaciones de desarrollo (útil para la prueba).
  • Permitir dispositivos de emulación: Permitir actualizaciones a emuladores/simuladores (útil para la prueba).
  • Permitir autoasignación de dispositivo: permite que la aplicación cambie a este canal en tiempo de ejecución utilizando setChannelSi se deshabilita, setChannel fallará para este canal.

Título de sección “Desactivar estrategias de actualización automática”

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

mayor: Bloquea un paquete objetivo cuya versión mayor es mayor que la base de línea nativa del dispositivo (

  • Ejemplo:version_buildestá bloqueado; 1.2.3 -> 2.0.0 está permitido. 1.2.3 -> 1.9.0 menor: Bloquea un paquete objetivo cuya versión mayor o menor difiere de
  • Ejemplo: version_buildes bloqueado; 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 de versión mayor, menor o de parche. Solo se permiten cambios de sufijo mientras MAJOR.MINOR.PATCH se mantiene igual. Ejemplos: 1.0.0-beta.1 -> 1.0.0-beta.2 está permitido, 1.0.0+build.1 -> 1.0.0+build.2 está permitido, 1.0.0 -> 1.0.1 está bloqueado.
  • metadata: Requiere una versión de actualización mínima de metadatos en cada paquete. Configura mediante CLI usando --min-update-version o --auto-min-update-version. Si falta, el canal se marca como mal configurado y las actualizaciones serán rechazadas hasta que se establezca.
  • ninguno: Permitir todas las actualizaciones según la compatibilidad de semver está bloqueado; no está bloqueado..

These strategies compare the channel’s target bundle against the native baseline sent as version_build, no el paquete descargado actualmente enviado como version_name.

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

Ejemplo (CLI):

Ventana de terminal
# 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

Título de la sección “Usando setChannel() desde Tu Aplicación”

El setChannel() Este 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/debugeo 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
});

Asignar un paquete a un canal

Sección titulada “Asignar un paquete a un canal”

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

Ventana de terminal
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.

También puedes asignar compilaciones a canales desde la sección “Paquetes” del panel de control de 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.

Versión de paquetes y canales

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

When estés versionando tus paquetes, recomendamos utilizar la versión semántica con __CAPGO_KEEP_0__’s Tester de Semver y identificadores de versión prelanzamiento para construcciones específicas de canal. Por ejemplo, una versión beta podría ser versionada como semantic versioning with Capgo’s Semver Tester Comunica claramente la relación entre las construcciones. 1.2.3-beta.1.

es obvio que es una versión prelanzamiento de

  • Permite reutilizar números de versión en diferentes canales, reduciendo la confusión. 1.2.3-beta.1 Facilita caminos de rollback claros. Si necesitas retroceder desde 1.2.3.
  • , sabes que
  • es la versión estable anterior. 1.2.3Aquí tienes un ejemplo de cómo podrías alinear las versiones de tus paquetes con un conjunto de canales típico: 1.2.2 canal:

protectedTokens

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

Usando con identificadores de prelanzamiento de 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

Sección titulada “Revertir una Actualización en Vivo”

Si se introduce un error o necesita ser revertido en una actualización en vivo, puede revertir fácilmente a una versión anterior. Desde la sección “Canales” de la consola:

  1. Haga clic en el nombre del canal que desea revertir
  2. Encuentre la versión que desea revertir y haga clic en el icono de la corona Revertir versión
  3. Confirme la acción

La versión seleccionada se volverá inmediatamente la versión activa para ese canal de nuevo. Las aplicaciones recibirán la versión revertida la próxima vez que revisen las actualizaciones.

Automatización de Despliegues

Sección titulada “Automatización de Despliegues”

Para flujos de trabajo más avanzados, puede automatizar los 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 envíe cambios a ciertas ramas o cree nuevas versiones.

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

Desplegando a un Dispositivo

Sección titulada “Desplegando 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 tu canal deseado
  3. Sube una compilación y asigna ese canal
  4. Lanza la aplicación y espera a que se actualice!

Para una guía detallada, consulta el Desplegando Actualizaciones en Vivo ¡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 de características graduales
  • 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 los canales

Si estás utilizando

Canales para planificar la ruta de los canales y el despliegue escalonado, conecta con Section titled “Sigue adelante desde los canales” Canales para los detalles de implementación en Canales, Canales para los detalles de implementación en Canales, 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 Mejores Prácticas de Entorno: Etapa con un ID de Aplicación Móvil para el contexto práctico en Capgo Mejores Prácticas de Entorno: Etapa con un ID de Aplicación Móvil.