Jeden Pull Request in eine installierbare Vorschau umwandeln

Was wäre, wenn Ihre Produktions-App die neuesten Änderungen aus jeder Pull-Anfrage direkt auf das Gerät ziehen könnte, ohne dass es zu Neustarts oder Verzögerungen bei den App-Stores kommt?

Das ist

PR-Vorschau-Anzeigen PR-Vorschau-Anzeigen enable. Wenn ein Entwickler einen Pull-Request öffnet, erstellt ein GitHub-Action eine dedizierte 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 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. 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 nutzen das Capgo-Kanal-System, um pro-PR-Update-Streams zu erstellen. Hier ist der Ablauf:

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

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

Einrichten von PR-Vorschauen

Bevor Sie PR-Vorschauen implementieren können, muss Ihr Projekt mit Capgo Live Updates konfiguriert werden. Folgen Sie dem 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, sich auf den Kanal innerhalb der App umzuschalten, indem sie die setChannel() API

Einrichten von Capgo Token

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

Wie Tester Kanäle wechseln

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

Das Shake-Menü mit Kanal-Selektor in deinem Capacitor Konfiguration aktivieren:

// 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. pr-123auf), tippen, um ihn auszuwählen, und die App lädt und aktualisiert sich automatisch. Wenn das Testen abgeschlossen ist, schütteln sie erneut und wechseln zurück in die Produktion.

Das Shake-Menü handhabt den gesamten Flow automatisch:

Alle selbst-zuweisbaren Kanäle via listChannels()
Anzeige von Kanälen mit Suchfunktion, um spezifische PRs zu finden
Herunterladen der Aktualisierung nach Auswahl
Wiederherstellungsanforderung mit den Optionen „Jetzt wiederherstellen“ / „Später“

Option 2: Benutzerdefinierter Kanal-Selektions-UI

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

listChannels() - Abrufen aller Kanäle mit Selbstzuweisung aktiviert
setChannel() - Wechseln Sie 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;
}

Mithilfe dieser Bausteine 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-Beispiel, sehen Sie sich unseren Artikel zum Kanalwechsel an.

Sauberung von PR-Kanälen

Wenn ein PR verschmolzen oder geschlossen wird, möchten Sie den Kanal aufräumen. 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 Liste der Kanäle sauber.

Versionenkompatibilität

PR-Vorschauen funktionieren nur, wenn das JavaScript-Bundle mit der installierten nativen Version kompatibel ist. Wenn Ihr PR nativ 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 nativ Version als die installierte ansteuert, wird die Aktualisierung nicht angewendet. Dies verhindert Crashs von inkompatiblen code.

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

Wer sich von PR-Vorschauen profitiert

QA-Engineeure

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 integriert werden
Geben Sie Feedback direkt auf dem PR
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
Debuggen von Problemen mit bestimmten Benutzern
Weniger Zeit für die Verwaltung von Beta-Versionen

Vergleich: Traditionell vs. PR-Vorschau

Aspekt	TestFlight/Beta	Capgo Vorabansicht
Aufbauzeit	15-30 min	<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 einfache Identifizierung
Auto-Löschen: Lösen Sie immer Kanäle, wenn PRs schließen
Beschränken Sie den Zugriff: Aktivieren Sie nur das Shake-Menü in Debug-/Staging-Builds
Dokumentiere den Prozess: Füge Testanweisungen zu deinem Pull-Request-Vorlage hinzu
Feihere Fehlern gegenüber: Überprüfe, ob die Kanal-Erstellung erfolgreich ist, bevor du Kommentare postest

Wann nicht PR-Vorschau verwenden

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

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

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

Kombinieren mit Channel Surfing

PR-Vorschauen funktionieren am besten, wenn sie mit Fernsehen von Kanälen kombiniert werden.Ihre 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

Testern mit Produktionsbuilds können auf jeden 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 Ihre Team mobile Funktionen überprüft und testet. Anstatt auf die TestFlight-Verarbeitung zu warten und mehrere Beta-Builds zu verwalten, können Tester auf jede PR-Kanal in Sekunden wechseln, indem sie die App verwenden, die sie bereits installiert haben.

Die Einrichtung ist minimal - ein einziges GitHub Actions-Aufgaben-Workflow-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 Workflow 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 Turn Every Pull Request Into an Installable Preview um Kanalrouten und rollende Veröffentlichung zu planen, verbinden Sie es mit Channels Channels Channels für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, 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 verwandeln