Trasforma ogni Richiesta di Pulizia in una Preview 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.

Che cosa se la tua app di produzione potesse estrarre le ultime modifiche da qualsiasi richiesta di pulizia direttamente sul dispositivo, senza alcuna reinstallazione o ritardi degli store?

È questo che le preview delle PR abilitare. 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à possiede.

Problema di TestFlight

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

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

Questo crea un punto di blocco. 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 Work

PR previews use Capgo’s channel system to create per-PR update streams. Here’s the flow:

1. Il sistema dei canali di __CAPGO_KEEP_0__ viene utilizzato per creare flussi di aggiornamento per ogni PR. Ecco il flusso: - GitHub Action triggers
2. - __CAPGO_KEEP_0__ Action attiva un'azione Caricamento del bundle
3. - Le tue modifiche JS/CSS vengono caricate in un canale specifico per il PR Commento pubblicato
4. - Gli utenti di testing ricevono istruzioni nel PR Test in tempo reale

- Cambia canale, testa, torna al canale precedente

Senza nuove installazioni dell'app. Senza ritardi di TestFlight. L'app di produzione può estrarre aggiornamenti da canali diversi.

Prima di poter implementare le anteprime dei PR, il tuo progetto deve essere configurato con Capgo Aggiornamenti in Tempo Reale. Segui la Capgo guida rapida 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 flag quando si crea il canale. Ciò consente ai tester di passare al canale dall'applicazione utilizzando il setChannel() API.

Configurazione del Token Capgo

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

Come i tester cambiano canale

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

Opzione 1: Shake Menu (Meno complesso)

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 di 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 al canale di produzione.

Il menu di scuotimento gestisce l'intero flusso automaticamente:

1. Recupera tutti i canali auto-assegnabili tramite listChannels()
2. Visualizza canali con la ricerca per trovare PR specifici
3. Scarica l'aggiornamento dopo la selezione
4. Richiede il riavvio con le opzioni "Riavvia ora" / "Più tardi"

Opzione 2: Selezione personalizzata del canale UI

Costruisci un commutatore di canale nella tua app che elenchi i canali PR disponibili e lascia che i tester ne scelgano uno. Questo utilizza due API chiave:

• listChannels() - Esegue il recupero di tutti i canali con l'assegnazione autoabilitata
• 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 di navigazione.

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 tua lista di 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 bundle di un PR punti a una versione nativa diversa da quella installata, l'aggiornamento non verrà applicato. Ciò impedisce gli crash dovuti a 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 di Test

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

Gestori di Prodotto

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

Developer

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

Confronto: Tradizionale vs Previsioni PR

Pratiche consigliate

1. Nome i canali in modo chiaro: Utilizza pr-{number} convenzione per un'identificazione facile
2. Pulizia automatica: Elimina sempre i canali quando i PR si chiudono
3. Limita l'accesso: Abilita il menu di scuotimento solo nei build debug/staging
4. Documentare il processo: Aggiungi istruzioni di testing al template del tuo PR
5. Affrontare le fallite con dignità: 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:

• Nuovi Capacitor plugin
• iOS native code changes
• Modifiche native iOS code
• Modifiche native Android __CAPGO_KEEP_0__

Aggiornamenti di dipendenza che influiscono sui build nativi

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

Le anteprime dei PR funzionano meglio quando sono combinate con la navigazione dei 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 PR

Gli tester con edizioni 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
• Documentazione dei canali
• Guida alla navigazione dei canali
• CLI Riferimento alle comandi
• Pagina delle Soluzioni di Visualizzazione delle Richieste di Pulizia

Conclusioni

Le anteprime delle richieste di pulizia 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 tester possono passare a qualsiasi canale della richiesta di pulizia 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 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

Se stai utilizzando Turn Every Pull Request Into an Installable Preview per pianificare la routing dei canali e la distribuzione in fasi, connettilo con Canali contexto: Capgo release channels feature name. Pagina/area: Capgo solutions marketing page. Ruolo: Etichetta di navigazione breve o elemento UI. Visto in: pagina solutions/white-label.astro. Chiave di messaggio `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value). per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione nei canali, Canali per i dettagli di implementazione nei canali, Soluzione di Test di Beta per il flusso di lavoro del prodotto in Soluzione di Test di Beta, e Soluzione di Targeting della Versione per il flusso di lavoro del prodotto in Soluzione di Targeting della Versione.