Salta al contenuto principale
Anteprima PR

Recensisci ogni pull request su un telefono reale

La tua CI carica il web build di ogni pull request sul proprio canale Capgo. I reviewer scansionano un QR code o cambiano canale nell'app per provarlo sul proprio dispositivo; il canale viene eliminato alla chiusura della PR. Le modifiche al code nativo richiedono ancora un nuovo build.

  • Un canale per ogni pull request
  • Anteprima QR code
  • Pulizia alla chiusura della PR

Il problema

Una modifica web non dovrebbe richiedere un nuovo binario per la review

Revisionare una PR con build di testing degli store

  1. Il developer apre una PR

    La modifica è pronta per la review, ma nessuno può ancora provarla su uno smartphone.

  2. Build, firma e upload

    Qualcuno crea un Native Build per il branch, lo firma, lo carica su TestFlight o su un canale di test di Play Store e attende l'elaborazione.

  3. Invito e installazione

    I reviewer devono essere aggiunti come tester e installare esattamente quella build.

  4. Ripeti per ogni fix

    Ogni commento di review che modifica code significa un'altra build, un altro upload e un'altra installazione.

Ogni round di review deve attendere un Native Build, anche quando è cambiato solo il JavaScript.

Il costo reale per il team

Ogni build

In attesa dell'elaborazione dello store

Ogni build che carichi su TestFlight o su un canale di test di Play viene elaborata prima che i tester possano installarla. Questo avviene per ogni build.

Ogni PR

Richiede un Native Build per il test

Senza Live Update, i reviewer possono testare un branch solo dopo che qualcuno ha buildato, firmato e caricato un nuovo binario, anche per modifiche solo web.

Feedback tardivo

La review arriva quando l'autore è già passato oltre

Quando la review deve aspettare le build, il feedback arriva in ritardo, l'autore è già su un altro task e il branch diverge da main.

Come funziona

Come i team testano le pull request con Capgo

Quattro step CI: configura una scoped key una volta, carica ad ogni push, condividi la preview, pulisci alla chiusura. Ogni comando qui sotto proviene dalla documentazione di Capgo.

  1. Crea una chiave App Preview e abilita le anteprime

    Un admin crea una chiave App Preview API per la CI. Può creare canali di preview e caricare bundle, ma non può modificare il canale default o di produzione. Le anteprime si attivano una sola volta per app.

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

  2. Carica la build della PR sul suo canale

    A ogni push, la CI builda la web app e la carica con una versione del bundle univoca. bundle upload --channel crea il canale pr-<number> se non esiste e vi collega il bundle.

    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"
    Anteprime PR nella documentazione dei canali

  3. Pubblica la preview nella PR

    get-qr stampa un code QR per il canale, oppure gli URL di preview con --url, così la CI può aggiungerli a un commento della PR.

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

  4. Elimina il canale quando la PR viene chiusa

    Eseguilo all'evento di chiusura della pull request. Con una chiave App Preview rimuove solo il canale e il bundle collegato creati da quella chiave.

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

Altri modi per passare a un canale PR

Entrambi richiedono un canale che permetta l'auto-assegnazione. Una App Preview key non lo imposta, quindi con quella chiave, condividi il QR preview o imposta un device override nella console.

Menu Shake

Attiva il menu shake nelle build interne. I tester scuotono il dispositivo per aprire il menu di test di Capgo, e il selettore di canale permette di scegliere quello desiderato.

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

Switcher in-app

Aggiungi un campo channel alla schermata delle impostazioni developer e chiama setChannel() con il nome del canale della PR.

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

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

Chi usa le PR preview

Chiunque debba revisionare la pull request può testarla su uno smartphone, non solo l'autore.

QA Engineer

  • Testa la web build della PR sul tuo dispositivo
  • Passa tra i canali della PR senza reinstallare l'app
  • Il nome del canale corrisponde al numero della PR, così saprai quale code stai eseguendo

Project Manager

  • Prova una feature su smartphone prima del merge
  • Scansiona il QR code postato nella PR
  • Lascia un feedback direttamente sulla PR

Developer

  • Ricevi feedback dal dispositivo mentre la PR è ancora aperta
  • Ogni push aggiorna il canale della PR
  • Nessun Native Build per modifiche solo JavaScript

Build di test vs canali PR Capgo

  • Portare una PR su uno smartphone

    TestFlight / Play testing
    Native Build, signing e processi degli store
    Canale PR Capgo
    Web build e upload del bundle da CI

  • Passaggio tra PR

    TestFlight / Play testing
    Installa un altro build
    Canale PR Capgo
    Scansiona un altro QR code o cambia canale

  • Setup del reviewer

    TestFlight / Play testing
    Invito al tester, poi installa ogni build
    Canale PR Capgo
    Installa l'app una sola volta

  • Modifiche code native e ai plugin

    TestFlight / Play testing
    Sì
    Canale PR Capgo
    No, serve un Native Build

Soluzioni per tipologia di team

Trova la soluzione adatta alle tue esigenze

Enterprise

Deployment multi-app e multi-team

Startup

Rilascia velocemente senza overhead

Sviluppatori individuali

Prova gratuita di 14 giorni, CLI upload

Agenzie

Gestisci più app client

App buildate con Capacitor

Le app di prodotto richiedono modifiche mobile verificabili

App di apprendimento, eventi e community possono avere contemporaneamente in revisione modifiche a onboarding, pratica, sessioni live e abbonamenti. Con le PR preview, product, QA e support possono ispezionare un build pronto per il mobile prima del merge.

Icona dell'app StudySmarter - Scuola e università ISTRUZIONE

StudySmarter - Scuola e università

App educativa in cui modifiche a lezioni, corsi e abbonamenti richiedono la revisione degli stakeholder.

Installazioni Google Play
6,5M
Valutazione store
4.8
Icona dell'app Poll Everywhere BUSINESS

Poll Everywhere

App per il coinvolgimento live, dove testare i flussi degli eventi prima del merge.

Installazioni Google Play
1,1M
Valutazione store
3.2
lichess • Icona dell'app gratuita di scacchi online TABELLONE DI GIOCO

lichess • Scacchi online gratuiti

App della community in cui le schermate di tornei e analisi beneficiano dei device preview.

Installazioni Google Play
11,3M
Valutazione store
4.3

Cosa dicono i clienti

Cosa dicono i team che rilasciano con Capgo

5.0/5 valutato dai team di sviluppatori 9,400+ team Leggi le recensioni

Nate van Jole

CTO, Privato

“Il setup ha richiesto meno di un giorno. I rollout basati su channel mi permettono di testare sul mio dispositivo prima che qualsiasi cosa arrivi agli utenti in produzione.”

Ritratto di Michael Haberler

Michael Haberler

nethead emeritors

“Ottimo lavoro sul plugin updater. Per me funziona alla perfezione e i live update sono un super acceleratore per velocizzare i test.”

no-tone @ Webincode

Sviluppatore, Webincode

“Poter aggiungere i Device ID a determinati gruppi e inviare le modifiche solo a quei gruppi è una manna.”

FAQ

Domande comuni sulle PR preview

Risposte chiare per chi configura la CI e per chi fa review.

I reviewer hanno bisogno di una nuova build per ogni PR?

Non se la PR modifica solo il web layer. I reviewer installano l'app una sola volta, e il JavaScript, l'HTML, il CSS e gli asset di ogni PR vanno nel proprio canale. Se la PR aggiunge un plugin o modifica code nativo, serve una build nativa. Esegui build needed in CI per rilevarlo.

Cosa richiede una build nativa

La chiave CI può toccare il nostro canale di produzione?

Non con una chiave App Preview API. Può creare canali di preview, fare l'upload di bundle ed eliminare solo il canale e il bundle che ha creato. Non può modificare il canale di default o principale. In GitHub Actions, esegui il job su pull_request, non su pull_request_target, e limitalo alle PR dello stesso repository.

Chiavi App Preview API

Come fanno i reviewer ad aprire la preview?

Un admin abilita le preview una sola volta con app set --preview. Poi, get-qr stampa un QR code per il canale della PR, e --url stampa l'URL della preview web e il deep link. Pubblicali in un commento alla PR.

Riferimento get-qr

Cosa succede ai vecchi canali e ai bundle delle PR?

Aggiungi un job sull'evento pull request closed che esegua channel delete con --delete-bundle e --success-if-not-found. Con una chiave App Preview, questo rimuove il canale e il bundle a esso collegato. I bundle dei push precedenti possono essere rimossi con bundle cleanup, usando una chiave con permessi di delete.

Riferimento CLI del canale

Funziona con GitLab, Bitbucket o Azure DevOps?

Sì. I passaggi sono Capgo CLI commands, quindi girano in qualsiasi CI. La documentazione include guide all'integrazione per GitHub Actions, GitLab CI, Bitbucket Pipelines e Azure DevOps.

Integrazioni CI/CD

Anteprima il tuo prossimo pull request su uno smartphone

Aggiungi i passaggi di upload, QR e cleanup alla tua CI e testali sulla tua app durante la free trial.

Prova gratuita di 14 giorni, senza carta di credito. Le modifiche Native richiedono comunque un nuovo build.