Canal

Un canal de actualizaciones en vivo apunta a una construcción de paquete JS específica de tu aplicación que se compartirá con cualquier dispositivo configurado para escuchar ese canal de actualizaciones. Cuando instales el canal de actualizaciones en vivo Capgo de SDK en tu aplicación, cualquier binario nativo configurado a ese canal verificará actualizaciones disponibles cada vez que se lance la aplicación. Puedes cambiar la construcción a la que apunta un canal en cualquier momento y también puedes retroceder a versiones anteriores si es necesario. Los canales no proporcionan confidencialidad

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 cargado a Capgo debe tratarse aún 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 aún pueden ser descompuestos desde la aplicación distribuida con suficiente esfuerzo porque la clave pública es parte del cliente. Consulte La cifrado de actualizaciones en vivo para obtener 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 forzada 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. Capgo elimina la asignación 90 días después de la última escritura de sobrescritura. Consulte Los overrides de la consola y API expiran después de 90 días.
2. Sobrescritura de nube (por dispositivo) a través del Panel de control o API – Creado 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 o PR o para reproducir un problema de usuario. Reinstalar el binario no elimina la sobrescritura; eliminar la sobrescritura 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 tu versión principal), setChannel() funciona de manera diferente: contacta al servidor de backend para validar 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 entra en vigor de inmediato para la próxima verificación de actualizaciones—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 se reconociera el nuevo canal. 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, no crea 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: Even if a channel becomes disallowed after being set locally, the backend will still validate the channel during update checks, so security is maintained.

Importante: Cuando se realizan cambios en el canal mediante 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, utilice 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 forzado/override/local, la aplicación arranca en este canal (por ejemplo, beta, qa, pr-123Intendido para versiones de prueba internas / de TestFlight, 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 la nube (ruta principal ~99% de usuarios) – Si marca un canal por defecto en la consola de administración, todos los usuarios normales (sin forzar, sin sobreescribir mediante la consola de administración/API, sin canal local de plugin, sin configuración defaultChannel) 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 aterriza en el valor por defecto que coincide con su plataforma. Dejar el canal por defecto de la nube sin configurar está permitido; en ese caso, el dispositivo debe coincidir con los pasos 1-4 para recibir actualizaciones.

Buena práctica:

• Trate a 1-4 como capas de excepción / de prueba; cuando establezca un canal por defecto en la nube, los usuarios reales deben fluir hacia él. Si no lo configura, sea deliberado sobre cómo los usuarios se unen (normalmente mediante defaultChannel en config o sobrescrituras por dispositivo).
• Sólo configura defaultChannel en binarios que envíes explícitamente a los probadores. Dejarlo sin configurar mantiene la lógica de producción centralizada en la consola.
• Utiliza 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: Forzar > Consola/API Sobreescritura > Plugin setChannel() canal local > Config defaultChannel > Por defecto de la nube.

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

Las asignaciones forzadas y las sobrescrituras de la consola 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 overrideComprobando actualizaciones no reinicia ese reloj. Solo escribiendo el override de nuevo (o borrándolo 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 override elimina la asignación incluso si el dispositivo sigue activo.

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

• Establecer defaultChannel en capacitor.config.* (sobrevive a la reinstalación; requiere una nueva binaria nativa para cambiar más tarde).
• Llamar setChannel() contexto: texto fragmento de HTML de una cadena de Capgo UI más larga (clave de página `appflow_migration_step2`). Página/área: Comparación de flujo de Appflow / marketing de migración. Rol: Copia de sitio web de oración. Visto en: página ionic-appflow.astro. Conservar términos de producto/marca y desarrollador de Capgo exactamente. Clave de mensaje `appflow_migration_step2` (Paso 2 de migración de Appflow). setChannel() desde la aplicación. En el plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 y posterior, esa asignación es local y no se elimina por esta limpieza. Reinstalando la aplicación la elimina, por lo que la aplicación debe llamar a __CAPGO_KEEP_0__ de nuevo si todavía quiere ese canal.

El canal Dispositivos pantalla de dispositivos y la configuración de 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() asignaciones.

Notificación de retención de sobrescrituras en la pantalla de dispositivos del canal.

Comportamiento de canal predeterminado

Establecer un valor de canal por defecto es opcional, pero suele servir como el camino por defecto para nuevos dispositivos. Sin uno, solo los dispositivos que coinciden con las asignaciones forzadas, las sobrescrituras o un __CAPGO_KEEP_0__ en la configuración recibirán actualizaciones. Cuando elija marcar valores por defecto, tenga en cuenta estos patrones: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• – Si un canal tiene iOS, Android y Electron habilitados, se convierte en el valor por defecto único; cualquier dispositivo sin sobrescrituras se unirá aquí. – Si un canal tiene iOS, Android y Electron habilitados, se convierte en el valor por defecto único; cualquier dispositivo sin sobrescrituras se unirá aquí.
• Configuración específica 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 predeterminado de iOS, los dispositivos Android van al predeterminado de Android, y las aplicaciones Electron van al predeterminado de Electron.

Recuerde que el predeterminado de la nube y defaultChannel ambos ocupan el mismo nivel de decisión. Si establece un predeterminado 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 aunque el predeterminado de la nube sea diferente. defaultChannel Puede cambiar los predeterminados en cualquier momento en la consola. Abra el canal, luego

Administrar en ajustes de la aplicación Configuración específica de plataformala cual te lleva a Información de la Aplicación. El valor predeterminado ya no es un interruptor en la página del canal. Cuando intercambies 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

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 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 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

Configuración del canal en tu aplicación

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

Abre tu capacitor.config.ts (o capacitor.config.json) archivo. En la sección plugins opcionalmente establece defaultChannel para edición de pruebas (internacional / QA). Para ediciones de producción, prefiere omitirlo para que los dispositivos utilicen el valor por defecto de Cloud a menos que se sobreescriba 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.
    },
  },
};

Siguiente, 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 canales: Fuerza > Configuración del dispositivo/API > Plugin setChannel() canal local > Configuración defaultChannel > Valor por defecto de Cloud.

Utilice defaultChannel solo en ediciones de prueba/internas; déjelo fuera para la producción para que los usuarios sigan el valor por defecto de Cloud (si está configurado) en lugar de duplicar la configuración de ruteo en la configuración nativa.

Puedes forzar (fijar) un dispositivo o aplicar una sobrescripción más tarde—esas se imponen inmediatamente sobre el valor de configuración.

Los nombres de los canales son sensibles a la casilla.

Opciones y estrategias de los 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. Puede configurarlos desde la aplicación web, el CLI, o el API público.

• Canal predeterminado: Opcionalmente, marque los canales o los canales específicos de plataforma que los dispositivos nuevos se unen a. En el consola, esto vive en la información de la aplicación (Gestionar 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, Androiddispositivos por canal. Electron Deshabilitar la actualización automática bajo nativo: Evita enviar una actualización cuando la versión nativa del dispositivo es más nueva que la versión del paquete del canal (por ejemplo, dispositivo en 1.2.3 mientras que el canal tiene 1.2.2).
• Permitir actualizaciones de compilación de desarrollo: Permitir actualizaciones a compilaciones de desarrollo (útil para la prueba). __CAPGO_KEEP_0__:
• Allow development builds: Permit updates to development builds (useful for testing). CLI: --dev / --no-dev.
• Permitir actualizaciones de producción: Permite actualizaciones a builds de producción (almacén). Deje esto activado para los canales que sirven a usuarios reales. 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. Deje esto activado para los canales de producción. CLI: --device / --no-device.
• Permitir la asignación de dispositivos por parte del dispositivo: Permite que la aplicación cambie a este canal en tiempo de ejecución utilizando setChannelSi se desactiva, setChannel fallará para este canal. CLI: --self-assign / --no-self-assign.
• Paquete de actualización: Elija si los dispositivos descargan un archivo zip completo, una 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 un canal puede mantener una paquete estable mientras expone gradualmente un objetivo de lanzamiento separado a un grupo de dispositivos pegajosos. Puede pausar, reanudar, promover, retroceder y configurar una respuesta de falla automática sin cambiar el canal para todos. Consulte Despliegues progresivos para el modelo de entrega, flujo de trabajo de la consola, API campos y CLI comandos.

Desactivar estrategias de actualización automática

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

• mayor: Bloquea un paquete objetivo cuya versión mayor es superior a la base de línea 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 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. Configúrelo 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 o.

Estas estrategias comparan el paquete objetivo del canal con la base nativa enviada como 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/comandos/#estrategia-de-desactivar-actualizaciones.

Ejemplo (CLI). El canal ya debe existir (channel set no lo crea):

# 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/debug donde los probadores pueden cambiar entre canales
• Flujos de inscripción al programa de pruebas 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 del almacenamiento local: Si la validación es exitosa, el canal se guarda en el almacenamiento local del dispositivo como defaultChannel
3. Efecto 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 Dashboard o API cambios). 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() 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 de administración: Un canal configurado con el plugin no hace que el dispositivo aparezca como un override de dispositivo en la Capgo UI. Solo se muestran allí las asignaciones de canal creadas desde la consola de administración o el Public API . Utilice la consola de administración o API cuando necesite un override visible para los 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	Dónde se persiste	Mostrado en la interfaz de usuario de override de dispositivo	Expira	Caso de uso
setChannel() Desde plugin	Inmediato	Sólo en el dispositivo (local)	No	No (hasta que cambies o reinstales)	Cambio de canal iniciado por el usuario en la aplicación
Override de dispositivo en la consola	Hasta 2 min	Base de datos de backend	Sí	90 días después de la última escritura de sobrescritura	Cambios iniciados por el administrador para dispositivos específicos
API asignación de canal	Hasta 2 min	Base de datos de backend	Sí	90 días después de la última escritura de sobrescritura	Integraciones de backend automatizadas

Para obtener la mejor experiencia del usuario al crear interfaces de usuario de cambio de canal, utilice siempre el plugin’s setChannel() método.

Versión mínima para cambiar de canal solo en local: 5.34.0, 6.34.0, 7.34.0, o 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, ya sea X 5, 6, 7 o 8). Consulte instalación de plugin para etiquetas de versión.

Asignar un Paquete a un Canal

Para desplegar una actualización en vivo, debes subir una nueva construcción de paquete de JS y asignarla a un canal. Puedes 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á la nueva construcción como la versión activa para el Development canales. Cualquier aplicación configurada para escuchar ese canal recibirá la actualización la próxima vez que la busque.

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 tu aplicación, no específicos de canales individuales. El mismo paquete puede asignarse a varios canales.

Al versionar tus paquetes, recomendamos utilizar la versión semántica con el Tester de Semver de Capgo y identificadores de pre-lanzamiento para compilaciones específicas de canales. Por ejemplo, un lanzamiento beta podría versionarse como 1.2.3-beta.1.

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 incremente desde el paquete vinculado del canal hasta encontrar un nombre libre. aiWorkers AI infiere el nivel desde el delta local vs el delta anterior del manifiesto (cae en la versión anterior de __CAPGO_KEEP_0__). No puedes combinarlo con . Consulta la . patch y la referencia de Capgo --bundleEsta aproximación tiene varios beneficios: Comunica claramente la relación entre las compilaciones. obviamente es una versión previa de CLI reference.

Permite caminos de rollback claros. Si necesitas retroceder desde

• sabes 1.2.3-beta.1 CI/CD Integration 1.2.3.
• context
• Page/area: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Message key `native_build_feature_ci_cd` (Native Build Feature Ci Cd). 1.2.3and the 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 un conjunto de configuración típico 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.2etc.
• Production canal: 1.2.3, 1.2.4etc.

Usando semver con identificadores de versión previa es una aproximación recomendada, pero no estrictamente necesaria. 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 corona
3. Confirmar la acción

La compilación seleccionada se convertirá inmediatamente en la compilación activa para ese canal nuevamente. Las aplicaciones recibirán la versión revertida la próxima vez que revisen actualizaciones.

Automatizando Despliegues

Para flujos de trabajo más avanzados, puedes automatizar los despliegues de actualizaciones en vivo 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.

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

Previsualizaciones de PR con privilegios mínimos

Usar una Previsualización de Aplicación llave API cuando la CI necesite una canalización temporal por solicitud de extracción, pero no deba administrar canales existentes principales/por defecto. La llave 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 permisos de ciclo de vida automáticos, escalados por canal.

1. Tener un administrador de organización que cree una llave API segura limitada a la aplicación de previsualización y seleccione Previsualización de AplicaciónVer API Llaves.
2. Utilice un canal único y no público como pr-123No pase --default, --self-assign, opciones de lanzamiento, o --delete-linked-bundle-on-upload.
3. Suba y promueva el paquete de PR en una sola orden, y 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 crea un canal faltante, sube el paquete y lo promueve 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 y no compartido. No puede cambiar, promover o eliminar un canal principal o predeterminado existente, un canal de otra clave de vista previa, 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 configuraciones de la aplicación. En GitHub Actions, ejecute trabajos de vista previa que llevan secretos en pull_request, no pull_request_targety restringarlos 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. Lanza la aplicación y espera a que se actualice!

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

Uso Avanzado de Canales: Segmentación de Usuarios

Los canales se pueden utilizar para más que solo 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
• Implementación gradual de características
• Programas de pruebas beta

Aprenda 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á utilizando Canales para planificar la ruta de canal y el despliegue en etapas, conecte con 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 Versiones para el flujo de trabajo del producto en Solución de Versiones, 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.