Jeden 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 aus jeder Pull-Anfrage direkt auf das Gerät ziehen könnte, ohne dass eine Wiederinstallation oder eine Verzögerung durch den App-Store erforderlich ist?

Dass ist PR-Vorschau aktivieren. Wenn ein Entwickler einen Pull-Antrag ö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 Prü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 - Jede Änderung bedeutet erneutes 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 Euro pro PR an verlorenem Produktivitätsverlust kostet.

How PR Voransichten funktionieren

PR-Voransichten 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 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ür-Einsteiger falls 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, wenn Sie den Kanal erstellen. Dies ermöglicht es Testern, sich auf den Kanal innerhalb der App umzuschalten, indem sie die setChannel() API verwenden.

Einstellung von Capgo Token

Gehen Sie zu Ihrem Capgo-Dashboard
Navigieren Sie zu Einstellungen > API-Schlüssel
Erstellen Sie eine neue Schlüssel mit all Berechtigungen
Fügen Sie sie als CAPGO_TOKEN in Ihrem GitHub Repository-Secrets

Wie Tester Kanäle wechseln

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

Aktivieren Sie das Shake-Menü mit Kanal-Selektor in Ihrer Capacitor Konfiguration:

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

Die 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.), tippen darauf, um ihn auszuwählen, und die App lädt und appliziert automatisch die Aktualisierung. Wenn sie fertig getestet haben, schütteln sie erneut und wechseln zurück auf die Produktionsumgebung. pr-123Das Shake-Menü handhabt den gesamten Workflow automatisch:

Abruft alle selbst-zuweisbaren Kanäle via

Abruft alle selbst-zuweisbaren Kanäle via 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 sieh dir unsere Artikel zum Kanalwechsel an Reinigung von PR-Kanälen.

Wenn ein PR verschmolzen oder geschlossen wird, möchtest du den Kanal aufräumen. Füge einen weiteren Workflow hinzu:

Für ein vollständiges React-Beispiel sieh dir unsere Artikel zum Kanalwechsel an

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 nativere Version als die installierte ansteuert, wird die Aktualisierung nicht angewendet. Dies verhindert Crashs durch inkompatible 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 von PR-Vorschauen profitiert

QA-Engineeure

Testen Sie Funktionen sofort, wenn PRs geöffnet werden
Switchen Sie zwischen mehreren PRs, ohne neu zu installieren
Überprüfen Sie Reparaturen und Rückschritte auf echten Geräten
Keine Wartezeit mehr für 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

Rasches 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-Vorschau

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
code Änderungen in der Native Sprache	Erforderlich	Optional (nur JS)

Best Practices

Benenne Kanäle klar: Verwende pr-{number} eine Konvention für eine einfache Identifizierung
Automatischer Löschvorgang: Lösche Kanäle immer, wenn PRs geschlossen werden
Beschränke Zugriff: Aktiviere nur das Shake-Menü in Debug- oder Staging-Builds
Das Verfahren dokumentieren: Anweisungen zur Prüfung in Ihre Pull-Request-Vorlage einfügen
Feuerungen sanft handhaben: Überprüfen Sie, ob die Erstellung des Kanals erfolgreich ist, bevor Sie Kommentare posten

Wann PR-Vorschau nicht verwendet werden sollte

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

Neue Capacitor-Plugins
iOS native code changes
iOS-native code-Änderungen
Android-native __CAPGO_KEEP_0__-Änderungen

Abhängigkeitsaktualisierungen, die native Builds beeinflussen

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

PR-Vorschauen funktionieren am besten, wenn sie mit Kanalwechsel 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 Pull-Requests

Testern mit Produktionsbuilds können auf jeden PR-Kanal wechseln, die Funktion testen und dann wieder zurückwechseln – alles mit derselben installierten App.

Ressourcen

[Zusammenfassung]

[PR-Vorschau ä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 innerhalb von 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-File - und die Vorteile summieren sich über Ihr Team. QA bleibt unblockiert, Produktmanager überprüfen schneller und Entwickler erhalten schnellere Feedbacks.]

[Beginnen Sie damit, das Workflow in einem Repository hinzuzufügen und sehen Sie, wie es Ihre Überprüfungsprozess ändert.]

[Weitergehen 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 Stufenrollout zu planen, verbinden Sie es mit [Kanälen] [Kanälen] [Kanälen] [Kanälen] Für die Implementierungsdetails in den Kanälen, Kanäle Für die Implementierungsdetails in den Kanälen, Testlösung für Beta-Versionen Für den Produktworkflow in der Testlösung für Beta-Versionen, und Lösung für Zielversionen Für den Produktworkflow in der Lösung für Zielversionen.

Jede Pull-Anfrage in ein installierbares Vorschau umwandeln