Converti ogni Richiesta di Pulizia in un'anteprima installabile

Ogni team di sviluppo mobile 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.

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

È questo che anteprime di PR abilitano. Quando uno sviluppatore apre una richiesta di pulizia, un'azione GitHub 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 la verifica delle funzionalità mobili assomiglia a questo:

Il sviluppatore apre il 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 cambiamento significa un altro atteso

Ciò crea un bottino. La QA si blocca aspettando le 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 per PR in produttività persa.

Come Funzionano i Previsualizzazioni dei PR

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

PR aperto o aggiornato - GitHub Action attiva
Bundle caricato - Le tue modifiche JS/CSS vanno in un canale specifico per PR
Commento pubblicato - I tester ricevono istruzioni nel PR
Testistica istantanea - Cambia canale, testa, torna indietro

Nessuna nuova installazione dell'app. Nessun ritardo di TestFlight. Lo stesso'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 Live Updates. Segui le Guida rapida di Capgo Se non l'hai già fatto.

Flusso di lavoro di GitHub 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'applicazione utilizzando il setChannel() API.

Configurazione del token di Capgo

Vai al tuo Pannello di controllo Capgo
Naviga a Impostazioni > Chiavi di API
Genera una nuova chiave con all permessi
Aggiungilo come CAPGO_TOKEN in il tuo repository GitHub segreti

Come i tester passano ai canali

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

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

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

Il menu di scuotimento gestisce l'intero flusso automaticamente:

Recupera tutti i canali assegnabili tramite listChannels()
Mostra i canali con ricerca per trovare specifici PR
Scarica l'aggiornamento dopo la selezione
Suggerisce di ricaricare con le opzioni "Ricarica ora" / "Più tardi"

Opzione 2: Selezione personalizzata del canale UI

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

listChannels() Estrae tutte le canalizzazioni con l'assegnazione a sé abilitata
setChannel() - Passa il dispositivo al 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 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 elimina il canale quando il PR è chiuso, mantenendo la lista dei canali pulita.

Compatibilità della Versione

Le anteprime dei PR funzionano solo se il bundle JavaScript è compatibile con la versione nativa installata. Se il tuo PR include modifiche native code (nuove Capacitor plugin, modifiche iOS/Android), i tester avranno bisogno di una nuova build nativa.

Capgo controlla automaticamente la compatibilità della versione. Se il bundle di un PR si rivolge 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, sarà necessario 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 code nativa.

Chi Beneficia dalle Anteprime dei PR

Ingegneri di Test

Testa le funzionalità immediatamente quando vengono aperte le PR
Testare le funzionalità immediatamente quando i PR sono aperti
Passare tra più PR senza reinstallare
Nessun altro attendere per il processo di TestFlight

Gestori di Prodotto

Valuta le funzionalità prima che vengano merge.
Invia 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
Debugga gli errori con gli utenti specifici
Spendi meno tempo per la gestione delle versioni beta

Confronto: Tradizionale vs Previsioni PR

Aspetto	TestFlight/Beta	Capgo Previsione PR
Costruzione	15-30 min	Menos di 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	Richiesto	Facoltativo (solo JS)

Pratiche raccomandate

Nome i canali in modo chiaro: Utilizza pr-{number} convenzione per un'identificazione facile
Pulizia automatica: Elimina sempre i canali quando si chiudono le PR
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
Tratta le fallite con gentilezza: Assicurati 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:

Nuove 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 PR funzionano meglio quando combinate con Navigazione tra canali. Il tuo 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 specifiche PR

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

Risorse

Conclusion

PR previews transform how your team reviews and tests mobile features. Instead of waiting for TestFlight processing and managing multiple beta builds, testers can switch to any PR channel in seconds using the app they already have installed.

The setup is minimal - one GitHub Actions workflow file - and the benefits compound across your team. QA stays unblocked, product managers review faster, and developers get quicker feedback.

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

Continua dall'Implementazione di ogni Richiesta di Pulizia in una Previsualizzazione Installabile

Se stai utilizzando Converti ogni Richiesta di Pulizia in un'anteprima installabile Turn Every Pull Request Into an Installable Preview Channels per i dettagli di implementazione nei canali, Channels per i dettagli di implementazione nei canali, Canali per i dettagli di implementazione in Canali, Soluzione di Test di Beta per il flusso di lavoro del prodotto nella Soluzione di Test Beta. Soluzione di Targeting della Versione per il workflow del prodotto nella Version Targeting Solution.

Trasforma ogni richiesta di pull in un anteprima installabile