Trasforma ogni Richiesta di Pulizia in un Anteprima Installabile

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

Che se la tua app di produzione potesse estrarre le ultime modifiche da qualsiasi richiesta di pull direttamente sul dispositivo, senza alcun reinstallazione o ritardi dell'App Store?

È questo che gli anteprimi di PR abilitano. 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 feature e tornare indietro - tutto senza lasciare l'app che già ha.

Il Problema di TestFlight

Il tradizionale workflow per testare le feature mobili assomiglia a questo:

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

Ciò crea un punto di bottiglia. La QA si blocca in attesa di costruire. I responsabili dei prodotti non possono verificare le funzionalità velocemente. Gli sviluppatori perdono il contesto mentre attendono i feedback. L'industria stima che questo costa circa 340 dollari per PR in produttività persa.

Come funzionano le anteprime dei PR

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

1. PR aperto o aggiornato - GitHub Action attiva
2. Pacchetto caricato - I tuoi cambiamenti JS/CSS vanno in un canale specifico per PR
3. Commento pubblicato - I testatori ricevono istruzioni nel PR
4. Test di istantanea - Passa tra i canali, test, torna indietro

Nessuna nuova installazione dell'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 Capgo quickstart guide 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'interno dell'app utilizzando il setChannel() API.

Configurazione di Capgo

1. Vai alla tua Capgo dashboard
2. Naviga a Impostazioni > API Chiavi
3. Genera una nuova chiave con all permessi
4. Aggiungila come CAPGO_TOKEN nelle tue segrete GitHub repository

Come i tester cambiano canale

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

Opzione 1: Shake Menu (Meno complesso)

Abilita il menu Shake 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 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, __CAPGO_KEEP_0__) pr-123tappano 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:

1. Recupera tutti i canali auto-assegnati tramite __CAPGO_KEEP_0__ listChannels()
2. Visualizza canali con ricerca per trovare PR specifici
3. Scarica l'aggiornamento dopo la selezione
4. 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 testatori di scegliere uno. Questo utilizza due API chiave:

• listChannels() - Recupera 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');

For un esempio completo di componente React, vedere il nostro articolo sulla guida per la navigazione dei canali.

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

Il previsualizzazione dei PR funziona solo quando il bundle JavaScript è compatibile con la versione nativa installata. Se il tuo PR include modifiche native code (nuovi plugin Capacitor, modifiche iOS/Android), i tester avranno bisogno di un nuovo build nativo.

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ò prevenisce i crash da code incompatibili.

Per i PR che richiedono modifiche native, avrai bisogno di distribuire un nuovo build 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 delle previsualizzazioni dei PR

Ingegneri QA

• Testa le funzionalità immediatamente quando i PR sono aperti
• Passa tra più PR senza reinstallare
• Verifica le correzioni e le regressioni su dispositivi reali
• Nessun atteso per il processo di TestFlight

Gestori dei prodotti

• Valuta le funzionalità prima che vengano merge
• 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
• Demonstra le funzionalità ai stakeholder istantaneamente
• Sviluppa gli issue con gli utenti specifici
• Spesa meno tempo per la gestione delle versioni beta

Confronto: tradizionale vs anteprima PR

Pratiche consigliate

1. Nomi i canali in modo chiaro: Utilizza pr-{number} una convenzione per un'identificazione facile
2. Pulizia automatica: Elimina sempre i canali quando i PR si chiudono
3. Limita l'accesso: Abilita il menu a scuotimento solo nei build debug/staging
4. Documenta il processo: Aggiungi 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 anteprime dei PR

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

• Nuovi Capacitor plugin
• Cambiamenti nativi iOS code
• Modifiche native Android code
• Aggiornamenti di dipendenza che influiscono sui costrutti nativi

Per quelle modifiche avrai bisogno di una distribuzione tradizionale di TestFlight/Play Store.

Combinazione con Channel Surfing

Le anteprime dei PR funzionano meglio quando sono combinate con channel surfingLa 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 specifici PR

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

Risorse

• Capgo Aggiornamenti in Tempo Reale Documentazione
• Canali Documentazione
• Guida alla navigazione tra i canali
• CLI Riferimento alle Comandi
• Pagina delle Soluzioni per anteprime PR

Conclusioni

Le anteprime PR trasformano il modo in cui il tuo team esamina e testa le funzionalità mobili. Invece di dover aspettare 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 - e i benefici si accumulano nel tuo team. La QA rimane bloccata, i manager 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 pull in un'anteprima installabile"

Se stai utilizzando Trasforma ogni richiesta di pull in un'anteprima installabile per pianificare la routing dei canali e la distribuzione in fasi, 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 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.