Convirta 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 extracción directamente en el dispositivo, sin reinstalaciones ni retrasos en las tiendas de aplicaciones?

Es lo que Las vistas previas de PR habilitar. Cuando un desarrollador abre una solicitud de extracción, una acción GitHub 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 tienen.

El problema de TestFlight

El flujo de trabajo tradicional para probar características móviles se parece a esto:

1. Desarrollador abre PR - Code está listo para revisión
2. Espera a TestFlight - 15-30 minutos de tiempo de procesamiento
3. Encuentra e instala - Los probadores buscan la construcción correcta
4. Prueba y repite - Cada cambio significa otra espera

Esto crea una botella de cuello. La QA se bloquea esperando construcciones. 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.

How PR Previews Work

Las pruebas de PR utilizan el sistema de canal de Capgo para crear flujos de actualizaciones por PR.

1. Se abre o se actualiza una PR - Se activa la acción de GitHub
2. Se sube un paquete - Los cambios de JS/CSS van a un canal específico de PR
3. Se publica un comentario - Los probadores reciben instrucciones en la PR
4. Pruebas instantáneas - Cambiar de canal, probar, cambiar de nuevo

No se instalan nuevas aplicaciones. No hay retrasos en TestFlight. La misma aplicación de producción puede obtener actualizaciones de diferentes canales de actualización.

Configurando pruebas de PR

Antes de que puedas implementar vistas previas de PR, tu proyecto necesita estar configurado con Capgo Actualizaciones en vivo. Sigue el Capgo guía de inicio rápido si no lo has hecho ya.

GitHub flujo de trabajo de Acciones

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

Configurando el Capgo Token

1. Ve a tu Capgo panel de control
2. Navega a Configuración > API Claves
3. Genera una nueva clave con all permisos
4. Agrega como CAPGO_TOKEN en tu repositorio de secretos GitHub

Cómo los probadores cambian de canal

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

Opción 1: Menú de sacudida (Más sencillo)

Habilita el menú de sacudida con selector de canal en tu configuración 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-123), tocan para seleccionarlo y la aplicación descarga automáticamente y aplica la actualización. Cuando terminen de probar, sacuden de nuevo y cambian a producción.

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

1. Obtiene todos los canales autoasignables a través de listChannels()
2. Muestra canales con búsqueda para encontrar PRs específicas
3. Descarga la actualización después de la selección
4. Indica recargar con opciones "Recargar ahora" / "Más tarde"

Opción 2: Selector de canales 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 APIs clave:

• listChannels() - Obtiene todos los canales con autogeneració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 sobre navegación de canales.

Limpiar los 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 se cierra la solicitud de extracción, manteniendo tu lista de canales limpio.

Compatibilidad de Versión

Las vistas previas de solicitudes solo funcionan cuando el paquete de JavaScript es compatible con la versión nativa instalada. Si tu solicitud 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 solicitud de extracción apunta a una versión nativa diferente a la instalada, la actualización no se aplicará. Esto previene los errores de incompatibilidad code.

Para solicitudes que requieren cambios nativos, necesitarás distribuir una nueva versión de TestFlight/Play Store. Las vistas previas de solicitudes funcionan mejor para cambios de JavaScript, CSS y recursos que no tocan el código nativo code.

¿Quién se beneficia de las vistas previas de solicitudes?

Ingenieros de Pruebas

• contexto: Página/área: página de marketing de soluciones de Capgo. Rol: Etiqueta de IU corta o elemento de navegación. Visto en: página de soluciones/pr-preview.astro. Clave de mensaje `solutions_pr_preview_teams_qa` (Solutions Pr Preview Teams Qa).
• Prueba características de inmediato cuando se abren las solicitudes
• Pasa entre varias solicitudes sin reinstalar
• Verifica las correcciones y regresiones en dispositivos reales

No más espera por el procesamiento de TestFlight

• Revisa características antes de que se fusionen
• Dar retroalimentación directamente en la solicitud de revisión
• Verificar que la implementación coincide con los requisitos
• Reducir el tiempo de ciclo de revisión

Desarrolladores

• Obtener retroalimentación más rápida sobre cambios
• Demostrar características a partes interesadas de inmediato
• Depurar problemas con usuarios específicos
• Pasar menos tiempo gestionando versiones beta

Comparación: Versión tradicional vs Previsualizaciones de solicitudes de revisión

Prácticas recomendadas

1. Nombra los canales claramente: Utilice pr-{number} convención para una fácil identificación
2. Auto-borrado: Siempre elimine los canales cuando se cierren las PRs
3. Limitar acceso: Solo habilite el menú de sacudida en builds de depuración/producción
4. Documentar el proceso: Agregar instrucciones de prueba a tu plantilla de PR
5. Manejar las fallas con amabilidad: Verificar que la creación de canal tenga éxito antes de publicar comentarios

Cuándo No Usar Previsualizaciones de PR

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

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

Será necesario la distribución tradicional de TestFlight/Play Store para esos cambios.

Combinar con Surfing de Canales

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

• production - Lanzamientos estable para todos los usuarios
• beta - Acceso temprano para usuarios que opten por ello
• pr-123 - Pruebas 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

• Capgo Actualizaciones en vivo Documentación
• Documentación de canales
• Guía de navegación por canales
• CLI Referencia de comandos
• PR Preview Solutions Page

Conclusion

Las pruebas de PR transforman la forma en que su equipo revisa y prueba características móviles. En lugar de esperar al procesamiento 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 reciben 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 Turn Every Pull Request Into an Installable Preview

Si está utilizando Turn Every Pull Request Into an Installable Preview para planificar la ruta de canales y la implementación escalonada, conecte con Canalización context Capgo release channels feature name. Page/area: Capgo solutions marketing page. Role: Short UI label or navigation item. Seen in: page solutions/white-label.astro. Message key `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value). para el detalle de implementación en los canales, Canales para el detalle de implementación en los canales, Solución de Pruebas Beta para el flujo de trabajo del producto en la Solución de Pruebas Beta, y Solución de Alcance de Versión para el flujo de trabajo del producto en la Solución de Alcance de Versión.