Jeder Pull Request in eine installierbare Vorschau umwandeln

Jedes mobilen Entwicklerteam kennt das Problem: Eine Funktion ist für die Überprüfung bereit, aber es dauert Stunden, bis sie in die Hände der Stakeholder gelangt. 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 jeder Pull-Anfrage auf das Gerät ziehen könnte, ohne dass eine Wiederinstallation oder Verzögerungen bei der App-Store-Verarbeitung erforderlich sind?

Dass ist PR-Vorschau aktivieren. Wenn ein Entwickler einen Pull-Request öffnet, erstellt ein GitHub-Action einen dedizierten Update-Kanal und veröffentlicht die Änderungen. Jeder mit der App installiert kann sich auf diesen Kanal umschalten, die Funktion testen und wieder zurück umschalten - 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 bedeuten wiederum Wartezeit

Das 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 US-Dollar pro PR an verlorener Produktivität kostet.

How PR Voransichten funktionieren

PR-Voransichten 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-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-Voransichten

Bevor Sie PR-Vorschauen umsetzen können, muss Ihr Projekt mit Capgo Live Updates konfiguriert werden. Folgen Sie dem Capgo-RichtlinienfürAnfänger wenn Sie das noch nicht getan haben.

GitHub-Actions-Arbeitsfläche

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 beim Erstellen des Kanals. Dies ermöglicht es Testern, den Kanal innerhalb der App mithilfe der setChannel() API zu wechseln.

Einrichten des Capgo-Tokens

Gehen Sie zu Ihrem Capgo-Dashboard
Navigieren Sie zu Einstellungen > API-Schlüssel
Ein neues Schlüsselpaar mit __CAPGO_KEEP_0__ all Rechte
Fügen Sie es als __CAPGO_KEEP_0__-Repository-Secrets hinzu CAPGO_TOKEN in your GitHub repository secrets

Es gibt zwei Möglichkeiten, wie Tester auf einen PR-Kanal wechseln können:

Option 1: Shake-Menü (Einfachste)

Enable the shake menu with channel selector in your Capacitor config:

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

Das Shake-Menü übernimmt den gesamten Workflow automatisch: pr-123Alle selbst zuweisbaren Kanäle via __CAPGO_KEEP_0__

Option 2: __CAPGO_KEEP_0__-Konfiguration

Testers wechseln zwischen Kanälen, indem sie die __CAPGO_KEEP_0__-Konfiguration öffnen, den gewünschten Kanal auswählen und die Aktualisierung herunterladen und anwenden. listChannels()
Anzeigt Kanäle mit Suchfunktion, um spezifische PRs zu finden
Herunterlädt die Aktualisierung nach der Auswahl
Fordert eine Neuladung mit den Optionen „Jetzt neu laden“ / „Später“ an

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. 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 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 ein vollständiges React-Beispiel siehst du in unserem Artikel Überprüfung der PR-Kanäle.

Wenn ein PR verschmolzen oder geschlossen wird, möchten Sie den Kanal aufräumen. Fügen Sie einen anderen Workflow hinzu:

Für ein vollständiges React-Beispiel siehst du in unserem Artikel "Kanalwechsel"

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.

Versionenkompatibilität

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

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

Für Pull-Requests, die nativ Ä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 nativen code berühren.

Wer sich von Pull-Request-Vorschau profitiert

Qualitätsingenieure

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

Produktmanager

Features überprüfen, bevor sie integriert werden
Feedback direkt auf dem PR geben
Überprüfen, ob die Implementierung den Anforderungen entspricht
Zeit für die Überprüfung reduzieren

Entwickler

Rasche Feedback zu Änderungen erhalten
Features sofort an Stakeholder vorstellen
Probleme bei bestimmten Benutzern debuggen
Weniger Zeit für die Verwaltung von Beta-Versionen aufwenden

Vergleich: Traditionell vs. PR-Vorschauen

Aspekt	TestFlight/Beta	Capgo Voransicht
Buildzeit	15-30 min	<1 min
PRs wechseln	5+ min Reinstallierung	10 Sekunden
Setup-Komplexität	App Store-Zugangsdaten	Eine Workflow-Datei
Reinigung	Manuell	Automatisch
Native code Änderungen	Erforderlich	(JS nur optional)

Best Practices

Benenne Kanäle klar: Verwende pr-{number} Konvention für eine einfache Identifizierung
Automatischer Löschvorgang: Lösche Kanäle immer, wenn PRs geschlossen werden
Zugriff einschränken: Aktiviere Shake-Menü nur in Debug- oder Staging-Builds
Dokumentieren Sie den Prozess: Fügen Sie Anweisungen zur Prüfung Ihrem Pull-Request-Vorlage hinzu
Fehler verarbeiten: Überprüfen Sie, ob die Erstellung des Kanals erfolgreich ist, bevor Sie Kommentare posten

Wenn Sie PR-Vorschau nicht verwenden sollten

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.

Kombination mit Channel Surfing

PR-Vorschauen funktionieren am besten, wenn sie mit Fernsehen von Kanälen kombiniert werden.Ihr 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 jeden PR-Kanal wechseln, die Funktion testen und dann wieder zurückwechseln – alles mit der gleichen installierten App.

Ressourcen

Zusammenfassung

PR-Vorschauen verändern, wie Ihre Team mobile Funktionen überprüft und testet. Anstatt auf die Verarbeitung von TestFlight zu warten und mehrere Beta-Versionen zu verwalten, können Tester in 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. 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 Ihre Überprüfungsprozess ändert.

Fortsetzen Sie von Turn Every Pull Request Into an Installable Preview

Wenn Sie "Turn Every Pull Request Into an Installable Preview" verwenden Wenn Sie "Turn Every Pull Request Into an Installable Preview" verwenden um Kanalrouten und Stufenrollout zu planen, verbinden Sie es mit Kanälen Kanälen Kanälen für die Implementierungsdetails in den Kanälen, Kanäle für die Implementierungsdetails in den Kanälen, Beta-Testlösung für den Produktworkflow in der Beta-Testlösung, und Versionziel-Lösung für den Produktworkflow in der Versionziel-Lösung.

Jede Pull-Anfrage in eine installierbare Vorschau umwandeln