Jede Pull-Anfrage in ein installierbares Vorschau-Preview umwandeln

Jedes mobile 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.

Wie wäre es, wenn Ihre Produktions-App die neuesten Änderungen aus jedem Pull Request direkt auf das Gerät ziehen könnte, ohne dass es zu einem Neustart oder einer Verzögerung bei der App-Store-Veröffentlichung kommt?

Das ist, was PR-Vorschauen ermöglichen. 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 wechseln, die Funktion testen und wieder zurückkehren – alles ohne die App zu verlassen, die er bereits hat.

Das TestFlight-Problem

Die traditionelle Workflow für die Testung von mobilen Funktionen sieht ungefähr so aus:

1. Entwickler öffnet PR - Code ist bereit für die Überprüfung
2. Warten auf TestFlight - 15-30 Minuten Verarbeitungszeit
3. Finden und installieren - Tester suchen nach der richtigen Build
4. Testen und wiederholen - Jeder Änderung bedeuten erneut 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 Produktivitätsverlusten kostet.

Wie PR-Vorschau funktioniert

PR-Vorschau nutzen Capgo's Kanal-System, um pro-PR-Update-Streams zu erstellen. Hier ist der Ablauf:

1. PR geöffnet oder aktualisiert - GitHub-Aktion ausgelöst
2. Bundle hochgeladen - Ihre JS/CSS-Änderungen gehen in einen pro-PR-Kanal
3. Kommentar veröffentlicht - Testern werden Anweisungen im Pull-Request bereitgestellt
4. Instant-Test - 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.

Einstellungen für Pull-Request-Vorschauen

Bevor Sie Pull-Request-Vorschauen implementieren können, muss Ihr Projekt mit Capgo Live Updates konfiguriert sein. Folgen Sie der Capgo Schnellstartanleitung falls Sie das noch nicht getan haben.

GitHub Actions-Aufgaben

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 das --self-assign Flag setzen, wenn der Kanal erstellt wird. Dies ermöglicht es Testern, auf den Kanal von innerhalb der App umzuschalten, indem sie den setChannel() API.

Capgo Einrichten

1. Gehe zu deinem Capgo-Dashboard
2. Navigiere zu Einstellungen > API-Schlüssel
3. Erstelle einen neuen Schlüssel mit all Rechten
4. Hinzufügen als CAPGO_TOKEN im deinem GitHub-Repository-Secrets

Wie Testers auf einen PR-Kanal umschalten

Es gibt zwei Möglichkeiten, wie Testers auf einen PR-Kanal umschalten:

Option 1: Shake-Menü (Einfachste)

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. pr-123), tippen darauf, um ihn auszuwählen, und die App lädt und aktualisiert sich automatisch. Wenn sie fertig getestet haben, schütteln sie erneut und wechseln zurück auf die Produktionsversion.

Das Shake-Menü handhabt den gesamten Workflow automatisch:

1. Holt alle selbst-zuweisbaren Kanäle via listChannels()
2. Zeigt Kanäle mit Suchfunktion an, um bestimmte PRs zu finden
3. Lädt die Aktualisierung nach Auswahl herunter
4. Fordert zum Neuladen mit den Optionen „Jetzt neu laden“ / „Später“ an

Option 2: Benutzerdefiniertes Kanal-Selektor-UI

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

• listChannels() - Holt alle Kanäle mit selbst-zuweisbarer Funktion ab
• setChannel() - Wechseln Sie das Gerät auf die ausgewählte Kanalinstanz

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 können Sie eine einfache Benutzeroberfläche 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 Beispiel eines React-Komponents, sehen Sie sich bitte unser Artikel über das Kanalsurfen an Sauberkeit der PR-Kanäle.

Wenn ein Pull-Request abgeschlossen oder geschlossen wird, möchten Sie wahrscheinlich die Kanalinstanz aufräumen. Fügen Sie einen weiteren Workflow hinzu:

Dies entfernt die Kanalinstanz, wenn der Pull-Request geschlossen wird, und hält Ihre Liste der Kanäle sauber.

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

Kompatibilität der Version

PR-Vorschauen funktionieren nur, wenn das JavaScript-Paket mit der installierten nativen Version kompatibel ist. Wenn Ihr Pull-Request nativ __CAPGO_KEEP_0__ Änderungen (neue __CAPGO_KEEP_1__ Plugins, iOS/Android-Modifikationen) enthält, benötigen die Tester eine neue nativ gebaute Version.

code überprüft automatisch die Versionen. Wenn ein Pull-Request-Paket eine andere nativere Version als die installierte ansteuert, wird die Aktualisierung nicht angewendet. Dies verhindert Crashs durch inkompatible Capacitor.

Capgo automatically checks version compatibility. If a PR’s bundle targets a different native version than what’s installed, the update won’t be applied. This prevents crashes from incompatible code.

For PRs that do require native changes, you’ll need to distribute a new TestFlight/Play Store build. PR previews work best for JavaScript, CSS, and asset changes that don’t touch native code.

__CAPGO_KEEP_0__ ist ein Platzhalter, der nicht übersetzt werden sollte.

QA-Engineer

• Funktionen sofort testen, wenn PRs geöffnet werden
• Zwischen mehreren PRs wechseln, ohne neu zu installieren
• Fehler und Rückschritte auf echten Geräten überprüfen
• Keine Wartezeit mehr für die TestFlight-Verarbeitung

Produktmanager

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

Entwickler

• Schnelleres Feedback auf Änderungen erhalten
• Demo-Funktionen für Stakeholder sofort bereitstellen
• Probleme bei spezifischen Benutzern debuggen
• Weniger Zeit für die Verwaltung von Beta-Versionen aufwenden

Vergleich: Traditionell vs. PR-Vorschau

Best Practices

1. Kanäle klar benennen: Verwenden pr-{number} eine Konvention für eine einfache Identifizierung
2. Auto-Reinigung: Löschung von Kanälen bei geschlossenen Pull-Requests
3. Zugriffsbeschränkung: Aktivierung des Shake-Menüs nur in Debug- oder Staging-Builds
4. Beschreibung des Prozesses: Hinzufügen von Testanweisungen zu Ihrem Pull-Request-Vorlage
5. Behandlung von Fehlern: Überprüfung, dass der Kanal erfolgreich erstellt wurde, bevor Kommentare gepostet werden

Wann nicht PR-Vorschau verwenden

PR-Vorschau 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.

Kombinieren Sie mit Channel-Surfen

PR-Vorschauen funktionieren am besten, wenn sie mit dem Channel-Surfen 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

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

Ressourcen

• Capgo Live Updates Dokumentation
• Kanäle Dokumentation
• Kanal-Surf-Guide
• CLI Befehlsreferenz
• PR-Vorschau-Lösungen-Seite

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-Builds zu verwalten, können Tester in Sekunden zu jedem PR-Kanal wechseln, indem sie die App verwenden, die sie bereits installiert haben.

Die Konfiguration ist minimal – ein GitHub Actions-Aufgaben-Workflow-Datei – und die Vorteile summieren sich über Ihr Team. QA bleibt unblockiert, Produktmanager können schneller überprüfen und Entwickler erhalten schnellere Feedbacks.

Beginnen Sie, indem Sie die Aufgaben-Workflow in einem Repository hinzufügen und sehen Sie, wie es Ihre Überprüfungsprozess ändert.

Fortsetzen Sie von Turn Every Pull Request Into an Installable Preview

Wenn Sie Jeden Pull Request in eine installierbare Vorschau umwandeln um Kanalrouting und rollende Veröffentlichung zu planen und es mit Kanäle für die Implementierungsdetails in Kanäle Kanäle für die Implementierungsdetails in Kanäle für die Implementierungsdetails in Kanäle Beta-Testlösung für den Produktworkflow in der Beta-Testlösung, und Versionziel-Lösung __CAPGO_KEEP_0__ zur Produktworkflow in der Version-Ziel-Lösung.