Convierte cada Pull Request en una preview instalable

Todos los equipos de desarrollo móvil han sentido este dolor: una funcionalidad está lista para revisión, pero ponerla en manos de los interesados implica navegar por el laberinto de revisión de TestFlight o las betas de Google Play. Lo que debería tomar minutos se convierte en horas de espera, instalación y gestión de builds beta.

¿Y si tu app de producción pudiera obtener los últimos cambios de cualquier pull request directamente en el dispositivo, sin reinstalaciones ni demoras de la app store?

Es lo que Previews de PR habilitar. Cuando un desarrollador abre un pull request, una GitHub Action crea un canal de actualización dedicado y publica los cambios. Cualquier persona con la app instalada puede cambiar a ese canal, probar la funcionalidad y volver - todo sin salir de la app que ya tiene.

El problema de TestFlight

El flujo de trabajo tradicional para probar funcionalidades móviles se ve así:

El desarrollador abre el PR - Code está listo para revisión
Esperar por TestFlight - 15-30 minutos de tiempo de procesamiento
Buscar e instalar - Los testers buscan el build correcto
Probar y repetir - Cada cambio implica otra espera

Esto crea un cuello de botella. QA se bloquea esperando builds. Los product managers no pueden verificar funciones rápidamente. Los desarrolladores pierden contexto mientras esperan feedback. La industria estima que esto cuesta alrededor de $340 por PR en productividad perdida.

Cómo funcionan las PR Previews

Las PR previews usan el sistema de canales de Capgo para crear flujos de actualización por PR. Este es el flujo:

Se abre o actualiza un PR - Se activa la Action de GitHub
Bundle subido - Tus cambios de JS/CSS van a un canal específico del PR
Se publica un comentario - Los testers reciben instrucciones en el PR
Testing instantáneo - Cambia de canal, testea y vuelve al anterior

Sin nuevas instalaciones. Sin retrasos de TestFlight. La misma app de producción puede descargar actualizaciones de distintos canales.

Configuración de PR Previews

Antes de poder implementar previews de PR, tu proyecto debe estar configurado con Capgo Live Updates. Sigue la guía de inicio rápido de Capgo si aún no lo has hecho.

Workflow de GitHub Actions

Crear .github/workflows/pr-preview.yml:

name: PR Preview
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Setup Bun
        uses: oven-sh/setup-bun@v2

      - name: Install Dependencies
        run: bun install

      - name: Build
        run: bun run build

      # Create a channel named after your PR (may already exist on synchronize)
      - name: Create PR Channel
        id: create_channel
        continue-on-error: true
        run: bunx @capgo/cli@latest channel add pr-${{ github.event.pull_request.number }} --self-assign
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

      # Upload the build to that channel
      - name: Upload to Capgo
        run: bunx @capgo/cli@latest bundle upload --channel pr-${{ github.event.pull_request.number }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

      # Post a comment with testing instructions (only on PR open)
      - name: Comment on PR
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.pull_request.number }},
              body: '📱 **Test this PR on device:**\n\nOpen your app and switch to channel: `pr-${{ github.event.pull_request.number }}`\n\nUse the shake menu or call `setChannel()` from your app.'
            })

La clave es el --self-assign flag al crear el canal. Esto permite que los testers cambien al canal desde la app usando el setChannel() API.

Configuración del token de Capgo

Ve a tu Dashboard de Capgo
Ve a Settings > API Keys
Genera una nueva clave con all permisos
Añádela como CAPGO_TOKEN en los secretos de tu repositorio de GitHub

Cómo los testers cambian de canal

Hay dos formas para que los testers cambien a un canal de PR:

Habilita el menú de agitación con selector de canal en tu configuración de Capacitor:

// capacitor.config.ts
const config: CapacitorConfig = {
  // ... your other config
  plugins: {
    CapacitorUpdater: {
      shakeMenu: true,
      allowShakeChannelSelector: true
    }
  }
};

Los testers agitan su dispositivo para abrir el menú de depuración, que muestra una lista de canales disponibles con una barra de búsqueda. Encuentran su canal de PR (p. ej., pr-123), lo tocan para seleccionarlo y la app descarga y aplica la actualización automáticamente. Al terminar de probar, agitan de nuevo y vuelven a producción.

El menú de agitación gestiona todo el flujo automáticamente:

Obtiene todos los canales autoasignables mediante listChannels()
Muestra canales con búsqueda para encontrar PRs específicas
Descarga la actualización tras la selección
Solicita recargar con las opciones “Recargar ahora” / “Más tarde”

Opción 2: UI personalizada del selector de canal

Crea un selector de canales en tu app que liste los canales de PR disponibles y permita a los testers elegir uno. Esto usa dos APIs clave:

listChannels() - Obtiene todos los canales con autoasignación habilitada
setChannel() - Cambia el dispositivo al canal seleccionado

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Get all available channels (including PR channels)
async function getAvailableChannels() {
  const { channels } = await CapacitorUpdater.listChannels();

  // Filter to show only PR channels
  const prChannels = channels.filter(c => c.name.startsWith('pr-'));

  return prChannels;
}

// Switch to a specific PR channel
async function switchToChannel(channelName: string) {
  await CapacitorUpdater.setChannel({
    channel: channelName,
    triggerAutoUpdate: true  // Immediately check for updates
  });
}

// Return to production
async function switchBackToProduction() {
  await CapacitorUpdater.unsetChannel({});
}

// Get current channel
async function getCurrentChannel() {
  const { channel } = await CapacitorUpdater.getChannel();
  return channel;
}

Con estos bloques de construcción, puedes crear una UI simple:

// Example: List PR channels and let user select
const channels = await getAvailableChannels();
const current = await getCurrentChannel();

// Display channels in your UI
channels.forEach(channel => {
  console.log(`${channel.name} ${channel.name === current ? '(current)' : ''}`);
});

// When user selects a channel
await switchToChannel('pr-123');

Para un ejemplo completo de un componente de React, consulta nuestro artículo sobre channel surfing.

Limpieza de canales de PR

Cuando una PR se fusiona o cierra, querrás limpiar el canal. Añade otro workflow:

name: Cleanup PR Preview
on:
  pull_request:
    types: [closed]

jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - name: Delete PR Channel
        run: bunx @capgo/cli@latest channel delete pr-${{ github.event.pull_request.number }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

Esto elimina el canal cuando se cierra el PR, manteniendo tu lista de canales limpia.

Compatibilidad de versiones

Las previews de PR solo funcionan cuando el bundle de JavaScript es compatible con la versión nativa instalada. Si tu PR incluye cambios nativos de code (nuevos plugins Capacitor, modificaciones en iOS/Android), los testers necesitarán un nuevo build nativo.

Capgo comprueba automáticamente la compatibilidad de versiones. Si el bundle de un PR apunta a una versión nativa distinta de la instalada, la actualización no se aplicará. Esto evita crashes por code incompatibles.

Para los PR que sí requieran cambios nativos, tendrás que distribuir un nuevo build en TestFlight/Play Store. Las previews de PR funcionan mejor para cambios en JavaScript, CSS y assets que no toquen el code nativo.

Quiénes se benefician de las previews de PR

Ingenieros de QA

Testea funciones al instante al abrir un PR
Cambia entre múltiples PR sin reinstalar
Verifica fixes y regresiones en dispositivos reales
Olvídate de esperar el procesamiento de TestFlight

Responsables de producto

Revisa las features antes del merge
Da feedback directamente en el PR
Verifica que la implementación cumpla los requisitos
Reduce el tiempo de revisión

Desarrolladores

Recibe feedback más rápido sobre los cambios
Haz demos de features a stakeholders al instante
Debuguea issues con usuarios específicos
Dedica menos tiempo a gestionar builds beta

Comparativa: Tradicional vs PR Previews

Aspecto	TestFlight/Beta	Preview de PR de Capgo
Tiempo de build	15-30 min	< 1 min
Cambiar de PR	Reinstalación de 5+ min	10 segundos
Complejidad de setup	Credenciales de App Store	Un archivo de workflow
Limpiar	Manual	Automático
Cambios nativos de code	Obligatorio	Opcional (solo JS)

Buenas prácticas

Nombra los canales con claridad: Usa pr-{number} convención para identificar fácilmente
Auto-cleanup: Elimina siempre los canales al cerrar los PR
Limitar el acceso: Activa el menú de shake solo en builds de debug/staging
Documenta el proceso: Añade instrucciones de pruebas a tu plantilla de PR
Gestiona los fallos correctamente: Verifica que el canal se cree correctamente antes de publicar comentarios

Cuándo no usar PR Previews

Las previews de PR son para cambios en JavaScript/CSS. Si tu PR incluye:

Nuevos plugins de Capacitor
Cambios nativos de iOS en code
Cambios nativos de Android en code
Actualizaciones de dependencias que afectan a los builds nativos

Para esos cambios, necesitarás la distribución tradicional a través de TestFlight/Play Store.

Combinarlo con Channel Surfing

Las previews de PR funcionan mejor combinadas con cambiar de canal constantemente. Tu app puede tener:

production - Versiones estables para todos los usuarios
beta - Acceso anticipado para usuarios opt-in
pr-123 - Previews de features para PRs específicos

Los testers con builds de producción pueden cambiar a cualquier canal de PR, probar la feature y volver atrás, todo con la misma app instalada.

Recursos

Conclusión

Las previsualizaciones de PR transforman la forma en que tu equipo revisa y prueba funciones móviles. En lugar de esperar el procesamiento de TestFlight y gestionar múltiples builds beta, los testers pueden cambiar a cualquier canal de PR en segundos usando la app que ya tienen instalada.

La configuración es mínima: un archivo de workflow de GitHub Actions, y los beneficios se acumulan en todo el equipo. QA no se bloquea, los product managers revisan más rápido y los desarrolladores reciben feedback más ágil.

Comienza añadiendo el workflow a un repositorio y observa cómo cambia tu proceso de revisión.

Continuar desde Cómo convertir cada pull request en una preview instalable

Si estás usando Convierte cada Pull Request en una preview instalable para planificar el enrutamiento de canales y el despliegue gradual, conéctalo con Canales para los detalles de implementación en Channels, Canales para los detalles de implementación en Channels, Canales para los detalles de implementación en Channels, Solución de beta testing para el workflow del producto en la solución de beta testing, y Solución de segmentación por versión para el workflow del producto en la solución de segmentación por versión.