Jeder Pull Request in eine installierbare Vorschau umwandeln

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 durch das TestFlight- oder Google Play-Beta-Review-Labyrinth. Was Minuten dauern sollte, wird zu Stunden Warten, Installieren und Verwalten von Beta-Builds.

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

Das ist, was PR-Vorschauen ermöglichen. Wenn ein Entwickler einen Pull-Request öffnet, erstellt ein GitHub-Action eine dedizierte Update-Kanal und publiziert die Änderungen. Jeder, der die App installiert hat, kann auf diesen Kanal umschalten, die Funktion testen und wieder zurückkehren – alles ohne das App, die sie bereits haben.

Das TestFlight-Problem

Die 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 nochmal warten

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

Wie PR-Vorschau funktioniert

PR-Vorschau nutzen Capgo's Kanal-System, um pro-PR-Update-Streams 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 testing - 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. Fahren Sie mit der Capgo Schnellstartanleitung 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 der setChannel() API zu wechseln.

Einstellungen für Capgo Token vornehmen

Gehe zu deinem Capgo Dashboard
Navigiere zu Einstellungen > API Schlüssel
Erstelle einen neuen Schlüssel mit all Berechtigungen
Füge ihn als CAPGO_TOKEN in deinen GitHub Repository-Secrets hinzu

Wie Tester Kanäle wechseln

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

Aktiviere das Shake-Menü mit Kanal-Selektor in deiner Capacitor Konfiguration:

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

Testern 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. pr-123), tippen, um ihn auszuwählen, und die App lädt und appliziert den Update automatisch. Wenn sie mit dem Testen fertig sind, schütteln sie erneut und wechseln zurück zur Produktionsumgebung.

Das Shake-Menü handhabt den gesamten Fluss automatisch:

Holt alle selbst zuweisbaren Kanäle via listChannels()
Zeigt Kanäle mit Suchfunktion an, um spezifische PRs zu finden
Lädt das Update nach Auswahl herunter
Fordert zum Neuladen mit den Optionen „Jetzt neu laden“ / „Später“ an

Option 2: Benutzerdefinierter Kanal-Selektor-UI

Bauen Sie einen Kanalwechsler in Ihre App ein, der verfügbare PR-Kanäle auflistet und es Testern ermöglicht, einen auszuwählen. Dies verwendet zwei Schlüssel-APIs:

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 können Sie 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 ein vollständiges React-Komponentenbeispiel, siehe unser Artikel über das Channel-Surfen.

Reinigung der PR-Kanäle

Wenn ein PR abgeschlossen oder geschlossen wird, möchten Sie wahrscheinlich den Kanal reinigen. Fügen Sie einen anderen 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 Kanalliste sauber.

Kompatibilität der Version

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 überprüft automatisch die Versionen. Wenn ein PRs Bundle eine andere nativen Version als die installierte ansteuert, wird die Aktualisierung nicht angewendet. Dies verhindert Abstürze durch inkompatible code.

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

Wer sich von PR-Vorschau profitiert

QA-Engineeure

Testen Sie Funktionen sofort, wenn PRs geöffnet werden
Zwischen mehreren PRs hin- und herwechseln, ohne neu zu installieren
Überprüfen Sie Reparaturen und Rückschritte auf echten Geräten
Keine Wartezeit mehr für die TestFlight-Verarbeitung

Produktmanager

Überprüfen Sie Funktionen, bevor sie integriert werden
Geben Sie Feedback direkt auf dem PR
Überprüfen Sie, ob die Implementierung den Anforderungen entspricht
Verringern Sie die Review-Zykluszeit

Entwickler

Erhalten Sie schnellere Feedback auf Änderungen
Demo-Funktionen an Stakeholdern sofort vorstellen
Fehler bei spezifischen Benutzern mit dem Debugger auflösen
Weniger Zeit für die Verwaltung von Beta-Versionen

Vergleich: Traditionell vs PR-Vorschau

Aspekt	TestFlight/Beta	Capgo PR-Vorschau
Zeit für die Erstellung	15-30 min	<1 min
Änderung von PRs	5+ min Neustart	10 Sekunden
Komplexität der Einrichtung	App Store-Zugangsdaten	Ein Workflow-Datei
Säubern	Manuell	Automatisch
Native code changes	Erforderlich	Optional (nur JS)

Gute Praxis

Benenne Kanäle klar: Verwende pr-{number} eine Konvention für eine einfache Identifizierung
Automatische Löschung: Löschung von Kanälen bei geschlossenen Pull Requests
Einschränkung des Zugriffs: Aktivierung des Shake-Menüs nur in Debug- oder Staging-Builds
Beschreibung des Prozesses: Hinzufügen von Testanweisungen zu Ihrem Pull-Request-Vorlage
Behandlung von Fehlern: Überprüfung, ob die Kanal-Erstellung erfolgreich ist, bevor Kommentare gepostet werden

Wann PR-Vorschau nicht verwendet werden sollte

PR-Vorschau ist für JavaScript- und CSS-Änderungen vorgesehen. Wenn Ihr Pull-Request enthält:

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

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

Kombination mit Channel-Surfen

PR-Vorschauen funktionieren am besten, wenn sie mit channel-Surfen kombiniert werdenIhr App kann haben:

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

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

Ressourcen

Zusammenfassung

PR-Vorschauen verändern, wie Ihre Team Mitglieder mobile Funktionen überprüfen und testen. Anstatt auf die TestFlight-Verarbeitung zu warten und mehrere Beta-Versionen zu verwalten, können Tester auf jeden Kanal in Sekunden wechseln, indem sie die App verwenden, die sie bereits installiert haben.

Die Einrichtung ist minimal - ein GitHub Actions-Aufgaben-Workflow-Datei - und die Vorteile summieren sich über Ihr Team. Die QA bleibt unblockiert, Produktmanager können schneller überprüfen und Entwickler erhalten schnellere Feedbacks.

Beginnen Sie, indem Sie die Aufgaben-Workflow in einem Repository hinzufügen und sehen Sie, wie es Ihre Überprüfungsprozess ändert.

Fortsetzen Sie von Turn Every Pull Request Into an Installable Preview

Wenn Sie bereits Wenn Sie bereits Turn Every Pull Request Into an Installable Preview verwenden um das Kanalrouting und die rollenbasierte Bereitstellung zu planen, verbinden Sie es mit Kanäle zur Implementierungsdetail in Kanäle Kanäle zur Implementierungsdetail in Kanäle Kanäle zur Implementierungsdetail in Kanäle Prüfungs-Testlösung zur Produktworkflow in Prüfungs-Testlösung, und Zielgruppenziel-Lösung zur Produktworkflow in Zielgruppenziel-Lösung.

Jede Pull-Anfrage in eine installierbare Vorschau umwandeln