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 las actualizaciones, no la secrecía de los 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 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 forzosa de dispositivo (Panel de control) – Asigne manualmente un ID de dispositivo específico a un canal. Utilice para depuración urgente o pruebas controladas con un solo usuario real. Esto siempre gana. Capgo elimina la asignación 90 días después de la última escritura de sobrescritura. Consulte Console y API sobrescriben expiran después de 90 días.
2. Sobrescritura de nube (por dispositivo) a través del Panel de control 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 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 su 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 tener que 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 si un canal se vuelve inaceptable después de haberse establecido localmente, el servidor aún validará el canal durante las verificaciones de actualizaciones, por lo que se mantiene la seguridad.

Importante: Cuando se realizan cambios en los canales 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 comienza en este canal (por ejemplo, beta, qa, pr-123Intendido para versiones de prueba / builds internos para que los probadores aterricen en un canal de pre-lanzamiento automáticamente. Los builds 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 override de la consola/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 / pruebas; 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).
• Solo 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 Cloud.

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

Forced mappings and Dashboard or Public API channel overrides are stored as per-device assignments in Capgo. A cleanup job deletes those assignments 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 el timestamp.

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: fragmento de texto HTML de una cadena de Capgo UI más larga (clave de padre `appflow_migration_step2`). Página/área: Comparación y migración de Appflow / marketing de copia de página. Rol: Oración de copia de sitio web. Visto en: página ionic-appflow.astro. Preservar términos de producto/marca y términos de desarrollador exactamente. Clave de mensaje `appflow_migration_step2` (Paso 2 de la 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, se 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 el dispositivo de Override UI solo lista la consola y las asignaciones públicas API. No listan todos los dispositivos del canal, y no listan los dispositivos locales setChannel() Asignaciones.

Nota de retención de Override en la pantalla de dispositivos del canal.

Comportamiento del canal por defecto

Establecer un valor por defecto en la nube 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 elijas marcar valores por defecto, ten 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í. Configuración de valor por defecto único
• 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

Gestionar en ajustes de la aplicación Configuración específica de plataformawhich 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 que escuche el canal adecuado. En este ejemplo, utilizaremos el Development canal.

Abre tu capacitor.config.ts archivo (o capacitor.config.json) en el editor. En la sección plugins opcionalmente establece defaultChannel para edición de pruebas (internacional / QA). Para compilaciones 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, compila 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: Fuerza > Configuración del dispositivo API > Plugin > Canal local > Configuración > Valor por defecto de Cloud. setChannel() Usar defaultChannel Usa solo en compilaciones de prueba/internas; omítelo 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 routing en la configuración nativa.

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

Siguiente, compila tu aplicación web y ejecuta

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

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 conectan a. En la consola, esto vive en la información de la aplicación (Gestione en ajustes de la aplicación desde la página del canal). Consulte “Comportamiento del canal predeterminado” para escenarios de enrutamiento.
• Filtros de plataforma: Activa o desactiva 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).
• Permitir actualizaciones de compilación de desarrollo: Permita actualizaciones a compilaciones de desarrollo (útil para pruebas). 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, 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

Una canalización puede mantener una paquete estable mientras expone gradualmente un objetivo de lanzamiento separado a un grupo de dispositivos adheridos. Ver for the delivery model, dashboard workflow, API fields, and CLI commands.

para el modelo de entrega, flujo de trabajo de la consola, campos __CAPGO_KEEP_0__ y comandos __CAPGO_KEEP_1__.

Sección titulada “Desactivar estrategias de actualización automática”

• Utilice esto para restringir qué tipos de actualizaciones la canalización entregará automáticamente. Opciones:version_buildmayor: Bloquea un paquete objetivo cuya versión mayor es superior a la base de línea nativa del dispositivo ( 1.2.3 -> 2.0.0 Ejemplo: 1.2.3 -> 1.9.0 está bloqueado;
• está permitido. version_buildmenor: Bloquea un paquete objetivo cuya versión mayor o menor difiere de 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.
• se permiten todas las actualizaciones según la compatibilidad de semver o.

Estas estrategias comparan el paquete objetivo del canal con la base de línea 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/#desactivar-estrategia-de-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 Tu Aplicación

El setChannel() 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 en el programa de beta
• Implementaciones de banderas de características
• Escenarios de prueba 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 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 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 antiguas, setChannel() guardaba la sobrescritura del canal en la base de datos del servidor (igual que Dashboard o API cambios). Los dispositivos tenían que esperar a la replicación del servidor (hasta 2 minutos) antes de que el cambio de canal tuviera efecto. Ahora, setChannel() solamente lee de la base de datos del servidor (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 una sobrescritura de dispositivo en la Capgo UI. Solo las asignaciones de canal creadas desde la consola de administración o el API público están listadas allí. Utilice la consola de administración o API cuando necesite una sobrescritura visible para los administradores.

Nota de seguridad: Even si los permisos de un canal cambian después de ser configurado localmente (por ejemplo, la autoasignación está deshabilitada), el servidor aún 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	Ubicación persistente	Mostrado en la interfaz de usuario de sobrescritura de dispositivo	Vence	Uso de caso
setChannel() Desde plugin	Inmediato	Solo en el dispositivo (local)	No	No (hasta que cambies o reinstales)	Switch de canal iniciado por el usuario en la aplicación
Opción de sobrescritura de dispositivo en la consola	Hasta 2 min	Base de datos de backend	Sí	90 días después de la última escritura de override	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 override	Integraciones de backend automatizadas

Para la mejor experiencia del usuario al crear interfaces de usuario de cambio de canal, siempre utilice 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 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 construcció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 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 múltiples canales.

Al versionar tus paquetes, recomendamos utilizar la versión semántica con el Capgo Tester de Semver y identificadores de prelanzamiento para compilaciones específicas de canal. Por ejemplo, una versión de prueba 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. Con ai, Workers AI infiere el nivel desde el delta local vs el delta anterior del manifiesto (cae en la versión previa de __CAPGO_KEEP_0__). No puedes combinarlo con . Consulta la sección de 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 y la integración de CI/CD 1.2.3.
• y la integración de CI/CD
• y la integración de CI/CD 1.2.3y la integración de CI/CD 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 las 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 hagas push 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 una clave de API cuando la CI necesite una canalización temporal por solicitud de extracción, pero no deba gestionar los canales existentes principales/por defecto. La clave sigue unida a la organización propietaria y la aplicación seleccionada; simplemente no tiene ningún 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 la organización que cree una clave de API segura limitada a la aplicación de previsualización y seleccione Previsualización de AplicaciónVer Claves de API.
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, 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 solo puede eliminar 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 otro teclado 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 de configuración de la aplicación. En GitHub Actions, ejecute trabajos de vista previa con 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 pueden usarse 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ás 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 para el entorno: Estadío con un ID de aplicación móvil para el contexto práctico en Capgo Prácticas recomendadas para el entorno: Estadío con un ID de aplicación móvil.