Trasforma ogni richiesta di pull in un anteprima installabile

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

Qual è se la tua app di produzione potesse estrarre le ultime modifiche da qualsiasi richiesta di pulizia direttamente sul dispositivo, senza alcuna reinstallazione o ritardi dell'app store?

Ecco cosa Le preview delle richieste di pulizia abilitano. Quando uno sviluppatore apre una richiesta di pulizia, 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 funzione e tornare indietro - tutto senza lasciare l'app che già ha.

Il Problema di TestFlight

Il flusso di lavoro tradizionale per testare le funzioni mobili assomiglia a questo:

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

Questo crea un bottlenecco. La QA si blocca in attesa di costruire. I responsabili 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:

1. PR aperto o aggiornato - L'azione di GitHub viene attivata
2. Bundle caricato - Le tue modifiche JS/CSS vanno in un canale specifico per PR
3. Commento pubblicato - Gli tester ricevono istruzioni nel PR
4. Test in tempo reale - Passa tra i canali, testa, torna indietro

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

Configurazione dei Previews dei PR

Prima di poter implementare i previews dei PR, il tuo progetto deve essere configurato con Capgo Aggiornamenti in Tempo Reale. Segui il guida rapida 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 è il --self-assign impostare il flag quando si crea il canale. Ciò consente agli tester di passare al canale dal dentro dell'applicazione utilizzando il setChannel() API.

Configurazione del token Capgo

1. Vai al tuo Capgo dashboard
2. Naviga a Impostazioni > Chiavi API
3. Genera una nuova chiave con all autorizzazioni
4. Aggiungilo come CAPGO_TOKEN in segreto del tuo repository GitHub

C'è un modo per i tester di passare a un canale PR:

C'è un altro modo per i tester di passare a un canale PR:

Opzione 1: Shake Menu (Meno Complicato)

Abilita il menu di scuotimento con selezione canale nella tua configurazione Capacitor:

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

I testatori 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), toccano per selezionarlo e l'applicazione scarica e applica automaticamente l'aggiornamento. Quando hanno finito di testare, scuotono nuovamente e tornano alla produzione.

Il menu di scuotimento gestisce l'intero flusso automaticamente:

1. Recupera tutti i canali auto-assegnabili tramite listChannels()
2. Mostra canali con ricerca per trovare PR specifici
3. Scarica l'aggiornamento dopo la selezione
4. Suggerisce di ricaricare con le opzioni “Ricarica ora” / “Più tardi”

Opzione 2: Selezione personalizzata del canale UI

Costruisci un switcher di canali nella tua app che elenchi i canali PR disponibili e lascia che i testatori ne scegliano uno. Questo utilizza due API chiave:

• listChannels() - Recupera tutti i canali con l'assegnazione auto-abilitata
• setChannel() - Cambia 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 interfaccia utente:

// 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.

Rimuovere i canali dei PR

- Quando un PR viene fuso 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 rimuove 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ò prevenirebbe i crash da code incompatibili.

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

Chi beneficia delle anteprime dei PR

Ingegneri QA

• Testare le funzionalità immediatamente quando vengono aperte le PR
• Passare tra più PR senza reinstallare
• Verificare le correzioni e le regressioni su dispositivi reali
• Non più attesa per il processo di TestFlight

Gestori di prodotto

• Revisionare le funzionalità prima che vengano merge
• Dare feedback direttamente sulla PR
• Verificare che l'implementazione corrisponda alle richieste
• Ridurre il tempo del ciclo di revisione

Sviluppatori

• Ottenere feedback più veloci sulle modifiche
• Mostra funzionalità di demo agli stakeholder istantaneamente
• Debugga problemi con utenti specifici
• Spendi meno tempo per gestire le versioni beta

Confronto: Tradizionale vs Previsualizzazioni PR

Pratiche raccomandate

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

Quando non utilizzare le anteprime dei PR

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

• Nuovi Capacitor plugin
• Il cambiamento nativo iOS code
• Il cambiamento nativo Android code
• Aggiornamenti di dipendenza che influiscono sui costrutti nativi

Avrà bisogno di distribuzione tradizionale con TestFlight/Play Store per questi cambiamenti.

Combina 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 iscrivono
• pr-123 - Anteprime di funzionalità per specifiche PR

Testatori con edizioni di produzione possono passare a qualsiasi canale di PR, testare la funzionalità, quindi tornare indietro - tutto con la stessa app installata.

Risorse

• Capgo Aggiornamenti in Tempo Reale Documentazione
• Documentazione sui Canali
• Guida al Surfing dei Canali
• CLI Riferimento alle Comandi
• Pagina delle Soluzioni per le Previsioni di PR

Conclusioni

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

La configurazione è minima - un file di workflow GitHub Actions - e i benefici si accumulano nel tuo team. La QA rimane bloccata, i manager di prodotto 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

If sei stai utilizzando Trasforma ogni richiesta di pull in un'anteprima installabile per pianificare la routing dei canali 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 Soluzione di testing beta per il flusso di lavoro del prodotto in Soluzione di testing beta, e Soluzione di targeting della versione __CAPGO_KEEP_0__ per il workflow del prodotto nella Version Targeting Solution.