Canales

A Live Update channel points to a specific JS bundle build of your app that will be shared with any devices configured to listen to that channel for updates. When you 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 la configuración de construcción de un canal en cualquier momento y también puede retroceder a versiones anteriores si es necesario.

Los canales no proporcionan confidencialidad

Los canales controlan la elegibilidad de las actualizaciones, no la secrecía de los paquetes. Incluso si un canal es privado o se ha deshabilitado la autoasignación, cualquier paquete no cifrado subido a Capgo debe tratarse 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 con suficiente esfuerzo porque la clave pública forma parte del cliente. Consulte Live Update cifrado para obtener más 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) – 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. Capgo elimina la asignación 90 días después de la última escritura de sobrescritura. Consulte Consola y API sobrescrituras expiran después de 90 días.
2. Opción de nube (por dispositivo) mediante la consola o API – Se crea cuando cambias el canal del dispositivo en la consola o a través de API. Utiliza para usuarios QA que cambian entre canales de características / PR o para reproducir un problema de usuario. Reinstalar el binario no elimina la sobrescritura; eliminar la sobrescritura del dispositivo sí. La misma retención de 90 días se aplica.
3. Plugin setChannel() canal local – Creado cuando la aplicación llama setChannel() and the backend validates that the target channel allows self-assignment. The selected channel is stored locally on that device, takes effect instantly, and is not shown in the Device Override UI.

Cambiar de Canal Instantáneo 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 tu versión principal) setChannel() funciona de manera diferente: se comunica con el backend para validate que el canal esté permitido (verificando si la autoasignación está habilitada para ese canal), luego almacena el canal localmente en el dispositivo como defaultChannel. Esto significa que el nuevo canal tiene efecto instantáneamente para la próxima actualización, sin necesidad de 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 desde el servidor (para la validación) y almacena localmente, lo que hace que los cambios de canal sean instantáneos.

Porque setChannel() es solo local, no not Crea una entrada de override de dispositivo en la consola Capgo. La interfaz de usuario de Device Override solo muestra overrides creados desde la consola o la 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 los canales 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, use setChannel() desde su aplicación code—valida con el servidor de backend, luego establece el canal localmente 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 de fuerza/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 en un canal de prelanzamiento automáticamente. Las versiones de producción suelen dejar esto sin establecer.
5. Canal por defecto de Cloud (ruta principal ~99% de usuarios) – Si marca un canal por defecto en la consola, todos los usuarios finales normales (sin fuerza, sin sobreescribir la consola/API, sin canal local de plugin, sin configuración por defecto de canal) se unen aquí. Cambiarlo para desplegar o retroceder instantáneamente—sin nuevo binario. 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 se une al valor por defecto que coincida con su plataforma. Dejar el valor por defecto de la nube sin establecer es permitido; en ese caso, el dispositivo debe coincidir en los pasos 1–4 para recibir actualizaciones.

La práctica recomendada:

• Trate a 1–4 como capas de excepción / pruebas; cuando establezca un valor por defecto en la nube, 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 in config or per-device overrides).
• Solo configura defaultChannel En binarios que explícitamente envías a los probadores. Dejarlo sin configurar mantiene la lógica de producción centralizada en la consola.
• Use setChannel() raramente en producción—principalmente para pruebas de QA o diagnósticos dirigidos.

If a channel is disabled for the platform (iOS/Android/Electron toggles) when it would otherwise be chosen, the selection process skips it and continues down the list.

Resumen: Forzar > Panel de control/API Sustitución > Plugin setChannel() canal local > Configuración defaultChannel > Canal Predeterminado.

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

Las asignaciones forzadas y el panel de control o el canal 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 sobrescrituraComprobando la actualización sin reiniciar el reloj. Solo escribiendo nuevamente la sobrescritura (o eliminándola tú mismo) cambia la fecha de modificación.

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

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

• Establecer defaultChannel contexto capacitor.config.* (sobrevive a la reinstalación; requiere un nuevo binario nativo para cambiar más tarde).
• llamar setChannel() desde la aplicación. En plugins 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 y posteriores, esa asignación es local y no se elimina con esta limpieza. Reinstalando la aplicación, se elimina, por lo que la aplicación debe llamar setChannel() Vuelve a intentarlo si todavía deseas ese canal.

Dispositivos Devices tab and the device Override UI only list console and Public API assignments. They do not list every device on the channel, and they do not list local setChannel() assignments.

Título de la sección ‘Comportamiento por defecto del canal’

Comportamiento de 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 el archivo de 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 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 valor por defecto para su plataforma. Los dispositivos iOS van al valor por defecto de iOS, los dispositivos Android van al valor por defecto de Android y las aplicaciones Electron van al valor por defecto de Electron.

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

Puedes cambiar los valores por defecto en cualquier momento en la consola. Abre el canal, luego Administrar ajustes de la aplicación, lo que te lleva a Información de la aplicación. El valor por defecto ya no es un interruptor en la página del canal. 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

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. 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 coincidir los canales con las 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 la prueba final en un entorno de producción similar
• Production - para la versión de tu aplicación que los usuarios finales reciben desde las tiendas de aplicaciones

Configuración del Canal en Tu Aplicación

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

(o capacitor.config.ts (or capacitor.config.jsonarchivo. Debajo de plugins sección, opcionalmente configurada defaultChannel para edición de pruebas Para ediciones 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.
    },
  },
};

Luego, construye tu aplicación web y ejecuta npx cap sync to copy the updated config file to your iOS, Android, and Electron projects. If you skip this sync step, your native projects will continue to use whichever channel they were previously configured for.

Caution

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

Usar defaultChannel solo en compilaciones de prueba/internas; omitirlo para producción para que los usuarios sigan el valor por defecto de Cloud (si está configurado) en lugar de duplicar la configuración de routing en la configuración nativa.

Todavía puedes forzar (fijar) un dispositivo o aplicar un override más tarde—esos superan inmediatamente el valor de configuración.

Channel names are case sensitive.

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

• Canal por defecto: Opcionalmente, marca los canales o plataformas específicos que los nuevos dispositivos se unen a. En la consola, esto vive en Información de la aplicación (Gestionar en ajustes de la aplicación Consulte “Comportamiento de Canal Predeterminado” para escenarios de enrutamiento.
• Filtros de plataforma: Habilita o deshabilita la entrega a iOS, Android, o Electron dispositivos por canal.
• No deshabilitar la desactualizació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 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 actualizaciones de dispositivos emuladores: Permite actualizaciones a emuladores/simuladores (útil para pruebas). CLI: --emulator / --no-emulator.
• Permitir actualizaciones de dispositivos físicos: Permite actualizaciones a teléfonos y tabletas reales. Deja esto encendido para los canales de producción. CLI: --device / --no-device.
• Permite la asignación automática del dispositivo: permite al aplicativo cambiar a este canal en tiempo de ejecución setChannelSi está deshabilitado, setChannel No funcionará para este canal. CLI: --self-assign / --no-self-assign.
• Formato de descarga: Elija si los dispositivos descargan un archivo zip completo, solo los archivos delta modificados o la mejor de ambos.all, zip, delta, zip_from_builtin, delta_from_builtin). See Formato de descarga para el menú desplegable de la consola y cuando cada modo es útil.

Despliegues progresivos

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, campos API y comandos CLI.

Deshabilitar estrategias de actualización automática

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

• Utilice esto para restringir qué tipos de actualizaciones entregará automáticamente el canal. Opciones:version_build). Example: 1.2.3 -> 2.0.0 está bloqueado 1.2.3 -> 1.9.0 is permitido.
• minor: Bloquea un paquete objetivo cuyo número de versión mayor o menor difiere de version_build. Ejemplo: 1.2.3 -> 1.3.0 is bloqueado; 1.2.3 -> 1.2.4 is permitido.
• actualización: Modo más estricto. Bloquea cualquier cambio en el número mayor, menor o de parche. Solo se permiten cambios en la sufija mientras MAJOR.MINOR.PATCH se mantiene igual. Ejemplos: 1.0.0-beta.1 -> 1.0.0-beta.2 is permitido, 1.0.0+build.1 -> 1.0.0+build.2 is permitido, 1.0.0 -> 1.0.1 is bloqueado.
• metadata: Requiere una versión mínima de actualización de metadatos en cada paquete. Configura 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_buildno el paquete descargado actualmente enviado como version_name.

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

Ejemplo (CLI). El canal ya debe existir (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 tu aplicación

El setChannel() El método permite que su aplicación cambie programáticamente los canales en tiempo de ejecución. Esto es especialmente ú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+)

Cuando setChannel() se llama:

1. Validación de servidor (solo lectura): Se envía una solicitud al backend 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. Effecto inmediato: La próxima verificación de actualizaciones utiliza el nuevo canal de inmediato (sin esperar a la replicación)

Por qué esto importa: En versiones anteriores, setChannel() guardaba el override 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 del 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 un override de dispositivo en la consola Capgo. Solo los asignaciones de canal creadas desde la consola o el API público están listados allí. Utilice la consola o API cuando necesite un override visible para administradores.

Nota de seguridad: Even si los permisos de un canal cambian después de configurarse localmente (por ejemplo, la autoasignación está deshabilitada), el servidor validará el canal durante las comprobaciones de actualizaciones, asegurando la seguridad.

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

Método	Tiempo de efecto	Persistido en	Mostrado en la interfaz de usuario de dispositivo	Expira	Uso
setChannel() desde el plugin	desde plugin	Dispositivo solo (local)	No	No (hasta que cambies o reinstales)	Switch de canal iniciado por el usuario en la aplicación
Override de dispositivo en la consola	Hasta 2 min	Base de datos del servidor	Sí	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 del servidor	Sí	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, utilice siempre el plugin. setChannel() method.

Versión mínima para cambiar de canal solo local: 5.34.0, 6.34.0, 7.34.0, or 8.0.0 (depending on your major version). Each minor version number corresponds to the same feature set across all major versions (e.g., X.34.0 includes the same features whether X is 5, 6, 7, or 8). See para etiquetas de versión. Asignar un Bundle a un Canal

Sección titulada “Asignar un Bundle a un Canal”

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:

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

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

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

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 semantic versioning con Capgo’s Tester de Semver y versiones de prelanzamiento para compilaciones específicas de canal. Por ejemplo, una versión de beta podría ser versionada 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 ai) por lo tanto el CLI se actualiza desde el canal vinculado hasta que se encuentra un nombre gratuito. Con ai, Workers AI infiere el nivel desde el manifiesto local vs el delta previo (cae en la falla a) patch con ninguna versión previa de Capgo). No se puede combinar con --bundle. Consulte Integración CI/CD y el referencia de CLI.

Este enfoque tiene varios beneficios.

• Comunicación clara de la relación entre las compilaciones. 1.2.3-beta.1 es obviamente una versión previa de 1.2.3.
• Permite reutilizar números de versión en diferentes canales, reduciendo la confusión.
• Proporciona caminos de rollback claros. Si necesitas retroceder desde 1.2.3conoces 1.2.2 es la versión de lanzamiento estable anterior.

Aquí tienes un ejemplo de cómo podrías alinear las versiones de tu paquete con una configuración típica 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 canales: 1.2.3, 1.2.4etc.

Usando semver con identificadores de prelanzamiento Es una recomendación usar semver con identificadores de versión prelanzamiento, pero no es 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 compilación anterior. Desde la sección “Canales” de la consola:

1. Hacer clic en el nombre del canal que deseas revertir
2. Encuentra la compilación que deseas revertir y haz 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 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, puede automatizar sus live update despliegues 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 ciertos ramos o cree nuevas versiones.

Consulte la sección de Integración CI/CD docs to learn more about automating Capgo live updates.

Previsualizaciones de PR con privilegios mínimos

Utilice un Utilice una API key when CI needs one temporary channel per pull request but must not manage existing main/default channels. The key remains bound to the owning organization and selected app; it simply has no organization-wide role. Each non-public preview channel it creates receives its own automatic, channel-scoped lifecycle permission.

1. Tenga un administrador de la organización crear una clave segura API limitada al aplicativo de vista previa y seleccione App PreviewVer API Claves.
2. Utilice un canal único y no público como pr-123. Do not pass --default, --self-assign, opciones de lanzamiento, o --delete-linked-bundle-on-upload.
3. Suba y promueva el paquete de PR en una sola orden, luego elimine el canal y el paquete propiedad cuando se cierre la 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 creates a missing channel, uploads the bundle, and promotes it in one flow. Cleanup is atomic and ownership-checked: the key can delete only a channel it created and its linked, unshared bundle. It cannot change, promote, or delete an existing main/default channel, another preview key’s channel, or another key’s bundle.

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

Un clave de vista de aplicación no puede habilitar vistas por sí misma porque no tiene permiso de configuración de aplicación. En GitHub Acciones, ejecuta trabajos de vista previa con secretos en) pull_request, no pull_request_target, y restrinja 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. Instale el Capgo SDK en su aplicación
2. Configure la aplicación para escuchar su canal deseado
3. Suba una compilación y asigne ese canal
4. Lanzar la aplicación y espere a que se actualice!

Para una guía detallada, consulte el Desplegando Actualizaciones en Vivo ¡Disfruta 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
• Despliegue gradual de características
• Programas de pruebas beta

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

Sigue adelante desde Canales

Si estás utilizando Canal conectarla para planificar la ruta de canal y el despliegue en etapas Canal para obtener más detalles de implementación en Canales, Canal para obtener más 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 Capgo Prácticas recomendadas del entorno: Etapa con un ID de aplicación móvil único para el contexto práctico en Capgo Prácticas recomendadas del entorno: Etapa con un ID de aplicación móvil único.