Your CI uploads each pull request's web build to its own Capgo channel. Reviewers scan a QR code or switch channels in the app to try it on their device, and the channel is deleted when the PR closes. Changes to native code still need a new build.
Apoyo humano de Martin
El Problema
El desarrollador abre un PR
El cambio está listo para ser revisado, pero nadie puede probarlo en un teléfono todavía
Construir, firmar y subir
Alguien crea un binario nativo para la rama, lo firma, lo sube a TestFlight o un canal de pruebas de Play, y espera a que se procese.
Invitar y instalar
Los revisores necesitan ser agregados como probadores e instalar esa construcción exacta
Repetir para cada arreglo
Cada comentario de revisión que cambia code significa otra construcción, otra subida, y otra instalación
Cada ronda de revisión espera a una construcción nativa, incluso cuando solo se cambió JavaScript
Cada compilación
Espera por el procesamiento de la tienda
Cada compilación que subas a TestFlight o un canal de pruebas de Play se procesa antes de que los testers puedan instalarla. Eso sucede con cada compilación.
Cada PR
Necesita su propia compilación nativa para probar
Sin actualizaciones en vivo, los revisores solo pueden probar una rama después de que alguien construya, firme y suba un nuevo binario, incluso para un cambio web solo.
Retraso en la retroalimentación
La revisión ocurre después de que el autor ha avanzado
Cuando la revisión espera a las compilaciones, la retroalimentación llega más tarde, el autor está en otra tarea y la rama se desvía de la principal.
Cómo funciona
Cuatro pasos de CI: establecer una clave de alcance una vez, subir por empuje, compartir la vista previa, limpiar en cierre. Cada comando a continuación proviene de los Capgo docs.
Un administrador crea una clave de vista previa de App API para CI. Puede crear canales de vista previa y subir paquetes, pero no puede cambiar su canal predeterminado o de producción. Las vistas previas se activan una vez por aplicación.
# once, run by an admin (not the preview key)
npx @capgo/cli@latest app set com.example.app --previewOn each push, CI construye la aplicación web y la sube con una versión de paquete única. bundle upload --channel crea el canal pr-<number> si no existe y enlaza el paquete con é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"imprime un código QR code para el canal, o las URL de previsualización con --url, para que la CI pueda agregarlas a un comentario de PR.
npx @capgo/cli@latest get-qr com.example.app \
--channel "pr-$PR_NUMBER" \
--apikey "$CAPGO_PREVIEW_KEY" \
--urlEjecutar esto en el evento de cierre de solicitud de extracción. Con una clave de vista previa de App, elimina solo el canal y el paquete enlazado 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-foundPara ambos, necesitan un canal que permita la autoasignación. Una clave de vista previa de App no establece eso, por lo que con esa clave, comparte la vista previa QR o establece un override de dispositivo en la consola.
Activa el menú de sacudida en compilaciones internas. Los probadores sacuden el dispositivo para abrir el menú de prueba de Capgo y el selector de canal de sacudida les permite elegir un canal.
// capacitor.config.ts (internal builds)
CapacitorUpdater: {
shakeMenu: true,
}Agrega un campo de canal a una pantalla de ajustes de desarrollador y llama a setChannel() con el nombre del canal de PR.
import { CapacitorUpdater } from '@capgo/capacitor-updater'
await CapacitorUpdater.setChannel({
channel: 'pr-123',
triggerAutoUpdate: true,
})Cualquiera que revise la solicitud de extracción puede verificarla en un teléfono, no solo el autor.
Encuentre la solución que se adapte a las necesidades de su equipo
Apps built with Capacitor
Las aplicaciones de aprendizaje, eventos y comunidad pueden tener cambios de inicio, práctica, sesión en vivo y suscripción bajo revisión al mismo tiempo. Los visores de PR permiten a los productos, QA y soporte inspeccionar una construcción móvil lista antes de la fusión.
EDUCACIÓN
Aplicación educativa donde los cambios de lección, curso y suscripción necesitan revisión de partes interesadas.
NEGOCIO
Aplicación de engagement en vivo donde los flujos de eventos deben ser probados antes de la fusión.
TABLERO DE AJEDREZ
Aplicación de comunidad donde las pantallas de torneos y análisis se benefician de vistas previas de dispositivos.
Prueba de clientes
Director Técnico, Privado
Me tomó menos de un día configurarlo. Los despliegues basados en canales me permitieron probar en mi dispositivo antes de que nada llegue a los usuarios de producción.
nethead emeritors
Excelente trabajo en el plugin de actualizador. Funciona sin problemas para mí, y las actualizaciones en vivo son un superacelerador para un giro rápido de pruebas.
Desarrollador, Webincode
“Ser capaz de agregar IDs de dispositivo a ciertos grupos y enviar los cambios a solo ciertos grupos es un salvavidas.”
FAQ
Respuestas claras para las personas que configuran la CI y las personas que revisan.
Not when the PR only changes the web layer. Reviewers install the app once, and each PR's JavaScript, HTML, CSS, and assets go to its own channel. If the PR adds a plugin or changes native code, it needs a native build. Run build needed in CI to detect that.
FAQ sobre vistas previas de PRNot with an App Preview API key. It can create preview channels, upload bundles, and delete only the channel and bundle it created. It cannot change the default or main channel. In GitHub Actions, run the job on pull_request, not pull_request_target, and limit it to PRs from the same repository.
App Preview API keysUn administrador habilita las vistas previas una vez con app set --preview. Después de eso, get-qr imprime un código QR code para el canal de PR y --url imprime la URL de vista previa web y el enlace profundo. Póngalos en un comentario de PR.
Referencia de get-qrAgregue una tarea en el evento de cierre de solicitud de cambios que ejecute el comando de eliminación de canal con --delete-bundle y --success-if-not-found. Con una clave de vista previa de App, eso elimina el canal y el paquete vinculado a él. Los paquetes de empujes anteriores se pueden eliminar con la limpieza de paquetes, utilizando una clave que tenga derechos de eliminación.
Referencia del canal CLISí. Los pasos son Capgo CLI comandos, por lo que se ejecutan en cualquier CI. Los documentos tienen guías de integración para GitHub Acciones, GitLab CI, Bitbucket Pipelines y Azure DevOps.
Integraciones CI/CDAgrega los pasos de carga, QR y limpieza a tu CI y prueba en tu propia aplicación durante la prueba gratuita.
Apoyo humano de Martin
Prueba gratuita de 14 días, sin tarjeta de crédito. Los cambios nativos aún requieren una nueva compilación.