Canales

Un canal de Live Update 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 Capgo Live Updates 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 un canal en cualquier momento y también puedes retroceder a versiones anteriores si es necesario.

Canales No Proporcionan Confidencialidad

Los canales controlan la elegibilidad de actualizaciones, no la secrecía de paquetes. Incluso si un canal es privado o la autoasignación está deshabilitada, cualquier paquete no cifrado subido a Capgo debe tratarse todavía como un activo público entregado a los clientes. La cifrado protege el camino de entrega y la autenticidad de las actualizaciones, pero los paquetes enviados todavía pueden ser descompuestos de la aplicación distribuida con suficiente esfuerzo porque la clave pública es parte del cliente. Consulte Live Update cifrado para detalles.

¿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. Mapeo de dispositivo forzado (Panel de control) – Asigna 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. Capgo elimina la asignación 90 días después de la última escritura de sobrescritura. Consulte Console y API sobrescripciones expiran después de 90 días.
2. Opción de nube (por dispositivo) mediante la consola o API – Creada cuando cambies 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 la sobrescripción; eliminar la sobrescripción del dispositivo lo hace. La misma retención de 90 días se aplica.
3. Plugin setChannel() canal local – Creado cuando la aplicación llama a setChannel() y el servidor de backend valida que el canal objetivo permite la autoasignación. El canal seleccionado se almacena localmente en ese dispositivo, tiene efecto instantáneo y no se muestra en la interfaz de usuario de Sustitución de Dispositivo.

Intercambio de canales instantáneo con setChannel()

Desde 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 comunica 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 defaultChannel. Esto significa que el nuevo canal entra en vigor de inmediato para la próxima actualización de verificación—sin esperar a la replicación.

Anteriormente, setChannel() guardaba el override del canal en la base de datos del servidor (como Dashboard o API cambios), y los dispositivos tenían que esperar a la replicación de datos (hasta 2 minutos) antes de que el nuevo canal fuera reconocido. El nuevo comportamiento solo lee de la base de datos (para la validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos.

Porque setChannel() es solo local, hace que no cree una entrada de override de dispositivo en el Capgo dashboard. La interfaz de usuario de Device Override solo muestra overrides creados desde el dashboard o el Public API.

Nota: Aunque un canal se vuelva inhabilitado después de configurarlo localmente, el servidor validará el canal durante las comprobaciones de actualizaciones, por lo que se mantiene la seguridad.

Importante: Cuando se realizan cambios en el canal a través de la Consola de administración 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, use setChannel() desde tu aplicación code—valida con el servidor de backend, luego establece el canal local para un efecto inmediato.

4. Capacitor de configuración defaultChannel (versión de prueba predeterminada) – Si está presente en capacitor.config.* y no existe un canal forzado/override/local, la aplicación arranca en este canal (por ejemplo, beta, qa, pr-123Intendido para versiones de prueba / internas, para que los probadores aterricen automáticamente en un canal de prelanzamiento. Las versiones de producción suelen dejar esto sin configurar.
5. Canal por defecto de Cloud (ruta principal ~99% de usuarios) – Si marcas un canal por defecto en la consola de administración, todos los usuarios normales (sin forzar, sin override de la consola/API, sin canal local de plugin, sin configuración defaultChannel) se unen aquí. Cambiarlo para desplegar o retroceder instantáneamente—sin nuevo binario. Si tienes 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.

Buena práctica:

• Tener en cuenta 1-4 como capas de excepción / pruebas; cuando establezcas un canal por defecto en la nube, los usuarios reales deben fluir hacia él. Si no lo estableces, sé deliberado sobre cómo los usuarios se unen (normalmente a través de defaultChannel en la configuración o en overrides por dispositivo).
• Configuración solo para defaultChannel en binarios que explícitamente envíen 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.

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

Resumen: Obligatorio > Consola/API Sustitución > Plugin setChannel() canal local > Configuración defaultChannel > Por defecto de la nube.

Consola y API sobrescrituras caducan después de 90 días

Para los mapeos forzados y las sobrescripciones de canal de Dashboard o Público API se almacenan como asignaciones por dispositivo en Capgo. Un trabajo de limpieza elimina esas asignaciones. 90 días después de la última escritura de sobrescrituraVerificando la actualización no reinicia el reloj. Solo escribiendo la sobrescritura nuevamente (o eliminándola tú mismo) cambia la fecha de modificación.

No es lo mismo que retención de inventario de dispositivos. El inventario elimina dispositivos que no se han conectado a Capgo durante 90 días. La limpieza de sobrescripciones elimina la asignación incluso si el dispositivo sigue activo.

Para una asignación que no se elimina por esta limpieza:

• Establecer defaultChannel in capacitor.config.* (sobrevive a la reinstalación; requiere un nuevo binario nativo para cambiar más tarde).
• Call setChannel() from the app. On plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 and later, that assignment is local and is not removed by this cleanup. Reinstalling the app clears it, so the app must call setChannel() Vuelve a intentarlo si todavía deseas ese canal.

El canal Dispositivos La pestaña y el dispositivo de sobrescritura solo muestran asignaciones de consola y públicas API. No muestran todos los dispositivos del canal y no muestran dispositivos locales setChannel() assignments.

Comportamiento del Canal Predeterminado

Sección titulada “Comportamiento del Canal Predeterminado”

Setting a cloud default is optional, but it usually serves as the catch-all path for new devices. Without one, only devices that match on forced mappings, overrides, or a defaultChannel en la configuración Capacitor recibirán actualizaciones. Cuando elijas marcar valores por defecto, ten en cuenta estos patrones:

• Valores predeterminados específicos de plataforma – Si un canal tiene iOS, Android y Electron habilitados, se convierte en el único predeterminado; cualquier dispositivo sin sobreescribir se unirá aquí.
• Preferencias por plataforma por defecto – 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 predeterminado para su plataforma. Los dispositivos iOS van al canal predeterminado de iOS, los dispositivos Android van al canal predeterminado de Android, y las aplicaciones Electron van al canal predeterminado de Electron.

Recuerde que el predeterminado de la nube y defaultChannel in capacitor.config.* ambos ocupan el mismo nivel de decisión. Si estableces un valor por defecto en la nube, no necesitas duplicar el valor en tu configuración de Capacitor —deja defaultChannel Reservar para compilaciones de producción. defaultChannel for binaries you intentionally ship to testers or QA when you want them to start on a non-production channel even if the cloud default is different.

Puedes cambiar los valores por defecto en cualquier momento desde la consola. Abre el canal, , lo que te lleva aManage in App settings Información de la AplicaciónLa configuración predeterminada ya no es un interruptor en la página del canal. Cuando intercambies una configuración predeterminada, los dispositivos nuevos siguen la nueva configuración 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 la configuración inicial 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. Dirígete a la sección “Canales” de la consola de 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 coincidir los canales con tus etapas de desarrollo, como:

• Development - para probar actualizaciones en vivo en dispositivos locales o emuladores
• QA - for your QA team to verify updates before wider release
• Staging para pruebas finales en un entorno similar a la producción
• Production - para la versión de tu aplicación que los usuarios finales reciben desde las tiendas de aplicaciones.

Configurando el canal en tu aplicación.

Una vez creados los canales, debes configurar tu aplicación para que escuche el canal adecuado. En este ejemplo, utilizaremos el Development canal.

Abre tu capacitor.config.ts (o capacitor.config.jsonarchivo. Bajo el plugins ) archivo. Bajo la defaultChannel for para Para compilaciones de producción, omita esta configuración para que los dispositivos utilicen el valor por defecto de Cloud.

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, construye tu aplicación web y ejecuta npx cap sync para copiar el archivo de configuración actualizado a tus proyectos de iOS, Android y Electron. Si omites este paso de sincronización, tus proyectos nativos seguirán utilizando el canal en el que estaban configurados anteriormente.

Advertencia

Orden de selección de canal: Forzar > Opción de dispositivo del panel de control/API > Plugin setChannel() canal local > Configuración defaultChannel > Canal Predeterminado.

Use defaultChannel only in test/internal builds; leave it out for production so users follow the Cloud Default (when set) instead of duplicating the routing in native config.

Puedes forzar (pin) un dispositivo o aplicar un override más tarde, lo que tiene prioridad sobre el valor de configuración.

Channel names are case sensitive.

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, marca los canales o plataformas específicas a los que se conectan nuevos dispositivos. En la consola, esto se encuentra en Información de la aplicación ("Administrar en ajustes de la aplicación desde la página del canal). Consulte “Comportamiento del canal predeterminado” para escenarios de enrutamiento.
• Filtros de plataforma: Habilitar o deshabilitar la entrega a iOS, Androido 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 versión del paquete del canal (por ejemplo, dispositivo en 1.2.3 mientras que el canal tiene 1.2.2).
• Allow development builds: Permit updates to development builds (useful for testing). CLI: --dev / --no-dev.
• Allow production builds: Permit updates to production (store) builds. Leave this on for channels that serve real users. CLI: --prod / --no-prod.
• Permitir dispositivos emuladores: Permite actualizaciones a emuladores/simuladores (útil para pruebas). CLI: --emulator / --no-emulator.
• Permitir dispositivos físicos: Permite actualizaciones a teléfonos y tabletas reales. Deja esto encendido para canales de producción. CLI: --device / --no-device.
• Permitir la asignación automática del dispositivo: permite que la aplicación cambie a este canal en tiempo de ejecución setChannelSi se deshabilita, setChannel fallará para este canal. CLI: --self-assign / --no-self-assign.
• Paquete de actualización: Elija si los dispositivos descargan un archivo zip completo, un delta de archivos modificados o ambos (all, zip, delta, zip_from_builtin, delta_from_builtinConsulte Paquete de actualización para el menú desplegable de la consola y cuando cada modo es útil.

Despliegue progresivo

A channel can keep a stable bundle while gradually exposing a separate rollout target to a sticky device cohort. You can pause, resume, promote, roll back, and configure an automatic failure response without switching the channel for everyone. See Despliegues progresivos para el modelo de entrega, flujo de trabajo de la consola, API campos y CLI comandos.

Deshabilitar 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 superior a 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_buildEjemplo: 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 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. Configure mediante CLI usando --min-update-version o --auto-min-update-versionSi falta, el canal se marca como configurado incorrectamente y las actualizaciones serán rechazadas hasta que se establezca.
• ninguno: Permitir todas las actualizaciones según compatibilidad de semver.

Estas estrategias comparan el paquete objetivo del canal con la base nativa enviada como version_build, no el currente paquete descargado enviado como version_name.

Obtenga más detalles y ejemplos en la estrategia de deshabilitar actualizaciones en /docs/cli/comandos/#desactivar-actualizaciones-estrategia.

Ejemplo (CLI). El canal debe existir ya (channel set No crea un canal.

# 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

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

Usando setChannel() desde su aplicación

El setChannel() método permite a su aplicación cambiar canales de manera programática 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
});

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 es exitosa, 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 inmediatamente (sin esperar a la replicación)

Por qué esto importa: En versiones anteriores, setChannel() guardaba la sobrescritura del canal en la base de datos del backend (igual que 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() solo lee desde el 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 se muestre como una sobrescritura de dispositivo en la consola de Capgo. Solo las asignaciones de canal creadas desde la consola o el API público se muestran allí. Utilice la consola o API cuando necesite una sobrescritura visible para administradores.

Nota de seguridad: Even 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 verificaciones de actualizaciones, asegurando la seguridad.

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

Método	Tiempo de efecto	Persistido Donde	Mostrado en la interfaz de usuario de Override de Dispositivo	Vence	Uso de Caso
setChannel() Desde plugin	Inmediato	Solo en el dispositivo (local)	No	No (hasta que cambies o reinstales)	Cambiar de canal en la aplicación
Panel de dispositivo override	Hasta 2 min	Base de datos de backend	Si	90 días después de la última actualización manual	Cambios administrados para dispositivos específicos
Asignación de canal API	Hasta 2 min	Base de datos de backend	Si	90 días después de la última actualización manual	Integraciones de backend automatizadas

Para una mejor experiencia del usuario al crear interfaces de cambio de canal, siempre utilice el plugin. setChannel() Automatizado

Versión mínima para cambiar de canal de forma local: 5.34.0, 6.34.0, 7.34.0o 8.0.0 (dependiendo de tu 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 de plugins para etiquetas de versión.

Asignar un paquete a un canal

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

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

Esto subirá tus activos web compilados y establecerá la nueva compilación como la build 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 puede asignar compilaciones a canales desde la sección "Paquetes" del panel de control Capgo. Haga clic en el icono de menú junto a una compilación y seleccione "Asignar a canal" para elegir el canal para esa compilación.

Versión de paquetes y canales

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

Al versionar sus paquetes, recomendamos utilizar versión semántica con el Semver Tester 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.

En CI, si la versión local ya se había subido, utilice npx @capgo/cli@latest bundle upload --auto-bump opcionalmente major, minor, patch/fix, metadata, o aipara que CLI incremente desde el paquete vinculado del canal hasta encontrar un nombre libre. Con aiWorkers AI infiere el nivel desde el delta de manifestos local vs previo (cae en patch con ninguna versión previa Capgo). No puedes combinarlo con --bundle. Consulta Integración CI/CD y el referencia de CLI.

Este enfoque tiene varios beneficios.

• Esta aproximación tiene varios beneficios: 1.2.3-beta.1 Claramente comunica la relación entre las compilaciones. 1.2.3.
• Permite reutilizar números de versión entre canales, reduciendo la confusión.
• Permite reutilizar números de versión en diferentes canales, reduciendo la confusión. 1.2.3, sabe 1.2.2 es la versión estable anterior.

Aquí hay un ejemplo de cómo podrías alinear las versiones de tu paquete con una configuración de canal típica:

• 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.4, etc.

Usando semver con identificadores de versión 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 Live Update

Si despliegas una live update que introduce un error o necesita ser revertido, puedes revertir fácilmente a una versión anterior. Desde la sección “Canales” de la consola:

1. Haz clic en el nombre del canal que deseas revertir
2. Encuentra la versión que deseas revertir y haz clic en el icono de la corona
3. Confirmar la acción

La versión seleccionada se convertirá inmediatamente en la versión activa para ese canal de nuevo. Las aplicaciones recibirán la versión revertida la próxima vez que busquen una actualización.

Automatizando Despliegues

Para flujos de trabajo más avanzados, puedes automatizar los despliegues de tu live update como parte de tu pipeline CI/CD. Al integrar Capgo en tu proceso de compilación, puedes subir automáticamente nuevos paquetes y asignarlos a canales cada vez que envíes cambios a ciertas ramas o crees nuevas versiones.

Explora el Integración CI/CD docs to learn more about automating Capgo live updates.

Previsualizaciones de PR con privilegios mínimos

Usar un App Preview API clave cuando la CI necesite una canal temporal por solicitud de extracción, pero no debe gestionar los 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 previsualización no público que crea recibe sus propias autorizaciones de ciclo de vida automáticas, escaladas al canal.

1. Tenga un administrador de organización que cree una clave API segura limitada a la aplicación de previsualización y seleccione App PreviewConsulte Claves API.
2. Usar un canal único y no público como pr-123. No pasar --default, --self-assign, opciones de lanzamiento, o --delete-linked-bundle-on-upload.
3. Subir y promocionar el paquete de PR en una sola orden, luego eliminar el canal y el paquete propiedad cuando se cierre el PR:

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, promocionar o eliminar un canal principal/por defecto existente, un canal de otra clave de vista previa, o un paquete de otra clave.

If reviewers need a QR code or preview URL, an administrator must enable previews once for the app:

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.

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. Ejecuta la aplicación y espera a que se actualice!

Para una guía detallada, consulta el Desplegando Actualizaciones en Vivo manual. ¡Feliz actualizando!

Uso Avanzado de Canales: Segmentación de Usuarios

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

• Feature flags for different user tiers
• Pruebas A/B
• Implementación 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 los canales

Si estás utilizando Canal conectarlo para planificar la ruta de canal y el despliegue en etapas 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.