Zum Hauptinhalt springen
PR-Vorschau

Jeden Pull Request auf einem echten Smartphone testen

Deine CI lädt den Web-Build jedes Pull Requests in einen eigenen Capgo Channel hoch. Reviewer scannen einen QR-code oder wechseln in der App den Channel, um es auf ihrem Gerät zu testen; der Channel wird gelöscht, sobald der PR geschlossen wird. Änderungen am nativen code erfordern weiterhin einen neuen Build.

  • Ein Channel pro Pull Request
  • QR code Preview
  • Automatisches Cleanup beim Schließen des PR

Das Problem

Web-Änderungen sollten keinen neuen Binary für das Review benötigen

PRs mit Store-Testing-Builds reviewen

  1. Developer öffnet einen PR

    Die Änderung ist bereit fürs Review, aber niemand kann sie bisher auf einem Handy testen.

  2. Build, Sign und Upload

    Jemand baut ein Native Build für den Branch, signiert es, lädt es bei TestFlight oder einem Play Testing Track hoch und wartet auf die Verarbeitung.

  3. Einladen und Installieren

    Reviewer müssen als Tester hinzugefügt werden und genau diesen Build installieren.

  4. Wiederholung bei jedem Fix

    Jeder Review-Kommentar, der code ändert, bedeutet einen weiteren Build, einen weiteren Upload und eine weitere Installation.

Jede Review-Runde wartet auf ein Native Build, selbst wenn nur JavaScript geändert wurde.

Was das das Team kostet

Jeder Build

Wartet auf Store-Verarbeitung

Jeder Build, den du zu TestFlight oder einem Play-Testing-Track hochlädst, muss erst verarbeitet werden, bevor Tester ihn installieren können. Das gilt für jeden Build.

Jeder PR

Braucht einen eigenen Native Build zum Testen

Ohne Live Updates können Reviewer einen Branch erst testen, nachdem jemand eine neue Binary gebaut, signiert und hochgeladen hat – selbst bei reinen Web-Änderungen.

Spätes Feedback

Review kommt, wenn der Autor schon weiter ist

Wenn Reviews auf Builds warten müssen, kommt Feedback zu spät, der Autor bereits an etwas anderem arbeitet und der Branch vom main-Branch abweicht.

So funktioniert es

So previewen Teams Pull Requests mit Capgo

Vier CI-Schritte: Einmal einen Scoped Key einrichten, pro Push hochladen, die Preview teilen, beim Schließen aufräumen. Alle Befehle stammen aus der Capgo Doku.

  1. App Preview Key erstellen und Previews aktivieren

    Ein Admin erstellt einen App Preview API Key für die CI. Dieser kann Preview-Channels erstellen und Bundles hochladen, aber keine Default- oder Production-Channels ändern. Previews werden pro App einmalig aktiviert.

    # once, run by an admin (not the preview key)
npx @capgo/cli@latest app set com.example.app --preview
    App Preview API Keys

  2. PR-Build in einen eigenen Channel hochladen

    Bei jedem Push baut die CI die Web-App und lädt sie mit einer eindeutigen Bundle-Version hoch. bundle upload --channel erstellt den pr-<number> Channel, falls dieser noch nicht existiert, und verknüpft das Bundle damit.

    npx @capgo/cli@latest bundle upload com.example.app \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "pr-$PR_NUMBER" \
  --bundle "1.2.3-pr.$PR_NUMBER.$GITHUB_RUN_NUMBER"
    PR-Previews in der Channel-Doku

  3. Preview im PR posten

    get-qr gibt einen QR code für den Channel aus, oder die Preview-URLs mit --url, damit die CI diese in einen PR-Kommentar einfügen kann.

    npx @capgo/cli@latest get-qr com.example.app \
  --channel "pr-$PR_NUMBER" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --url
    get-qr-Referenz

  4. Channel löschen, wenn der PR geschlossen wird

    Führe dies beim „pull request closed“-Event aus. Mit einem App Preview Key werden nur der Channel und das verknüpfte Bundle gelöscht, die dieser Key erstellt hat.

    npx @capgo/cli@latest channel delete \
  "pr-$PR_NUMBER" com.example.app \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found
    Channel CLI Referenz

Andere Wege, wie Reviewer zu einem PR-Channel wechseln

Beide benötigen einen Channel mit Self-Assignment. Ein App Preview Key setzt dies nicht; teile daher mit diesem Key den QR-Preview oder setze einen Device Override in der Console.

Shake-Menü

Aktiviere das Shake-Menü in internen Builds. Tester schütteln das Gerät, um das Testmenü von Capgo zu öffnen, und über den Shake-Channel-Selector können sie einen Channel auswählen.

// capacitor.config.ts (internal builds)
CapacitorUpdater: {
  shakeMenu: true,
}

In-App Switcher

Füge ein Channel-Feld in den Developer Settings hinzu und rufe setChannel() mit dem PR-Channelnamen auf.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

await CapacitorUpdater.setChannel({
  channel: 'pr-123',
  triggerAutoUpdate: true,
})
setChannel()-Referenz

Wer nutzt PR Previews?

Jeder, der den Pull Request reviewt, kann ihn auf einem Smartphone testen – nicht nur der Author.

QA-Engineers

  • Teste den Web-Build des PRs auf deinem eigenen Gerät
  • Wechsle zwischen PR-Channels, ohne die App neu zu installieren
  • Der Channel-Name entspricht der PR-Nummer, sodass du immer weißt, welchen code du gerade nutzt

Project Manager

  • Teste ein Feature auf dem Smartphone, bevor es gemergt wird
  • Scanne den im PR geposteten code
  • Gib Feedback direkt im PR ab

Entwickler

  • Erhalte Device-Feedback, solange der PR noch offen ist
  • Jeder Push aktualisiert den PR-Channel
  • Kein Native Build für reine JavaScript-Änderungen

Test-Builds vs. Capgo PR-Channels

  • Einen PR auf ein Smartphone bringen

    TestFlight / Play Testing
    Native Build, Signing und Store-Prozess
    Capgo PR-Channel
    Web Build und Bundle Upload via CI

  • Zwischen PRs wechseln

    TestFlight / Play-Testing
    Anderen Build installieren
    Capgo PR-Channel
    Anderen QR code scannen oder Channel wechseln

  • Setup für Reviewer

    TestFlight / Play-Testing
    Tester einladen, dann jeden Build installieren
    Capgo PR-Channel
    App einmal installieren

  • Native code und Plugin-Änderungen

    TestFlight / Play-Testing
    Ja
    Capgo PR-Channel
    Nein, benötigt einen Native Build

Lösungen nach Teamtyp

Finde die Lösung, die zu deinem Team passt

Enterprise

Multi-App- und Multi-Team-Deployments

Startups

Schnell deployen ohne Overhead

Solo-Entwickler

14 Tage kostenlos testen, CLI upload

Agenturen

Mehrere Client-Apps verwalten

Mit Capacitor gebaute Apps

Produkt-Apps benötigen reviewbare Mobile-Changes

Lern-, Event- und Community-Apps können Onboarding-, Practice-, Live-Session- und Subscription-Changes gleichzeitig unter Review haben. PR Previews ermöglichen es Product, QA und Support, einen mobile-ready Build vor dem Merge zu inspizieren.

StudySmarter - Schul- &amp; Uni-App-Icon BILDUNG

StudySmarter - Schule &amp; Uni

Bildungs-App, bei der Änderungen an Lektionen, Kursen oder Abos ein Review durch Stakeholder erfordern.

Google Play-Installationen
6,5 Mio.
Store-Bewertung
4.8
App-Icon von Poll Everywhere BUSINESS

Poll Everywhere

Interaktive App, bei der Event-Flows vor dem Merge getestet werden müssen.

Google Play-Installationen
1,1 Mio.
Store-Bewertung
3.2
lichess • Free Online Chess App-Icon SPIELBRETT

lichess • Kostenloses Online-Schach

Community-App, bei der Turnier- und Analyse-Screens von Device-Previews profitieren.

Google Play-Installationen
11,3 Mio.
Store-Bewertung
4.3

Kundenstimmen

Das sagen Teams, die mit Capgo deployen

5.0/5 von Entwicklerteams bewertet 9,400+ Teams Bewertungen lesen

Nate van Jole

CTO, Privat

„Das Setup war in weniger als einem Tag erledigt. Mit Channel-basierten Rollouts kann ich erst auf meinem eigenen Gerät testen, bevor etwas bei den Production-Usern ankommt.“

Porträt von Michael Haberler

Michael Haberler

nethead emeritors

„Tolle Arbeit am Updater-Plugin. Bei mir läuft es einwandfrei, und Live Updates sind ein echter Beschleuniger für schnelle Testzyklen.“

no-tone @ Webincode

Entwickler, Webincode

„Geräte-IDs zu bestimmten Gruppen hinzuzufügen und Änderungen nur an diese Gruppen zu pushen, ist ein echter Gamechanger.“

FAQ

Häufige Fragen zu PR Previews

Klare Antworten für alle, die CI einrichten oder Pull Requests reviewen.

Benötigen Reviewer für jeden PR einen neuen Build?

Nicht, wenn der PR nur den Web-Layer ändert. Reviewer installieren die App einmal, und das JavaScript, HTML, CSS sowie die Assets jedes PRs gehen in einen eigenen Channel. Wenn der PR ein Plugin hinzufügt oder natives code ändert, ist ein Native Build nötig. Nutze einen Build-Check in der CI, um das zu erkennen.

Was einen Native Build erfordert

Kann der CI-Key unseren Production-Channel beeinflussen?

Nicht mit einem App Preview API Key. Er kann Preview-Channels erstellen, Bundles hochladen und nur den Channel sowie das Bundle löschen, das er selbst erstellt hat. Er kann den Default- oder Main-Channel nicht ändern. Führe in GitHub Actions den Job auf pull_request aus (nicht pull_request_target) und beschränke ihn auf PRs aus demselben Repository.

App Preview API Keys

Wie öffnen Reviewer die Preview?

Ein Admin aktiviert die Previews einmalig mit app set --preview. Danach druckt get-qr einen QR code für den PR-Channel aus, und --url gibt die Web-Preview-URL sowie den Deep Link aus. Poste diese einfach als PR-Kommentar.

get-qr-Referenz

Was passiert mit alten PR-Channels und Bundles?

Füge einen Job für das Event 'pull request closed' hinzu, der channel delete mit --delete-bundle und --success-if-not-found ausführt. Mit einem App Preview Key werden so der Channel und das zugehörige Bundle gelöscht. Bundles aus früheren Pushes können per Bundle Cleanup mit einem Key gelöscht werden, der entsprechende Löschrechte besitzt.

Channel CLI Referenz

Funktioniert das mit GitLab, Bitbucket oder Azure DevOps?

Ja. Die Schritte sind Capgo CLI-Befehle und laufen daher in jeder CI. In der Doku gibt es Integrations-Guides für GitHub Actions, GitLab CI, Bitbucket Pipelines und Azure DevOps.

CI/CD-Integrationen

Vorschau deines nächsten Pull Requests auf dem Handy

Füge die Upload-, QR- und Cleanup-Schritte zu deiner CI hinzu und teste sie während der kostenlosen Testphase mit deiner eigenen App.

14 Tage kostenlos testen, keine Kreditkarte nötig. Native Änderungen erfordern weiterhin einen neuen Build.