Todos los equipos de desarrollo móvil han sentido el dolor: una característica está lista para la revisión, pero hacer que llegue a las manos de los interesados significa navegar por el laberinto de revisiones de beta de TestFlight o Google Play. Lo que debería tomar minutos se convierte en horas de espera, instalación y gestión de compilaciones de 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 ninguna reinstalación o retrasos en la tienda de aplicaciones?
Eso es lo que vistas previas de PR habilitan. Cuando un desarrollador abre una solicitud de revisió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:
- Desarrollador abre PR - Code está listo para la revisión
- Espera a TestFlight - 15-30 minutos de tiempo de procesamiento
- Encuentra e instala - Los probadores buscan la construcción correcta
- Prueba y repite - Cada cambio significa otra espera
Esto crea una botella de cuello. QA se bloquea esperando construcciones. Los gerentes de producto no pueden verificar rápidamente las características. 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 canal de Capgo para crear flujos de actualizaciones por PR. Aquí está el flujo:
- Se abre o se actualiza un PR - Se activa la acción de GitHub
- Se sube un paquete - Sus cambios de JS/CSS van a un canal específico de PR
- Comentario publicado - Los probadores reciben instrucciones en el PR
- Prueba instantánea - Cambiar canales, 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.
Configuración de vistas previas de PR
Antes de que puedas implementar vistas previas de PR, tu proyecto debe estar configurado con Capgo Actualizaciones en vivo. Sigue el Capgo guía rápida 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 el --self-assign indicar un canal 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
- Vaya a su Capgo dashboard
- Navegue a Configuración > API Claves
- Generar una nueva clave con
allpermisos - Agregarla como
CAPGO_TOKENen sus secretos de repositorio GitHub
Cómo los probadores cambian de canales
Hay dos formas en que los probadores pueden cambiar a un canal de PR:
Opción 1: Menú de Sacudida (Más Simple)
Habilite el menú de sacudida con selector de canal en su 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-123), tocan para seleccionarlo y la aplicación descarga y aplica automáticamente la actualización. Cuando terminan de probar, sacuden de nuevo y vuelven a la producción.
El menú de sacudida maneja el flujo completo 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
- Indica para recargar con opciones de “Recargar Ahora” / “Más Tarde”
Opción 2: Selector de Canal Personalizado de IU
Construya un selector de canal en su aplicación que muestre los canales de PR disponibles y permita a los probadores elegir uno. Esto utiliza dos APIs clave:
listChannels()- Obtiene todos los canales con autoasignación habilitadasetChannel()- 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 React, consulta nuestro artículo sobre la navegación por canales.
Limpiar los canales de PR
Cuando se fusiona o cierra un PR, 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 el PR, manteniendo tu lista de canales limpia.
Compatibilidad de versiones
Las vistas previas de PR solo funcionan cuando el paquete de JavaScript es compatible con la versión nativa instalada. Si tu 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 un 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 los PR que requieren cambios nativos, necesitarás distribuir una nueva versión de TestFlight/Play Store. Las vistas previas de PR funcionan mejor para cambios en JavaScript, CSS y activos que no tocan el código nativo code.
¿Quién se beneficia de las vistas previas de PR
Ingenieros de Pruebas
- Prueba características de inmediato cuando se abren PRs
- Alternar entre múltiples PRs sin reinstalar
- Verificar arreglos 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
- Dar retroalimentación directamente en el PR
- Verificar que la implementación coincide con los requisitos
- Reducir el tiempo del ciclo de revisión
Desarrolladores
- Obtener retroalimentación más rápida sobre los cambios
- Demostrar características a los stakeholders de inmediato
- Depurar problemas con usuarios específicos
- Reducir el tiempo dedicado a la gestión de versiones beta
Comparación: Versión tradicional vs Previsualizaciones de PR
| Aspecto | TestFlight/Beta | Capgo Previsualización de PR |
|---|---|---|
| Tiempo de compilación | 15-30 min | <1 min |
| Cambiar entre PRs | 5+ min reinstalar | 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
- Nombrar los canales con claridad: Utilice
pr-{number}convenio para identificación fácil - Auto-limpieza: Siempre elimine los canales cuando se cierren las PR
- Limitar el acceso: Habilitar solo el menú de sacudida en compilaciones de depuración/producción
- Documentar el proceso: Agregue instrucciones de prueba a su plantilla de PR
- Manejar las fallas con gracia: Verifique que la creación de canales tenga éxito antes de publicar comentarios
No usar vistas previas de PR
Las vistas previas de PR son para cambios de JavaScript/CSS. Si su PR incluye:
- Nuevo Capacitor plugins
- Cambios nativos de iOS code
- Cambios nativos de Android code
- Actualizaciones de dependencias que afectan compilaciones nativas
Para esos cambios, necesitará distribución tradicional a través de TestFlight/Play Store.
Combina con Channel Surfing
Las vistas previas de PR funcionan mejor cuando se combinan con navegación por canales. Su aplicación puede tener:
production- Lanzamientos estables para todos los usuariosbeta- Acceso temprano para usuarios que opten por ellopr-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
- Página de soluciones de vistas previas de PR
Conclusión
Las vistas previas 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 compilaciones de 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 - 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 [Turn Every Pull Request Into an Installable Preview](https://capgo.io/es/blog/turn-every-pr-into-installable-preview/)
If you are using Turn Every Pull Request Into an Installable Preview para planificar la ruta de canalización 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, 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, y Solución de Alcance de Versión para el flujo de trabajo del producto en la Solución de Alcance de Versión.