Crea un canale dedicato Capgo per ogni richiesta di pull. Condividi un link con il tuo team e possono testare le modifiche esatte sul loro dispositivo - senza reinstallare l'app, senza TestFlight, senza aspettare.
Il sviluppatore apre la PR
Code è pronto per la revisione. Ma prima che qualcuno possa testarlo, hai bisogno di costruire e caricare su TestFlight.
Costruisci e Carica
Costruisci l'app localmente o in CI. Archivia. Carica su App Store Connect. Aspetta la elaborazione. 15-30 minuti minimo.
Distribuisci ai Testatori
Aggiungi testatori se non sono già in TestFlight. Invita. Aspetta che accettino. Spiega come installare.
Testa la Versione Errata
I testatori scaricano la versione. Il dev invia una correzione. Ora tutti devono ripetere i passaggi 2-3 per ottenere la versione aggiornata.
Tempo totale per testare una PR: 45-60 minuti. Per PR. Per testatore. Per ogni aggiornamento.
15-30 minuti
Tempo di elaborazione di TestFlight
Ogni build che carichi deve essere elaborato da Apple prima che i testatori possano accedervi. Questo è per-build, ogni volta.
67%
Del tempo di QA trascorso ad aspettare
I ingegneri QA segnalano di trascorrere il 67% del loro tempo ad aspettare i build anziché testare effettivamente. È 5+ ore al giorno di produttività sprecata.
$340/PR
Costo nascosto per richiesta di pull
Quando si tiene conto del tempo di attesa del developer, del tempo bloccato della QA e della feedback ritardato, ogni PR costa in media $340 di produttività persa.
Creare un canale Capgo per ogni PR. I tester cambiano canale in secondi. Nessun riavvio dell'app. Nessun aspettare.
CI costruisce automaticamente l'app e crea un canale Capgo chiamato con il numero della PR.
Automatico
Il bundle costruito viene caricato su Capgo in background. Nessuna ritardata elaborazione.
meno di 30 secondi
Il tester apre l'app, sposta al canale PR e ottiene il build immediatamente.
meno di 10 secondi
La QA esegue test sul dispositivo reale. Il dev invia le correzioni. Il tester riceve immediatamente le aggiornamenti. Nessuna reinstallazione necessaria.
Iterazione istantanea
name: PR Preview
on:
pull_request:
types: [opened, synchronize]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Setup & Build
run: |
npm ci
npm run build
# Create a channel named after your PR
- name: Create PR Channel
run: npx @capgo/cli channel add pr-$${{ github.event.pull_request.number }}
# Upload the build to that channel
- name: Upload to Capgo
run: npx @capgo/cli bundle upload --channel pr-$${{ github.event.pull_request.number }}
# Post a comment with the test link
- name: Comment on PR
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 }}`'
})La configurazione richiede 5 minuti. Copia questo workflow e adattalo al tuo CI.
Abilita il gesto di scuotimento integrato. I tester scuotono il loro dispositivo per aprire un menu che mostra tutti i canali disponibili.
// capacitor.config.ts
CapacitorUpdater: {
shakeMenu: true // Enable for testing
}Costruisci un'interfaccia utente personalizzata per la selezione dei canali. Perfetto per una schermata di impostazioni del dev nel tuo app.
// Switch channel from your app
import { CapacitorUpdater } from '@capgo/capacitor-updater'
await CapacitorUpdater.setChannel({
channel: 'pr-123'
})App di collaborazione B2B SaaS - Team
La squadra mobile di TechFlow stava inviando 15-20 PRs a settimana. Ogni PR richiedeva la verifica da parte di QA prima dell'incorporamento. Con TestFlight, il loro capo QA stimava di aver trascorso il 60% del loro tempo ad aspettare i build anziché testare.
Il vero dolore arrivò durante le settimane di crunch. Quando erano necessarie le verifiche di più PR contemporaneamente, QA doveva reinstallare costantemente i diversi build di TestFlight. I tester si confondevano sulla versione che stavano eseguendo. I bug venivano segnalati su versioni già corrette code.
Dopo l'implementazione di Capgo PR Preview, la loro squadra QA poteva passare da qualsiasi PR in secondi. Nessuna reinstallazione. Nessuna confusione. Nessuna attesa. Il loro tempo medio per la risposta del QA è sceso da 2,3 giorni a 0,6 giorni.
"Il nostro team di QA è passato da frustrato a felice. Gli sviluppatori si divertono a testare ora perché non devono aspettare. Siamo riusciti a rilasciare il doppio di feature per sprint."
— Lisa Wong, Responsabile tecnico a TechFlow
La preview dei PR trasforma il modo in cui il tuo team collabora sullo sviluppo mobile.
TestFlight / Beta
Capgo anteprima del PR
Trova la soluzione che si adatta alle esigenze della tua squadra
App costruite con Capacitor
Le app di apprendimento, eventi e community possono avere modifiche in corso di revisione per l'iscrizione, la pratica, la sessione in diretta e l'abbonamento allo stesso tempo. Le anteprime dei PR consentono a prodotto, QA e supporto di esaminare una versione mobile pronta per la fusione prima della fusione.
ISTRUZIONE
App di istruzione dove le modifiche alle lezioni, ai corsi e agli abbonamenti richiedono la revisione dei stakeholder.
IMPRESE
App di impegno in diretta dove i flussi degli eventi dovrebbero essere testati prima della fusione.
TAVOLO DA SCACCHI
Comunità app dove le schermate del torneo e dell'analisi beneficiano delle anteprime del dispositivo.
Il tuo team di QA merita di più di guardare i progressi dei barre. Dai loro accesso istantaneo a ogni PR.
Configura in 5 minuti. Nessun TestFlight richiesto. Nessuna reinstallazione dell'app.