Jeden Pull Request in eine installierbare Vorschau umwandeln

Jedes mobiles 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 Managements von Beta-Builds.

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

Dass ist PR-Vorschau 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 mit der App installiert kann auf diesen Kanal wechseln, die Funktion testen und wieder zurückkehren – alles ohne das App-Icon zu verlassen, das sie bereits haben.

Das TestFlight-Problem

Die traditionelle Workflow für die Überprüfung 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 ein weiteres Warten

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

Wie PR-Vorschau funktioniert

PR-Vorschau nutzen Capgo’s 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 in der 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. 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 Flag, wenn Sie den Kanal erstellen. Dies ermöglicht es Testern, den Kanal innerhalb der App mithilfe des setChannel() API zu wechseln.

Einstellungen für Capgo Token

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

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

Testen Sie, indem Sie Ihr Gerät schütteln, 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 darauf, um ihn auszuwählen, und die App lädt und übernimmt automatisch die Aktualisierung. Wenn das Testen abgeschlossen ist, schütteln Sie erneut und wechseln zurück in die Produktion. pr-123Das Schüttelmenü handhabt den gesamten Fluss automatisch:

Alle selbst zuweisbaren Kanäle via __CAPGO_KEEP_0__ abrufen

Kanäle mit Suchfunktion anzeigen, um spezifische PRs zu finden listChannels()
Die Aktualisierung nach Auswahl herunterladen
Zum Neuladen auf „Jetzt neu laden“ / „Später“ anfragen
Option 2: Benutzerdefinierte Kanal-Selektions-UI

Erstellen Sie einen Kanalwechsler in Ihrer App, der die verfügbaren PR-Kanäle auflistet und es den Testern ermöglicht, einen auszuwählen. Dazu werden zwei Schlüssel-APIs verwendet:

- Alle Kanäle mit Selbstzuweisung abrufen

listChannels() - Das Gerät auf den ausgewählten Kanal umschalten
setChannel() Mit diesen Bausteinen können Sie eine einfache UI erstellen:

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

// 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-Component-Beispiel siehe unser Artikel über das Fernsehprogramm.

Sauberkeit von Pull-Request-Kanälen

Wenn ein Pull-Request abgeschlossen oder geschlossen wird, möchten Sie wahrscheinlich den Kanal saubermachen. 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 Pull-Request geschlossen wird, und hält Ihre Liste der Kanäle sauber.

Versionen-Kompatibilität

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

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

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

Wer von Pull-Request-Vorschau profitiert

QA-Engineeure

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

Produktmanager

Überprüfen Sie Funktionen bevor sie in die Mergen kommen
Geben Sie Feedback direkt auf dem Pull Request
Überprüfen Sie, ob 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
Fehler bei spezifischen Benutzern debuggen
Weniger Zeit für die Verwaltung von Beta Builds

Vergleich: Traditionell vs PR-Vorschau

Aspekt	TestFlight/Beta	Capgo PR-Vorschau
Aufbauzeit	15-30 min	<1 min
Wechsel von PRs	5+ min Reinstallierung	10 Sekunden
Setup-Komplexität	App Store-Zugangsdaten	Ein Workflow-File
Reinigung	Manuell	Automatisch
Nativ code-Änderungen	Erforderlich	Optional (JS nur)

Best Practices

Nenne Kanäle klar: Verwende pr-{number} eine Konvention für eine einfache Identifizierung
Automatischer Clean-up: Immer Kanäle löschen, wenn PRs geschlossen werden
Zugriffsbeschränkung: Nur den Shake-Menü in Debug-/Staging-Builds aktivieren
Dokumentationsprozess: Testanweisungen in Ihrem PR-Vorlage hinzufügen
Fehlergrößen vertragen: Überprüfen, ob die Kanal-Erstellung erfolgreich ist, bevor Kommentare posten

Wenn PR-Vorschau nicht verwendet werden soll

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

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

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

Kombination mit Channel Surfing

PR-Vorschauen funktionieren am besten, wenn sie mit dem Channel Surfing kombiniert werden. Channel SurfingIhr App kann haben:

production - Stabile Releases für alle Benutzer
beta - Frühe Zugriffe für opt-in-Benutzer
pr-123 - Funktionen-Vorschauen für bestimmte PRs

Tester mit Produktionsbuilds können auf jede PR-Kanal wechseln, die Funktion testen und dann wieder zurückwechseln – alles mit der gleichen installierten App.

Ressourcen

Schlussfolgerung

PR-Vorschauen verändern, wie Ihre Team Mitglieder Reviews und Tests von mobilen Funktionen durchführen. Anstatt auf die TestFlight-Verarbeitung zu warten und mehrere Beta-Builds zu verwalten, können Tester auf jeden PR-Kanal in Sekunden wechseln, indem sie die App verwenden, die sie bereits installiert haben.

Die Einrichtung ist minimal - ein GitHub Aktionen-Workflow-Datei - und die Vorteile summieren sich über Ihr Team. QA bleibt unblockiert, Produktmanager können schneller reviewen und Entwickler erhalten schnellere Feedback.

Beginnen Sie damit, die Workflow in einem Repository hinzuzufügen und sehen Sie, wie es Ihre Review-Prozess ändert.

Weitergehen von Jeder Pull Request in eine Installierbare Vorschau

Wenn Sie Jeder Pull Request in eine Installierbare Vorschau um Kanalrouting und rollende Veröffentlichung zu planen und zu verbinden mit Kanäle für die Implementierungsdetails in Kanäle, Kanäle für die Implementierungsdetails in Kanäle, Kanäle für die Implementierungsdetails in Kanäle, Beta-Testlösung für den Produktworkflow in Beta-Testlösung, und Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung.

Jeden Pull Request in eine installierbare Vorschau verwandeln