Vuelva a cada solicitud de extracción en una vista previa instalable

Cada equipo de desarrollo móvil ha sentido el dolor: una característica está lista para la revisión, pero hacer que llegue a las manos de las partes interesadas significa navegar por el laberinto de revisión de TestFlight o Google Play beta. Lo que debería tomar minutos se convierte en horas de espera, instalación y gestión de versiones beta.

¿Y si su aplicación de producción pudiera extraer los últimos cambios de cualquier solicitud de revisión directamente en el dispositivo, sin reinstalaciones ni retrasos en la tienda de aplicaciones?

Eso es lo que Las vistas previas de PR permiten. Cuando un desarrollador abre una solicitud de revisión, una GitHub Acción crea un canal de actualización dedicado y publica los cambios. Cualquiera con la aplicación instalada puede cambiar a ese canal, probar la característica y cambiar de nuevo - todo sin dejar la aplicación que ya tiene.

El problema de TestFlight

The traditional workflow for testing mobile features looks something like this:

El desarrollador abre PR - Code está listo para revisión
Espera a TestFlight - 15-30 minutos de tiempo de procesamiento
Encuentra e instala - Los probadores buscan la versión correcta
Prueba y repite - Cada cambio significa otra espera

Esto crea una botella de cuello. QA se bloquea esperando versiones. Los gerentes de producto no pueden verificar características rápidamente. Los desarrolladores pierden contexto mientras esperan retroalimentación. La industria estima que esto cuesta alrededor de $340 por PR en productividad perdida.

Cómo funcionan las vistas previas de PR

Las vistas previas de PR utilizan el sistema de canales de Capgo para crear flujos de actualizaciones por PR. Aquí está el flujo:

PR abierto o actualizado - GitHub Acciones desencadenantes
Paquete subido - Sus cambios de JS/CSS van a un canal específico de PR
Comentario publicado - Los probadores obtienen instrucciones en el PR
Pruebas instantáneas - Cambia de canales, prueba, cambia de nuevo

Sin nuevas instalaciones de aplicaciones. Sin retrasos de TestFlight. La misma aplicación de producción puede obtener actualizaciones de diferentes canales de actualizaciones.

Configuración de Previsualizaciones de PR

Antes de que puedas implementar las previsualizaciones de PR, tu proyecto necesita estar configurado con Capgo Actualizaciones en vivo. Sigue el Capgo guía rápida de inicio Si no lo has hecho ya.

GitHub Acciones de flujo de trabajo

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 a los probadores cambiar al canal desde dentro de la aplicación utilizando el setChannel() API.

Configuración de Capgo Token

Ir a tu Capgo panel de control
Navega a Configuración > API Claves
Genera una nueva clave con all permisos
Añádelo como CAPGO_TOKEN en tus secretos de repositorio GitHub

Cómo los probadores cambian de canal

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

Habilita el menú de sacudida 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 probadores sacuden 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 (por ejemplo, pr-123tapan para seleccionarlo y la aplicación descarga y aplica automáticamente la actualización. Cuando terminen de probar, sacuden de nuevo y cambian a producción.

El menú de sacudida maneja todo el flujo automáticamente:

Obtiene todos los canales autoasignables mediante listChannels()
Muestra canales con búsqueda para encontrar PR específicos
Descarga la actualización después de la selección
Prompts a recarga con opciones de ‘Recargar ahora’ / ‘Más tarde’

Opción 2: Selector de canal personalizado

Construye un selector de canales en tu aplicación que enumere los canales de PR disponibles y permita a los probadores elegir uno. Esto utiliza dos claves API:

listChannels() - Obtiene todos los canales con autogeneración de asignació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 interfaz de usuario 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 componente de React, consulta nuestro artículo de navegación de canales.

Limpiar Canales de PR

Cuando un PR se fusiona o cierra, querrás limpiar el canal. Agrega otro flujo de trabajo:

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 el PR se cierra, manteniendo tu lista de canales limpia.

Compatibilidad de Versión

Los previews de PR solo funcionan cuando el paquete de JavaScript es compatible con la versión nativa instalada. Si su PR incluye cambios nativos code (nuevos plugins Capacitor, modificaciones de iOS/Android), los probadores necesitarán una nueva compilación nativa.

Capgo verifica automáticamente la compatibilidad de versiones. Si el paquete de una PR apunta a una versión nativa diferente a la instalada, la actualización no se aplicará. Esto previene los errores de incompatibilidad code.

Para PRs que requieren cambios nativos, necesitará distribuir una nueva compilación de TestFlight/Play Store. Los previews de PR funcionan mejor para cambios de JavaScript, CSS y activos que no tocan la code nativa.

¿Quién se beneficia de los Previews de PR

Ingenieros de Pruebas

Verifique características de inmediato cuando se abren PRs
Pase entre múltiples PRs sin reinstalar
Verifique las correcciones y regresiones en dispositivos reales
No más espera por el procesamiento de TestFlight

Gerentes de Producto

Revisar características antes de que se fusionen
Proporcione retroalimentación directamente en el PR
Verifique que la implementación se ajusta a los requisitos
Reducir el tiempo de revisión

Desarrolladores

Obtenga retroalimentación más rápida sobre los cambios
Demostrar características a los stakeholders de inmediato
Depurar problemas con usuarios específicos
Pasen menos tiempo gestionando versiones beta

Comparación: Versión tradicional vs Previsualización de PR

Aspecto	TestFlight/Beta	Capgo Previsualización de PR
Tiempo de compilación	15-30 min	<1 min
Cambiar PRs	5+ min reinstallar	10 segundos
Complejidad de configuración	Credenciales de la Tienda de Aplicaciones	Un archivo de flujo de trabajo
Limpieza	Manual	Automático
Cambios nativos code	Requerido	Opcional (solo JS)

Prácticas recomendadas

Nombra los canales claramente: Utilice pr-{number} convención para una fácil identificación
Auto-borrado: Siempre elimine los canales cuando se cierren PRs
Limitar el acceso: Solo habilite el menú de sacudir en compilaciones de depuración/producción
Documente el proceso: Agregue instrucciones de prueba a su plantilla de PR
Administre fallas con gracia: Verifique que la creación del canal tenga éxito antes de publicar comentarios

Cuándo No Usar Previsualizaciones de PR

Las previsualizaciones de PR son para cambios de JavaScript/CSS. Si su PR incluye:

Nuevos Capacitor plugins
Cambios nativos de iOS code
Cambios nativos de Android code
Actualizaciones de dependencias que afectan compilaciones nativas

Necesitará distribución tradicional de TestFlight/Play Store para esos cambios.

Combinar con Channel Surfing

Las previsualizaciones de PR funcionan mejor cuando se combinan con navegación por canales. Su aplicación puede tener:

production - Lanzamientos estables para todos los usuarios
beta - Acceso temprano para usuarios que opten por ello
pr-123 - Previsualizaciones de características para PR específicos

Los probadores con compilaciones de producción pueden cambiar a cualquier canal de PR, probar la característica, luego cambiar de nuevo - todo con la misma aplicación instalada.

Recursos

Conclusión

Las pruebas de versión previa transforman la forma en que su equipo revisa y prueba características móviles. En lugar de esperar a que se procesen las pruebas de TestFlight y gestionar múltiples versiones beta, los probadores pueden cambiar a cualquier canal de PR en segundos utilizando la aplicación que ya tienen instalada.

La configuración es mínima - un archivo de flujo de trabajo GitHub Actions - y los beneficios se acumulan en su equipo. La QA permanece sin bloqueos, los gerentes de producto revisan más rápido y los desarrolladores obtienen retroalimentación más rápida.

Comience agregando el flujo de trabajo a un repositorio y vea cómo cambia su proceso de revisión.

Siga adelante desde 'Convirta cada solicitud de extracción en una vista previa instalable'.

Si está utilizando Convirtir cada solicitud de extracción en una vista previa instalable para planificar la ruta de canales y la implementación de un despliegue en etapas, conecte esto con Canal para los detalles de implementación en Canal Canal para los detalles de implementación en Canal Canal para los detalles de implementación en Channels, Solución de Pruebas Beta para el flujo de trabajo del producto en Solución de Pruebas Beta, y Solución de Enfoque de Versión para el flujo de trabajo del producto en Solución de Enfoque de Versión.

Convierta Cada Solicitud de Revisión en una Vista Previa Instalable