Jede Pull-Anfrage in einen installierbaren 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, indem man sich durch das TestFlight- oder Google Play-Beta-Review-Labyrinth navigiert. Was Minuten dauern sollte, wird zu Stunden der Wartezeit, Installation und Verwaltung von Beta-Builds.

What if your production app could pull the latest changes from any pull request directly onto the device, without any reinstalls or app store delays?

Das ist, was PR-Voransichten ermöglichen. Wenn ein Entwickler eine Pull-Anforderung öffnet, erstellt ein GitHub-Action eine dedizierte Update-Kanal und veröffentlicht die Änderungen. Jeder, der die App installiert hat, kann sich auf diesen Kanal umschalten, die Funktion testen und wieder zurückkehren – alles ohne die App zu verlassen, die er bereits hat.

Das TestFlight-Problem

Das traditionelle Workflow für die Prüfung von mobilen Funktionen sieht ungefähr so aus:

1. Entwickler öffnet Pull-Request - 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 wieder ein 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 Pull-Request an Produktivitätsverlusten kostet.

Wie PR-Vorschauen funktionieren

PR-Vorschauen nutzen das Capgo-Kanal-System, um pro-PR-Update-Streams zu erstellen. Hier ist der Ablauf:

1. PR geöffnet oder aktualisiert - GitHub-Aktion ausgelöst
2. Bündel hochgeladen - Ihre JS/CSS-Änderungen gehen in einen PR-spezifischen Kanal
3. Kommentar gepostet - Tester erhalten Anweisungen im PR
4. Instant-Testen - Kanäle wechseln, testen, zurückwechseln

Keine neuen App-Installationen. Keine TestFlight-Hinweise. Die gleiche Produktions-App kann von verschiedenen Update-Kanälen ziehen.

Einstellungen für PR-Vorschauen

Bevor Sie PR-Vorschauen implementieren können, muss Ihr Projekt mit Capgo Live Updates konfiguriert sein. Folgen Sie den Richtlinie für Capgo Wenn Sie das noch nicht getan haben.

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

Einrichten des Capgo-Tokens

1. Gehe zu deinem Capgo-Dashboard
2. Navigiere zu Einstellungen > API-Schlüssel
3. Erstelle einen neuen Schlüssel mit all Berechtigungen
4. Fügen Sie es als CAPGO_TOKEN in Ihrem GitHub Repository-Secrets

Wie Tester Kanäle wechseln

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

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

Testers shake their device to open the debug menu, which shows a list of available channels with a search bar. They find their PR channel (e.g., pr-123Klicken Sie auf es, um es auszuwählen, und die App lädt und übernimmt die Aktualisierung automatisch. Nachdem Sie getestet haben, bewegen Sie den App wieder in den Produktionsmodus.

Holt alle selbst-zuweisbaren Kanäle via

1. Alle selbst zuweisbaren Kanäle abrufen listChannels()
2. Anzeigt Kanäle mit Suchfunktion, um spezifische Pull Requests zu finden
3. Lädt die Aktualisierung nach der Auswahl herunter
4. Fordert zum Neuladen 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-Component-Beispiel siehe Sauberkeit bei den PR-Kanälen.

Bereinigung von PR-Kanälen

Dies entfernt den Kanal, wenn der PR geschlossen wird, und hält deine Kanalliste 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 }}

Dies entfernt den Kanal, wenn der Pull-Request geschlossen wird, und hält Ihre Kanalliste sauber.

Version Kompatibilitä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 Version-Kompatibilität. Wenn ein PR-Bundle eine andere nativen 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 sich von PR-Vorschauen profitiert

Wer sich von PR-Vorschauen profitiert

• Testen Sie Funktionen sofort, wenn PRs geöffnet werden
• Wechseln Sie zwischen mehreren PRs, ohne neu zu installieren
• Überprüfen Sie Fixes und Rückschritte auf echten Geräten
• Keine Wartezeit mehr für die TestFlight-Verarbeitung

Produktmanager

• Überprüfen Sie Funktionen, bevor sie eingefügt werden
• Feedback direkt auf dem PR geben
• Überprüfen, ob die Implementierung den Anforderungen entspricht
• Zeit für die Überprüfung verkürzen

Entwickler

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

Vergleich: Traditionell vs. PR-Vorschau

Best Practices

1. Benennen Sie Kanäle klar: Use pr-{number} Konvention für eine einfache Identifizierung
2. Auto-cleanup: Lösen Sie immer Kanäle, wenn PRs geschlossen werden
3. Beschränken Sie den Zugriff: Aktivieren Sie die Shake-Menü nur in Debug- oder Staging-Builds
4. Dokumentieren Sie den Prozess: In Ihrem PR-Vorlage Testanweisungen hinzufügen
5. Fehlerfallen sanft handhaben: Überprüfen Sie, ob die Kanalbildung erfolgreich ist, bevor Sie Kommentare posten

Wenn Sie PR-Vorschau nicht verwenden sollten

PR-Vorschau ist für JavaScript/CSS-Änderungen vorgesehen. Wenn Ihr PR Folgendes 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-Distribution

Kombination mit Channel Surfing

PR-Vorschau funktioniert am besten, wenn sie mit Kanalwechsel. Ihr App kann haben:

• production - Stabile Releases für alle Benutzer
• beta - Frühzugriff für Benutzer, die sich anmelden
• pr-123 - Funktionen-Vorschau für bestimmte PRs

Testern mit Produktionsbuilds können auf jede PR-Kanal wechseln, die Funktion testen und dann wieder zurückkehren – alles mit der gleichen installierten App.

Ressourcen

• Capgo Live-Updates-Dokumentation
• Lebendliche Updates-Dokumentation
• Kanal-Dokumentation
• CLI Befehlsreferenz
• Lebendliche Updates-Befehlsreferenz

Zusammenfassung

PR-Vorschauen verändern die Art und Weise, wie Ihr Team mobile Funktionen überprüft und testet. Anstatt auf die Verarbeitung von TestFlight und die Verwaltung mehrerer Beta-Versionen zu warten, 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. Die QA bleibt unblockiert, Produktmanager können schneller überprüfen und Entwickler erhalten schnellere Feedback.

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

Fortsetzen Sie mit Turn Every Pull Request Into an Installable Preview

Wenn Sie Capgo verwenden Wenn Sie Turn Every Pull Request Into an Installable Preview verwenden um es mit zu planen, Kanalrouting und rollouts in Stufen zu verbinden Kanälen für die Implementierungsdetails in den Kanälen, Kanälen für die Implementierungsdetails in den Kanälen, Kanäle für die Implementierungsdetails in Kanälen, Testlösung für Beta-Tests für den Produktworkflow in Testlösung für Beta-Tests, und Zielsystemlösung für Versionen für den Produktworkflow in Zielsystemlösung für Versionen.