Trasforma ogni richiesta di pull in un'anteprima installabile

Ogni squadra di sviluppatori mobili ha provato il dolore: una funzionalità è pronta per la revisione, ma farla entrare nelle mani degli stakeholder significa navigare il labirinto di revisione beta di TestFlight o Google Play. Ciò che dovrebbe richiedere minuti si trasforma in ore di attesa, installazione e gestione di build beta.

Che cosa se il tuo'applicazione di produzione potesse estrarre le ultime modifiche da qualsiasi richiesta di pull direttamente sul dispositivo, senza alcuna reinstallazione o ritardi dell'app store?

È questo che prevede le anteprime abilita. Quando un sviluppatore apre una richiesta di pull, un'GitHub azione crea un canale di aggiornamento dedicato e pubblica le modifiche. Chiunque abbia l'app installata può passare a quel canale, testare la funzionalità e tornare indietro - tutto senza lasciare l'app che già ha.

Il problema di TestFlight

Il flusso di lavoro tradizionale per la verifica delle funzionalità mobili assomiglia a questo:

Sviluppatore apre PR - Code è pronto per la revisione
Attendi TestFlight - 15-30 minuti di tempo di elaborazione
Cerca e installa - I tester cercano la versione giusta
- Testa e ripeti - Ogni cambiamento significa un altro attesa

Questa crea un punto di blocco. Il QA si blocca in attesa di costruire. I manager dei prodotti non possono verificare le funzionalità velocemente. Gli sviluppatori perdono il contesto in attesa di feedback. L'industria stima che questo costa circa 340 dollari a PR in produttività persa.

Come funzionano le anteprime dei PR

Le anteprime dei PR utilizzano il sistema di canali di Capgo per creare flussi di aggiornamento per ogni PR. Ecco il flusso:

PR aperto o aggiornato - L'azione di GitHub viene attivata
Caricamento del bundle - Le tue modifiche JS/CSS vanno in un canale specifico per PR
Commento pubblicato - I tester ricevono istruzioni nel PR
Test di istantanea - Cambia canale, testa, torna indietro

Nessuna nuova installazione di app. Nessun ritardo di TestFlight. L'app di produzione può estrarre da diversi canali di aggiornamento.

Configurazione delle anteprime dei PR

Prima di poter implementare le anteprime dei PR, il tuo progetto deve essere configurato con Capgo Aggiornamenti in Tempo Reale. Segui il guida di avvio rapido di Capgo se non l'hai già fatto.

GitHub Flusso di lavoro di Actions

Crea .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 chiave è la --self-assign bandiera quando si crea il canale. Ciò consente ai tester di passare al canale dall'app stessa utilizzando il setChannel() API.

Configurazione del Token Capgo

Vai alla tua Capgo dashboard
Naviga a Impostazioni > Chiavi API
Genera una nuova chiave con all autorizzazioni
Aggiungila come CAPGO_TOKEN nelle tue segretezza GitHub repository

Come i tester passano ai canali

Ci sono due modi per cui i tester possono passare a un canale PR:

Abilita il menu a scuotimento con selezione del canale nel tuo Capacitor config:

// capacitor.config.ts
const config: CapacitorConfig = {
  // ... your other config
  plugins: {
    CapacitorUpdater: {
      shakeMenu: true,
      allowShakeChannelSelector: true
    }
  }
};

Testatori scuotono il dispositivo per aprire il menu di debug, che mostra una lista dei canali disponibili con una barra di ricerca. Trovano il loro canale PR (ad esempio, pr-123), toccano per selezionarlo e l'applicazione scarica automaticamente e applica l'aggiornamento. Quando hanno finito di testare, scuotono nuovamente e tornano alla produzione.

La menu di scuotamento gestisce l'intero flusso automaticamente:

Recupera tutti i canali assegnabili tramite listChannels()
Mostra i canali con la ricerca per trovare PR specifici
Scarica l'aggiornamento dopo la selezione
Promuove il riavvio con le opzioni “Riavvia ora” / “Più tardi”

Opzione 2: Selezione personalizzata del canale UI

Costruisci un commutatore di canali all'interno dell'applicazione che elenchi i canali PR disponibili e lascia ai testatori scegliere uno. Questo utilizza due API chiave:

listChannels() - Recupera tutti i canali con l'assegnazione a sé abilitata
setChannel() - Sposta il dispositivo sul canale selezionato

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 questi blocchi di costruzione, puoi creare una semplice UI:

// 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');

Esempi di componenti React completi, vedi il nostro articolo sulle guide per la programmazione televisiva.

Pulizia dei canali PR

Quando un PR viene unito o chiuso, vorrai pulire il canale. Aggiungi un altro workflow:

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 }}

Questo elimina il canale quando il PR è chiuso, mantenendo la lista dei canali pulita.

Compatibilità della versione

PR previews only work when the JavaScript bundle is compatible with the installed native version. If your PR includes native code changes (new Capacitor plugins, iOS/Android modifications), testers will need a new native build.

Capgo controlla automaticamente la compatibilità della versione. Se il pacchetto di un PR mira a una versione nativa diversa da quella installata, l'aggiornamento non verrà applicato. Ciò prevenisce i crash da code incompatibili.

Per i PR che richiedono modifiche native, avrai bisogno di distribuire una nuova build di TestFlight/Play Store. I previsualizzatori dei PR funzionano meglio per le modifiche JavaScript, CSS e asset che non toccano la parte nativa code.

Chi beneficia dei previsualizzatori dei PR

Ing. QA

context
Passa tra più PR senza reinstallare
Verifica le correzioni e le regressioni su dispositivi reali
Non più attesa per il processo di TestFlight

Gestori dei prodotti

Recensisci le funzionalità prima che siano integrate
Dai feedback direttamente sul PR
Verifica che l'implementazione corrisponda alle richieste
Riduci il tempo del ciclo di revisione

Sviluppatori

Otterrai feedback più veloci sulle modifiche
Mostra le funzionalità ai stakeholder istantaneamente
Debugga gli issue con gli utenti specifici
Spend less time managing beta builds

Confronto: Previsioni tradizionali vs Previsioni PR

Aspetto	TestFlight/Beta	Capgo Previsione PR di Capgo
Tempo di costruzione	15-30 min	<1 min
Passaggio tra PR	5+ min reinstallazione	10 secondi
Complessità di configurazione	App Store credentials	Un file di workflow
Ripulisci	Manuale	Automatico
Modifiche native code	Richiesto	Facoltativo (solo JS)

Buone pratiche

Nome i canali chiaramente: Utilizza pr-{number} convenzione per un'identificazione facile
Auto-pulizia: Elimina sempre i canali quando i PR si chiudono
Limita l'accesso: Abilita il menu a scuotere solo nei build debug/staging
Documenta il processo: Aggiungi istruzioni di testing al template dei PR
Affronta le fallite con grazia: Verifica che la creazione del canale riesca prima di pubblicare commenti

Quando non utilizzare anteprime dei PR

Le anteprime dei PR sono per modifiche JavaScript/CSS. Se il tuo PR include:

Nuovi Capacitor plugin
iOS native code changes
Modifiche native di Android code
Aggiornamenti delle dipendenze che influiscono sui costrutti nativi

Avrai bisogno di una distribuzione tradizionale di TestFlight/Play Store per quelle modifiche.

Combinazione con Channel Surfing

Le anteprime dei PR funzionano meglio quando sono combinate con channel surfing. La tua app può avere:

production - Rilasci stabili per tutti gli utenti
beta - Accesso anticipato per gli utenti che si sono iscritti
pr-123 - Anteprime di funzionalità per specifici PR

I testatori con costrutti di produzione possono passare a qualsiasi canale PR, testare la funzionalità, poi tornare indietro - tutto con la stessa app installata.

Risorse

Conclusioni

Gli anteprime dei PR trasformano il modo in cui il tuo team esamina e testa le funzionalità mobili. Invece di dover attendere il processo di TestFlight e gestire più build beta, i tester possono passare a qualsiasi canale di PR in secondi utilizzando l'app che già hanno installato.

Il setup è minimale - un file di workflow GitHub - e i benefici si accumulano nel tuo team. La QA rimane non bloccata, i responsabili dei prodotti esaminano più velocemente e gli sviluppatori ricevono feedback più veloci.

Inizia aggiungendo il workflow a un repository e vedi come cambia il tuo processo di revisione.

Continua da Turn Every Pull Request Into an Installable Preview

Se stai utilizzando Turn Every Pull Request Into an Installable Preview per pianificare la routing del canale e la distribuzione in fase di testing, connettilo con Canali per i dettagli di implementazione in Canali Canali per i dettagli di implementazione in Canali Canali per i dettagli di implementazione in Canali Soluzione di Test Beta per il workflow del prodotto in Soluzione di Test Beta, e Soluzione di Targeting della Versione per il workflow del prodotto in Soluzione di Targeting della Versione.

Trasforma ogni Richiesta di Pulizia in un'anteprima installabile