Jeden Pull Request in eine installierbare Vorschau verwandeln

Jedes mobile Entwicklerteam kennt das Problem: Eine Funktion ist für die Überprüfung bereit, aber das Einbringen in die Hände der Stakeholder bedeutet das Navigieren des TestFlight- oder Google Play-Beta-Review-Labyrinths. Was Minuten dauern sollte, wird zu Stunden des Wartens, Installierens und der Verwaltung von Beta-Builds.

Was wäre, wenn Ihre Produktions-App die neuesten Änderungen aus jedem Pull-Request direkt auf das Gerät ziehen könnte, ohne jegliche Wiederinstallationen oder Verzögerungen bei den App-Store?

Das ist PR-Vorschau enable. Wenn ein Entwickler einen Pull-Antrag öffnet, erstellt ein GitHub-Action eine dedizierte Update-Kanal und publiziert die Änderungen. Jeder mit der App installiert kann auf diesen Kanal wechseln, die Funktion testen und wieder zurück wechseln - alles ohne die App zu verlassen, die sie bereits haben.

Das TestFlight-Problem

Das traditionelle Workflow für die Testung von mobilen Funktionen sieht ungefähr so aus:

Entwickler öffnet PR - Code ist bereit für die Überprüfung
Warten auf TestFlight - 15-30 Minuten Verarbeitungszeit
Finden und installieren - Tester suchen nach der richtigen Build
Testen und wiederholen - Jeder Änderung bedeutet erneutes Warten

Das schafft eine Engstelle. Die QA-Abteilung wird blockiert, während Builds gewartet werden. Produktmanager können keine Funktionen schnell überprüfen. Entwickler verlieren den Kontext, während sie auf Feedback warten. Die Branche schätzt dies auf etwa 340 US-Dollar pro PR an verlorener Produktivität.

Wie PR-Vorschauen funktionieren

PR-Vorschauen verwenden das Capgo-Kanal-System, um pro-PR-Update-Ströme zu erstellen. Hier ist der Ablauf:

PR geöffnet oder aktualisiert - GitHub-Aktion ausgelöst
Bundle hochgeladen - Ihre JS/CSS-Änderungen gehen in einen pro-PR-Kanal
Kommentar gepostet - Tester erhalten Anweisungen im PR
Instant-Testen - Kanäle wechseln, testen, zurückwechseln

Keine neuen App-Installationen. Keine TestFlight-Verzögerungen. Die gleiche Produktions-App kann von verschiedenen Update-Kanälen abrufen.

Einrichten von PR-Vorschauen

Bevor Sie PR-Vorschauen implementieren können, muss Ihr Projekt mit Capgo Live Updates konfiguriert werden. Folgen Sie dem Capgo Schnellstart-Leitfaden wenn Sie das noch nicht getan haben.

GitHub Actions Workflow

Erstellen .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.'
            })

Der Schlüssel ist die --self-assign Flagge, wenn Sie den Kanal erstellen. Dies ermöglicht es Testern, den Kanal innerhalb der App mithilfe des setChannel() API

Einrichten des Capgo Tokens

Gehen Sie zu Ihrem Capgo Dashboard
Navigieren Sie zu Einstellungen > API Schlüssel
Einen neuen Schlüssel mit __CAPGO_KEEP_0__ Berechtigungen erstellen all __CAPGO_KEEP_0__ Berechtigungen
Hinzufügen als CAPGO_TOKEN in Ihrem GitHub Repository-Secrets

Wie Tester Kanäle wechseln

Es gibt zwei Möglichkeiten für Tester, auf einen PR-Kanal zu wechseln:

Aktivieren Sie das Shake-Menü mit Kanal-Selektor in Ihrer Capacitor Konfiguration:

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

Tester schütteln ihr Gerät, um das Debug-Menü zu öffnen, das eine Liste der verfügbaren Kanäle mit einer Suchleiste anzeigt. Sie finden ihren PR-Kanal (z.B. __CAPGO_KEEP_0__), tippen ihn an, um ihn auszuwählen, und die App lädt und aktualisiert sich automatisch. Wenn sie fertiggetestet haben, schütteln sie erneut und wechseln zurück auf die Produktionsumgebung. pr-123Das Shake-Menü handhabt den gesamten Workflow automatisch:

Alle selbst-zuweisbaren Kanäle abrufen via

Fetches all self-assignable channels via __CAPGO_KEEP_0__ listChannels()
Anzeigt Kanäle mit Suchfunktion, um spezifische PRs zu finden
Lädt die Aktualisierung nach der Auswahl herunter
Bittet um Neuladen mit den Optionen „Jetzt neu laden“ / „Später“

Option 2: Benutzerdefinierter Kanal-Selektions-UI

Baut einen Kanalwechsler in deine App ein, der verfügbare PR-Kanäle auflistet und Testern ermöglicht, einen auszuwählen. Dazu werden zwei Schlüssel-APIs verwendet:

listChannels() - Holt alle Kanäle mit Selbstzuweisung ab
setChannel() - Wechselt das Gerät auf den ausgewählten Kanal

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;
}

Mit diesen Bausteinen kannst du eine einfache UI erstellen:

// 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');

Für einen vollständigen React-Beispiel siehe Unser Artikel über Kanal-Surfen.

Bereinigung von PR-Kanälen

Wenn ein PR verschmolzen oder geschlossen wird, möchten Sie den Kanal bereinigen. Fügen Sie einen weiteren Workflow hinzu:

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 }}

Dies entfernt den Kanal, wenn der PR geschlossen wird, und hält Ihre Liste der Kanäle sauber.

Versionenkompatibilität

PR-Vorschau funktioniert nur, wenn das JavaScript-Bundle mit der installierten nativen Version kompatibel ist. Wenn Ihr PR nativen code-Änderungen (neue Capacitor-Plugins, iOS/Android-Modifikationen) enthält, benötigen die Tester ein neues natives Build.

Capgo überprüft automatisch die Versionenkompatibilität. Wenn ein PRs Bundle eine andere nativen Version als die installierte ansteuert, wird die Aktualisierung nicht angewendet. Dies verhindert Crashs durch inkompatible code.

Für PRs, die nativen Änderungen bedürfen, müssen Sie ein neues TestFlight/Play Store-Build verteilen. PR-Vorschau funktioniert am besten für JavaScript, CSS- und Asset-Änderungen, die keine nativen code-Änderungen berühren.

Wer profitiert von PR-Vorschau

QA-Engineer

Testen Sie Funktionen sofort, wenn PRs geöffnet werden
Wechseln Sie zwischen mehreren PRs ohne Neuinstallation
Überprüfen Sie Reparaturen und Rückschritte auf echten Geräten
Keine Wartezeit für TestFlight-Verarbeitung

Produktmanager

Überprüfen Sie Funktionen, bevor sie in die Mergen integriert werden
Geben Sie Feedback direkt auf dem PR ab
Stellen Sie sicher, dass die Implementierung den Anforderungen entspricht
Verringern Sie die Zeit für die Überprüfung

Entwickler

Erhalten Sie schnellere Feedback auf Änderungen
Demo-Funktionen für Stakeholder sofort vorstellen
Führen Sie Probleme mit bestimmten Benutzern aus
Verbringen Sie weniger Zeit mit der Verwaltung von Beta-Versionen

Vergleich: Traditionell vs. PR-Vorschauen

Aspekt	TestFlight/Beta	Capgo Vorabansicht
Buildzeit	15-30 min	weniger als 1 min
Wechseln von PRs	5+ min Reinstallierung	10 Sekunden
Setup-Komplexität	App Store-Zugangsdaten	Ein Workflow-File
Aufräumen	Manuell	Automatisch
Nativ code Änderungen	Erforderlich	Optional (JS nur)

Best Practices

Nennen Sie Kanäle klar: Verwenden Sie pr-{number} Konvention für eine einfache Identifizierung
Automatischer Löschvorgang: Lösen Sie immer Kanäle, wenn PRs geschlossen werden
Zugriff einschränken: Aktivieren Sie die Shake-Menü nur in Debug-/Staging-Builds
Dokumentieren Sie den Prozess: Fügen Sie Anweisungen zur Prüfsoftware in Ihr Pull-Request-Vorlage hinzu
Fehler vermeiden: Überprüfen Sie, ob die Kanal-Erstellung erfolgreich ist, bevor Sie Kommentare posten

Wann nicht PR-Vorschau verwenden

PR-Vorschauen sind für JavaScript/CSS-Änderungen vorgesehen. Wenn Ihr Pull-Request enthält:

Neue Capacitor-Plugins
iOS-native code-Änderungen
Android-native code-Änderungen
Abhängigkeitsaktualisierungen, die native Builds beeinflussen

Sie benötigen traditionelle TestFlight/Play Store-Verteilung für diese Änderungen.

Kombinieren mit Channel Surfing

PR-Vorschauen funktionieren am besten, wenn sie mit FernsehenIhr App kann haben:

production - Stabile Versionen für alle Benutzer
beta - Frühzugriff für Benutzer, die sich anmelden
pr-123 - Funktionen-Vorschauen für bestimmte PRs

Benutzer mit Produktionsbuilds können auf jede PR-Kanal umschalten, die Funktion testen und dann wieder zurück umschalten - alles mit der gleichen installierten App.

Ressourcen

Zusammenfassung

PR-Vorschauen verändern, wie Ihr Team mobile Funktionen überprüft und testet. Anstatt auf die TestFlight-Verarbeitung zu warten und mehrere Beta-Versionen zu verwalten, können Tester innerhalb von Sekunden auf jede PR-Kanal wechseln, indem sie die App verwenden, die sie bereits installiert haben.

Die Einrichtung ist minimal - ein einziges GitHub Actions-Arbeitsfluss-Datei - und die Vorteile summieren sich über Ihr Team. Die QA bleibt unblockiert, Produktmanager überprüfen schneller und Entwickler erhalten schnellere Feedback.

Beginnen Sie damit, die Arbeitsfluss in einem Repository hinzuzufügen und sehen Sie, wie es Ihr Überprüfungsprozess ändert.