Trasforma ogni richiesta di pull in un'anteprima installabile

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

Cosa se il tuo'app di produzione potesse estrarre le ultime modifiche da qualsiasi richiesta di pulizia direttamente sul dispositivo, senza alcun reinstall o ritardi dell'app store?

È questo che PR previews abilita. Quando un sviluppatore apre una richiesta di pull, un'GitHub Action 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
Aspetta TestFlight - 15-30 minuti di tempo di elaborazione
Trova e installa - I tester cercano la build giusta
Testa e ripeti - Ogni modifica significa un altro atteso

Ciò crea un bottleneccio. La QA si blocca aspettando i build. I responsabili dei prodotti non possono verificare le funzionalità velocemente. Gli sviluppatori perdono il contesto mentre aspettano i feedback. L'industria stima che questo costa circa 340 dollari a PR in produttività persa.

How PR Previews Funzionano

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

PR aperto o aggiornato - GitHub Action attiva un'azione
Bundle caricato - Le tue modifiche JS/CSS vanno in un canale specifico per il PR
Commento pubblicato - I tester ricevono istruzioni nel PR
Test in tempo reale - Passa ai canali, testa, torna indietro

Senza nuove installazioni dell'app. Senza ritardi di TestFlight. Lo stesso app di produzione può estrarre da canali di aggiornamento diversi.

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 Capgo guida di avvio rapido se non l'hai già fatto.

GitHub Flusso di lavoro di Azioni

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 flag quando si crea il canale. Ciò consente ai tester di passare al canale dall'applicazione utilizzando il setChannel() API.

Configurazione del Token Capgo

Vai al tuo Capgo dashboard
Naviga a Impostazioni > API Chiavi
Genera una nuova chiave con all permessi
Aggiungila come CAPGO_TOKEN nelle tue segrete repository GitHub

Come i tester cambiano canale

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

Abilita il menu di scuotimento con selezione del canale nelle tue Capacitor impostazioni:

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

I tester scuotono il loro 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) e cliccano per selezionarlo; l'applicazione scarica automaticamente e applica l'aggiornamento. Quando hanno finito di testare, scuotono nuovamente e tornano al canale di produzione.

Il menu di scuotimento gestisce l'intero flusso automaticamente:

Estrae tutti i canali auto-assegnabili tramite listChannels()
Visualizza canali con 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 canale all'interno dell'app che elenca i canali PR disponibili e consente ai tester di scegliere uno. Questo utilizza due API chiave:

listChannels() - Elenca tutti i canali con l'assegnazione auto 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');

Per un esempio completo di componente React, vedi il nostro articolo sul canale surfing.

Pulizia dei Canali PR

Quando un PR è stato fuso o chiuso, vorrai pulire il canale. Aggiungi un'altra 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 }}

This removes the channel when the PR is closed, keeping your channel list clean.

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 bundle di un PR punti a una versione nativa diversa da quella installata, l'aggiornamento non verrà applicato. Ciò prevenirebbe crash da code incompatibili.

Il PR che richiedono modifiche native richiederanno una nuova distribuzione di TestFlight/Play Store. Le previsualizzazioni dei PR funzionano meglio per le modifiche JavaScript, CSS e asset che non toccano la code nativa.

Chi Beneficia dalle Previsualizzazioni dei PR

Ing. di Test

Testare le funzionalità immediatamente quando i PR sono aperti
Passare tra più PR senza reinstallare
Verificare le correzioni e le regressioni su dispositivi reali
Non più aspettare il processo di TestFlight

Manager dei Prodotti

Valuta le funzionalità prima che vengano merge
Dare feedback direttamente sul PR
Verifica che l'implementazione corrisponda alle richieste
Riduci il tempo di ciclo di revisione

Developer

Ottenere feedback più veloci sulle modifiche
Mostra le funzionalità ai stakeholder istantaneamente
Debug gli issue con gli utenti specifici
Passa meno tempo a gestire le versioni beta

Confronto: Tradizionale vs Previsualizzazioni PR

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

Pratiche Migliori

Nome i canali chiaramente: Utilizza pr-{number} convenzione per un'identificazione facile
Pulizia automatica: Elimina sempre i canali quando i PR si chiudono
Limita l'accesso: Abilita il menu a scorrimento solo nei build debug/staging
Documenta il processo: Aggiungi istruzioni di testing al template del tuo PR
Gestisci le fallite con grazia: Assicurati che la creazione del canale avvenga con successo 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
Modifiche native iOS code
Modifiche native Android code
Aggiornamenti delle dipendenze che influiscono sui build nativi

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

Combina con Channel Surfing

Le anteprime dei commit funzionano meglio quando sono combinati con la navigazione tra canali 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 commit

Gli tester con build di produzione possono passare da un canale di commit all'altro, testare la funzionalità e poi tornare indietro - tutto con la stessa app installata.

Risorse

Conclusioni

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

La configurazione è minima - un file di workflow GitHub Actions - 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 "Trasforma ogni Richiesta di Modifica in un'anteprima installabile"

Se stai utilizzando Trasforma ogni Richiesta di Modifica in un'anteprima installabile per pianificare la routing dei canali e la distribuzione in fasi, collega con Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Channels, Channels per i dettagli di implementazione in Channels, Soluzione di Test Beta per il flusso di lavoro del prodotto in Soluzione di Test Beta, e Soluzione di Targetizzazione della Versione per il flusso di lavoro del prodotto in Soluzione di Targetizzazione della Versione.

Trasforma ogni Richiesta di Pulizia in una Previsione Installabile