Saltar al contenido principal
Vista previa de PR

Revisa cada pull request en un teléfono real

Tu CI sube el build web de cada pull request a su propio canal de Capgo. Los revisores escanean un código QR code o cambian de canal en la app para probarlo en su dispositivo, y el canal se elimina al cerrar el PR. Los cambios en el code nativo aún necesitan un nuevo build.

  • Un canal por cada pull request
  • Vista previa de QR code
  • Limpieza automática al cerrar el PR

El problema

Un cambio web no debería requerir un nuevo binario para ser revisado

Revisar un PR con builds de testing de la tienda

  1. El desarrollador abre un PR

    El cambio está listo para revisión, pero nadie puede probarlo en un móvil todavía.

  2. Build, sign y upload

    Alguien genera un binario nativo para la rama, lo firma, lo sube a TestFlight o a un track de testing de Play y espera el procesamiento.

  3. Invitar e instalar

    Hay que añadir a los revisores como testers e instalar ese build exacto.

  4. Repetir por cada fix

    Cada comentario de revisión que cambie code implica otro build, otro upload y otra instalación.

Cada ronda de revisión depende de un Native Build, incluso si solo cambió JavaScript.

El coste real para el equipo

Cada build

Espera el procesamiento de la tienda

Cada build que subas a TestFlight o a una vía de pruebas de Play se procesa antes de que los testers puedan instalarla. Esto ocurre con cada build.

Cada PR

Requiere su propio Native Build para probar

Sin Live Update, los revisores solo pueden probar una rama después de que alguien haga el build, firme y suba un nuevo binario, incluso para cambios solo de web.

Feedback tardío

La revisión llega cuando el autor ya avanzó

Cuando la revisión depende de los builds, el feedback llega tarde, el autor ya está en otra tarea y la rama se desvía de main.

Cómo funciona

Cómo los equipos previsualizan pull requests con Capgo

Cuatro pasos de CI: configura una clave una vez, sube por cada push, comparte la preview y limpia al cerrar. Cada comando es de la documentación de Capgo.

  1. Crea una clave de App Preview y activa las previews

    Un admin crea una clave API de App Preview para CI. Puede crear canales de preview y subir bundles, pero no puede cambiar tu canal por defecto o de producción. Las previews se activan una vez por app.

    # once, run by an admin (not the preview key)
npx @capgo/cli@latest app set com.example.app --preview
    Claves API de App Preview

  2. Sube el build del PR a su propio canal

    En cada push, el CI construye la web app y la sube con una versión de bundle única. bundle upload --channel crea el canal pr-<number> si no existe y vincula el bundle a él.

    npx @capgo/cli@latest bundle upload com.example.app \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "pr-$PR_NUMBER" \
  --bundle "1.2.3-pr.$PR_NUMBER.$GITHUB_RUN_NUMBER"
    Previews de PR en la docs de canales

  3. Publica la preview en el PR

    get-qr imprime un code QR para el canal, o las URLs de preview con --url, para que el CI pueda añadirlas a un comentario del PR.

    npx @capgo/cli@latest get-qr com.example.app \
  --channel "pr-$PR_NUMBER" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --url
    Referencia de get-qr

  4. Elimina el canal cuando se cierre el PR

    Ejecuta esto en el evento de pull request cerrado. Con una clave de App Preview, solo elimina el canal y el bundle vinculado que esa clave creó.

    npx @capgo/cli@latest channel delete \
  "pr-$PR_NUMBER" com.example.app \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found
    Referencia CLI del canal

Otras formas de cambiar a un channel de PR

Ambos requieren un channel con self-assignment. Una App Preview key no lo activa; con esa key, comparte el QR o usa un device override en la consola.

Menú de agitación

Activa el menú de agitación en builds internos. Los testers agitan el dispositivo para abrir el menú de pruebas de Capgo, y el selector de canales les permite elegir uno.

// capacitor.config.ts (internal builds)
CapacitorUpdater: {
  shakeMenu: true,
}

Selector in-app

Añade un campo de canal a la pantalla de ajustes y llama a setChannel() con el nombre del canal del PR.

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

await CapacitorUpdater.setChannel({
  channel: 'pr-123',
  triggerAutoUpdate: true,
})
Referencia de setChannel()

Quiénes usan PR previews

Cualquiera que revise el pull request puede probarlo en un móvil, no solo el autor.

Ingenieros de QA

  • Prueba el web build del PR en tu propio dispositivo
  • Cambia entre canales de PR sin reinstalar la app
  • El nombre del canal coincide con el número del PR, así sabes qué code estás ejecutando

Project Managers

  • Prueba una feature en el móvil antes de que se haga el merge
  • Escanea el QR code publicado en el PR
  • Deja feedback en el propio PR

Desarrolladores

  • Recibe feedback del dispositivo mientras el PR sigue abierto
  • Cada push actualiza el canal del PR
  • Sin Native Build para cambios solo en JS

Builds de prueba de stores vs canales de PR Capgo

  • Llevar un PR a un teléfono

    Pruebas en TestFlight / Play
    Native Build, signing y procesamiento de la store
    Canal de PR Capgo
    Web build y upload de bundle desde CI

  • Cambiar entre PRs

    Pruebas en TestFlight / Play
    Instalar otro build
    Canal de PR Capgo
    Escanea otro QR code o cambia de canal

  • Configuración del revisor

    Pruebas en TestFlight / Play
    Invita al tester e instala cada build
    Canal de PR Capgo
    Instala la app una vez

  • Cambios en code nativo y en plugins

    Pruebas en TestFlight / Play
    Sí
    Canal de PR Capgo
    No, requiere un Native Build

Soluciones por tipo de equipo

Encuentra la solución que se adapte a tu equipo

Enterprise

Despliegues multiapp y multiequipo

Startups

Lanza rápido y sin complicaciones

Desarrolladores individuales

Prueba gratuita de 14 días, CLI upload

Agencias

Gestiona múltiples apps de clientes

Apps creadas con Capacitor

Las apps de producto requieren cambios móviles revisables

Las apps de aprendizaje, eventos y comunidad pueden tener a la vez cambios en onboarding, práctica, sesiones en vivo y suscripciones bajo revisión. Los PR previews permiten que producto, QA y soporte revisen un build listo para móvil antes del merge.

StudySmarter - Icono de la app de escuela y universidad EDUCACIÓN

StudySmarter - Escuela y uni

App educativa donde cambios en lecciones, cursos y suscripciones requieren revisión.

Instalaciones en Google Play
6.5M
Calificación en la tienda
4.8
Icono de la app Poll Everywhere NEGOCIOS

Poll Everywhere

App de alto engagement donde los flujos de eventos deben probarse antes del merge.

Instalaciones en Google Play
1.1M
Calificación en la tienda
3.2
lichess • Icono de la app gratuita de ajedrez online TABLERO DE JUEGO

lichess • Ajedrez online gratuito

App comunitaria donde las pantallas de torneos y análisis aprovechan los device previews.

Instalaciones en Google Play
11.3M
Calificación en la tienda
4.3

Testimonios de clientes

Lo que dicen los equipos que publican con Capgo

5.0/5 valorado por equipos de desarrollo 9,400+ equipos Leer reseñas

Nate van Jole

CTO, Privado

&ldquo;La configuración tomó menos de un día. Los rollouts por canales me permiten probar en mi propio dispositivo antes de lanzarlo a producción.&rdquo;

Retrato de Michael Haberler

Michael Haberler

nethead emeritors

“Buen trabajo con el plugin de actualizaciones. Me funciona de maravilla y las live updates son un gran acelerador para agilizar las pruebas.”

no-tone @ Webincode

Desarrollador, Webincode

&ldquo;Poder añadir Device IDs a grupos concretos y enviar los cambios solo a esos grupos es un salvavidas.&rdquo;

FAQ

Preguntas frecuentes sobre PR previews

Respuestas claras para quienes configuran el CI y para quienes revisan.

¿Necesitan los revisores un nuevo build para cada PR?

No cuando el PR solo cambia la capa web. Los revisores instalan la app una vez, y el JS, HTML, CSS y assets de cada PR van a su propio channel. Si el PR añade un plugin o cambia el code nativo, requiere un Native Build. Ejecuta un build necesario en el CI para detectarlo.

Qué necesita un build nativo

¿Puede la clave del CI tocar nuestro channel de producción?

No con una clave de App Preview API. Puede crear preview channels, hacer upload de bundles y borrar solo el channel y bundle que creó. No puede cambiar el channel principal o por defecto. En GitHub Actions, ejecuta el job en pull_request, no en pull_request_target, y limítalo a PRs del mismo repositorio.

Claves de App Preview API

¿Cómo abren la preview los revisores?

Un admin habilita las previews una vez con app set --preview. Después, get-qr imprime un QR code para el PR channel, y --url imprime la URL de la web preview y el deep link. Publícalos en un comentario del PR.

Referencia de get-qr

¿Qué pasa con los canales y bundles antiguos de los PR?

Añade un job en el evento pull request closed que ejecute channel delete con --delete-bundle y --success-if-not-found. Con una clave de App Preview, eso elimina el channel y el bundle vinculado. Los bundles de pushes anteriores pueden eliminarse con bundle cleanup, usando una clave con permisos de borrado.

referencia al canal CLI

¿Funciona con GitLab, Bitbucket o Azure DevOps?

Sí. Los pasos son Capgo CLI comandos, así que corren en cualquier CI. La documentación incluye guías de integración para GitHub Actions, GitLab CI, Bitbucket Pipelines y Azure DevOps.

Integraciones de CI/CD

Previsualiza tu próximo pull request en un móvil

Añade los pasos de upload, QR y cleanup a tu CI y pruébalos en tu propia app durante el free trial.

Prueba gratuita de 14 días, sin tarjeta. Los cambios nativos requieren un nuevo build.