Canales

Un canal de actualizaciones en vivo apunta a una construcción específica de paquete JS de tu aplicación que se compartirá con cualquier dispositivo configurado para escuchar ese canal de actualizaciones. Cuando install the Capgo Live Updates SDK Los canales no proporcionan confidencialidad

Los canales controlan la elegibilidad de las actualizaciones, no la secrecía del paquete. Incluso si un canal es privado o la autoasignación está deshabilitada, cualquier paquete no cifrado subido a __CAPGO_KEEP_0__ todavía 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. Consulta

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See Source guide 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. Asignación forzosa 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 Cloud (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 este; eliminar la entrada del dispositivo sí.
3. Plugin setChannel() canal local – Creado cuando la aplicación llama setChannel() y el servidor valida que el canal objetivo permite la asignación automática. El canal seleccionado se almacena localmente en ese dispositivo, tiene efecto inmediato y no se muestra en la interfaz de usuario de la sobrescritura de dispositivo.

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 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 surte efecto instantáneamente para la próxima verificación de actualizaciones—sin necesidad de 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 data (hasta 2 minutos) antes de que se reconociera el nuevo canal. El nuevo comportamiento solo lee de la base de datos del 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 inaceptable después de haberse establecido localmente, el backend aún validará el canal durante las comprobaciones de actualizaciones, 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 (prueba por defecto) – Si está presente en capacitor.config.* y no existe un canal forzado/override/local, la aplicación comienza en este canal (por ejemplo, beta, qa, pr-123Se destina a pruebas de TestFlight / ediciones internas para que los probadores aterricen automáticamente en un canal de pre-lanzamiento. Los ediciones 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 normales (sin forzar, sin sobreescribir Dashboard/API, sin plugin local canal, 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 establecer está permitido; en ese caso, el dispositivo debe coincidir con los pasos 1–4 para recibir actualizaciones.

Buen práctica:

• Trata 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 establecer uno, sea deliberado sobre cómo los usuarios se unen (normalmente mediante defaultChannel Solo configura
• en binarios que envíe explícitamente a los probadores. Dejarlo sin establecer mantiene la lógica de producción centralizada en la consola. defaultChannel Utilice
• Use setChannel() raramente 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: Fuerza > Panel de control/API Sustitución > Plugin setChannel() canal local > Configuración defaultChannel > Por defecto de Cloud.

Comportamiento por defecto del canal

Establecer un valor por defecto de Cloud es opcional, pero suele servir como ruta de escape para nuevos dispositivos. Sin uno, solo los dispositivos que coinciden con las asignaciones forzadas, las sustituciones 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 sustituciones 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), marque 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 canal por defecto de la nube y defaultChannel ambos ocupan el mismo nivel de decisión. Si establece un canal por defecto de la nube, no necesita duplicar el valor en su configuración __CAPGO_KEEP_0__—deje 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íe intencionalmente a los probadores o QA cuando desee que comiencen en un canal no de producción incluso si el canal por defecto de la nube es diferente. defaultChannel Puede cambiar los valores predeterminados en cualquier momento en la consola. Cuando intercambie un valor predeterminado, los nuevos dispositivos siguen el nuevo 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

Configuración de un Canal

Durante la configuración inicial, crea 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 de ‘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 tu equipo de QA verifique las actualizaciones antes de una mayor difusión
• Staging - para la prueba final 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 escuchar al canal adecuado. En este ejemplo, utilizaremos el Development canal.

Abra su capacitor.config.ts (o capacitor.config.json) archivo. Bajo la plugins sección, opcionalmente establezca defaultChannel para edición de pruebas internas / QA). Para ediciones 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.
    },
  },
};

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.

Cuidado

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

Sólo en compilaciones de prueba/internas; omitirlo en producción para que los usuarios sigan el canal predeterminado de Cloud (si está configurado) en lugar de duplicar la configuración de routing en la configuración nativa. defaultChannel Puedes forzar (fijar) un dispositivo o aplicar una sobrescritura más tarde—esas sobrescriben inmediatamente el valor de configuración.

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

Opciones y estrategias de canales

Sección titulada “Opciones y estrategias de canales”

Channels have several options that control who can receive updates and how updates are delivered. The most important ones are below. You can configure these from the web app, the CLI, or the Public API.

• Cuidado
• filtros de plataforma: Habilita o deshabilita 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 el canal tiene 1.2.2).
• Permitir actualizaciones de compilaciones de desarrollo: Permite actualizaciones a compilaciones de desarrollo (útil para pruebas).
• Permitir dispositivos de emulación: Permite actualizaciones a emuladores/simuladores (útil para pruebas).
• Permitir autoasignación de dispositivos: Permite que la aplicación cambie a este canal en tiempo de ejecución utilizando setChannel. Si se deshabilita, setChannel fallará para este canal.

Despliegues progresivos

Un canal puede mantener una versión estable del paquete mientras expone gradualmente un objetivo de despliegue separado a un conjunto de dispositivos fijos. Puede pausar, reanudar, promover, retroceder y configurar una respuesta automática de error sin cambiar el canal para todos. Consulte Despliegues progresivos para el modelo de entrega, flujo de trabajo de la consola, campos API y comandos CLI.

Deshabilitar estrategias de actualizaciones automáticas

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_buildEjemplo: 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 utilizando --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 la compatibilidad de semver compatibilidad de semver.

Estas estrategias comparan el paquete objetivo del canal con la base nativa enviada como version_build, no el bundle descargado actualmente 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):

# 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 a tu 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 siguiente comprobación de actualizaciones utiliza el nuevo canal inmediatamente (sin esperar a la replicación)

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

Nota de seguridad: Incluso si cambian las permisos de un canal después de haberse configurado 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 interfaz de usuario de Override de Dispositivo	Uso
setChannel() Desde plugin	Instantáneo	Solo dispositivo (local)	No	Cambios de canal iniciados por el usuario en la aplicación
Panel de control de dispositivo override	Hasta 2 min	Base de datos de servidor	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, utilice siempre el método del plugin. setChannel() Versiones mínimas para el cambio de canal local solo:

, o 5.34.0, 6.34.0, 7.34.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 8.0.0 instalación del plugin para etiquetas de versión. plugin installation

Asignar un paquete a un canal

Para desplegar una actualización en vivo, es necesario subir una nueva compilación de JS del paquete y asignarla a un canal. Puede 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.

También puede asignar compilaciones a canales desde la sección “Paquetes” del Capgo dashboard. 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 tu aplicación, no específicos de canales individuales. El mismo paquete puede asignarse a múltiples canales.

Cuando versiones tus paquetes, recomendamos utilizar versión semántica con Capgo’s Tester de Semver y identificadores de versión prelanzamiento para compilaciones específicas de canal. Por ejemplo, una versión de beta podría estar 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) para que CLI aumente desde el paquete vinculado del canal hasta encontrar un nombre gratuito. Con ai, Workers AI infiere el nivel desde el delta de manifest local vs previo (cae en patch con ninguna versión previa de Capgo). No se puede combinar con --bundle. Consulte y la referencia __CAPGO_KEEP_0__ CLI reference.

Este enfoque tiene varios beneficios:

• Claramente comunica la relación entre las 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.
• Hace posible los caminos de rollback claros. Si necesitas retroceder desde 1.2.3sabes 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 una configuración típica de canal:

• Development canal: 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.2, etc.
• Production canal: 1.2.3, 1.2.4, etc.

Usando semver con identificadores de pre-lanzamiento 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

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:

1. Haz 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 construcción seleccionada se convertirá inmediatamente en la construcción activa para ese canal de nuevo. Las aplicaciones recibirán la versión revertida la próxima vez que revisen actualizaciones.

Automatizar Despliegues

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 envíe cambios a ciertas ramas o cree nuevas versiones.

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

documentos para obtener más información sobre la automatización de __CAPGO_KEEP_0__ actualizaciones en vivo.

Título de sección “Previsualizaciones de PR con privilegios mínimos” Vista previa de la aplicación La clave API se utiliza cuando CI necesita una canalización temporal por solicitud de extracción, pero no debe gestionar canales principales o predeterminados existentes. La clave sigue vinculada a la organización propietaria y a la aplicación seleccionada; simplemente no tiene un papel organizativo. Cada canal de vista previa no público que crea recibe sus propias permisos de ciclo de vida automáticos, escalados por canal.

1. Que un administrador de la organización cree una clave API segura limitada a la aplicación de vista previa y seleccione Vista previa de la aplicaciónConsulte Claves API.
2. Utilice un canal único y no público como pr-123No pase --default, --self-assignopciones 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 promueve en un flujo. La limpieza es atómica y se verifica la propiedad: la clave solo puede eliminar un canal que creó y su paquete vinculado, no compartido. No puede cambiar, promover o eliminar un canal principal o predeterminado existente, un canal de otra clave de revisión 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 la aplicación no puede habilitar las vistas previas ella misma porque no tiene permiso para configurar la aplicación. En GitHub Actions, ejecuta trabajos de vista previa que contienen secretos en pull_request, no pull_request_target, y restringe a PRs con 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 tu 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 Actualizaciones en vivo: Despliegue ¡Actualizando con alegría!

Uso avanzado de canales: Segmentación de usuarios

Los canales pueden usarse 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.

Sigue adelante desde Canales

Si estás utilizando Canales contexto: nombre de la característica de canales de Capgo. Página/área: página de marketing de soluciones de Capgo. Rol: etiqueta de UI corta o elemento de navegación. Visto en: página soluciones/white-label.astro. Clave de mensaje `solutions_white_label_visual_cell2_value` (Valor de celda visual de soluciones White Label). conectarlo con Canales contexto: nombre de la característica de canales de Capgo. Página/área: página de marketing de soluciones de Capgo. Rol: etiqueta de UI corta o elemento de navegación. Visto en: página soluciones/white-label.astro. Clave de mensaje `solutions_white_label_visual_cell2_value` (Valor de celda visual de soluciones White Label). para los detalles de implementación en Canales, Canales, contexto: nombre de la característica de canales de Capgo. Página/área: página de marketing de soluciones de Capgo. Rol: etiqueta de UI corta o elemento de navegación. Visto en: página soluciones/white-label.astro. Clave de mensaje `solutions_white_label_visual_cell2_value` (Valor de celda visual de soluciones White Label). para el flujo de trabajo del producto en la Solución de Pruebas en Beta Solución de Alcance de Versión para el flujo de trabajo del producto en la Solución de Alcance de Versión, y Capgo Prácticas recomendadas del entorno: Etapa con un ID de aplicación móvil para el contexto práctico en Capgo Prácticas recomendadas del entorno: Etapa con un ID de aplicación móvil.