Jeden Pull Request in eine installierbare Vorschau umwandeln

Jeder mobile Entwicklerteam hat sich schon einmal gefragt: 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 des Wartens, Installierens und der Verwaltung von Beta-Builds.

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

Das ist, was PR-Vorschau möglich macht. Wenn ein Entwickler einen Pull-Request öffnet, erstellt ein GitHub-Action eine dedizierte Update-Kanal und veröffentlicht 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 ein weiteres Warten

Das schafft eine Engstelle. QA wird blockiert, während Builds abgewartet 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 $ pro PR in verlorener Produktivität.

Wie PR-Vorschauen funktionieren

PR-Vorschauen verwenden Capgo’s Kanal-System, um pro-PR-Update-Ströme 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 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.

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

Testern bewegen 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 übernimmt den Update automatisch. Wenn sie mit dem Testen fertig sind, bewegen sie sich erneut und wechseln zurück in die Produktion. pr-123Das Shake-Menü 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()
Update nach Auswahl herunterladen
Zum Neuladen auf "Jetzt neu laden" / "Später" anfragen
Option 2: Benutzerdefinierter Kanal-Selektor-UI

Ein Kanalwechsler in Ihre App integrieren, der die verfügbaren PR-Kanäle auflistet und es den Testern ermöglicht, einen auszuwählen. Dies verwendet zwei Schlüssel-__CAPGO_KEEP_1__s:

- Alle Kanäle mit Selbstzuweisung aktivieren

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

__CAPGO_KEEP_0__

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

For eine vollständige React-Komponentenbeispiel, siehe unser Artikel über das Fernsehen.

Reinigung von PR-Kanälen

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 Liste der Kanäle sauber.

Kompatibilität der Version

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

Capgo überprüft automatisch die Kompatibilität der Version. 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 native Ä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 native code berühren.

Wer 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 die Verarbeitung von TestFlight

Produktmanager

Überprüfen Sie Funktionen, bevor sie in die Hauptquelle eingefügt werden
Geben Sie Feedback direkt auf dem PR
Überprüfen Sie, ob die Implementierung den Anforderungen entspricht
Verringern Sie die Zeit für die Überprüfung

Entwickler

Erhalten Sie schnellere Feedback zu Änderungen
Demo-Funktionen für Stakeholder sofort
Führen Sie Probleme mit bestimmten Benutzern nach
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} 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
Dokumentation des Prozesses: Testanweisungen in Ihrem PR-Vorlage hinzufügen
Fehlergracevoll handhaben: Überprüfen, ob der Kanal erstellt wird, bevor Kommentare gepostet werden

Wenn nicht PR-Vorschau verwenden

PR-Vorschauen sind für JavaScript/CSS-Änderungen. 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 umschalten, die Funktion testen und dann wieder zurück umschalten - alles mit derselben installierten App.

Ressourcen

Zusammenfassung

PR-Vorschauen verändern, wie Ihre Team Pull-Requests und mobile Funktionen überprüft und getestet. Anstatt auf die Verarbeitung von TestFlight 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 Actions-Aufgaben-Workflow-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 Aufgaben-Workflow in einem Repository hinzuzufügen und sehen Sie, wie es Ihre Überprüfungsprozess ändert.

Machen Sie weiter von Turn Every Pull Request Into an Installable Preview

Wenn Sie " Turn Every Pull Request Into an Installable Preview für die Planung der Kanalrouten und der schrittweisen Veröffentlichung, verbinden Sie es mit __CAPGO_KEEP_0__ für die Implementierungsdetails in __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ für die Implementierungsdetails in __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ für die Produktworkflow in __CAPGO_KEEP_1__ und __CAPGO_KEEP_1__ für die Produktworkflow in __CAPGO_KEEP_2__. Geschrieben von protectedTokens

Jede Pull-Anfrage in eine installierbare Vorschau umwandeln