Zum Hauptinhalt springen
PR-Vorschau

Überprüfen Sie jeden Pull-Request auf einem echten Telefon

Ihr CI lädt jede Pull-Request-Webbuild in einen eigenen Capgo Kanal hoch. Die Rezensenten scannen einen QR-code-Code oder wechseln in der App den Kanal, um es auf ihrem Gerät auszuprobieren, und der Kanal wird gelöscht, wenn der PR geschlossen wird. Änderungen an nativen code-Komponenten erfordern einen neuen Build.

  • Eine Kanal pro Pull-Request
  • QR code Vorschau
  • Säubern, wenn der Pull-Request geschlossen wird

Das Problem

Ein Web-Änderung sollte nicht eine neue Binärdatei zum Review benötigen

Ein Pull-Request mit Ladenstore-Testbuilds überprüfen

  1. Entwickler öffnen einen Pull-Request

    Die Änderung ist für das Review bereit, aber niemand kann sie noch auf einem Telefon ausprobieren

  2. Bauen, signieren und hochladen

    Jemand baut eine native Binärdatei für den Zweig, signiert sie, lädt sie auf TestFlight oder einen Play-Test-Track hoch und wartet auf die Verarbeitung

  3. Einladen und installieren

    Zu den Reviewern müssen Testern hinzugefügt und jenes genaue Build installiert werden.

  4. Wiederholen Sie das für jeden Fix

    Jeder Review-Kommentar, der code ändert, bedeutet ein weiteres Build, ein weiteres Hochladen und ein weiteres Installieren.

Jeder Rundgang der Review wartet auf ein natives Build, selbst wenn nur JavaScript geändert wurde.

Was das Team kostet

Jedes Build

Wartet auf den Store-Processing

Jedes Build, das Sie auf TestFlight oder einem Play-Test-Track hochladen, wird vorher verarbeitet, bevor Tester es installieren können. Das passiert für jedes Build.

Jeder PR

Needs its own native build to test

Ohne Live-Updates können Reviewer nur eine Zweig nach dem anderen ausprobieren, nachdem jemand ein neues Binär gebaut, unterschrieben und hochgeladen hat, selbst für eine web-only-Änderung.

Spätzeitrückmeldung

Überprüfung erfolgt nachdem der Autor weitergemacht ist

Wenn die Überprüfung auf Builds wartet, gelangt die Rückmeldung später, der Autor ist an einem anderen Projekt, und der Zweig driftet vom Hauptzweig ab

Wie es funktioniert

Wie Teams Pull-Requests mit Capgo vorhersehen

Vier CI-Schritte: Einmalig eine skalierte Schlüssel einrichten, pro Push hochladen, den Vorschau-Link teilen, bei Schließen aufreinigen. Jeder Befehl unten stammt aus den Capgo-Dokumentationen

  1. Einen App-Vorschau-Schlüssel erstellen und Vorschauen aktivieren

    An admin creates an App Preview API key for CI. It can create preview channels and upload bundles, but it cannot change your default or production channel. Previews are turned on once per app.

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

  2. Hochladen des PR-Baus in seinen eigenen Kanal

    Bei jedem Push baut CI die Webanwendung und lädt sie mit einer eindeutigen Bundle-Version hoch. bundle upload --channel erstellt den pr-<number>-Kanal, wenn dieser nicht existiert, und verknüpft den Bundle mit ihm

    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"
    Vorschau von Pull-Requests im Kanäldokumentationen

  3. Poste die Voransicht auf dem PR

    get-qr druckt eine QR code für den Kanal oder die Voransicht-URLs mit --url, damit CI sie in einem PR-Kommentar hinzufügen kann.

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

  4. Lösche den Kanal, wenn der PR geschlossen wird

    Führe diesen auf dem Pull-Request-Geschlossenevent aus. Mit einem App-Voransichtsschlüssel entfernt es nur den Kanal und den mit diesem Schlüssel erstellten verbundenen Bundle.

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

Zusätzliche Wege, auf denen Reviewer auf einen PR-Kanal wechseln

Beide benötigen einen Kanal, der Selbstzuweisung ermöglicht. Ein App-Vorschausschlüssel stellt das nicht her, daher können Sie mit diesem Schlüssel entweder das QR-Vorschau-Code oder eine Geräteüberschreibung im Konsole einrichten.

Menü-Shake

Schalten Sie das Shake-Menü in internen Builds ein. Testen Sie, indem Sie das Gerät schütteln, um Capgo's Testmenü zu öffnen, und der Shake-Kanal-Selektor ermöglicht es den Testern, einen Kanal auszuwählen.

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

Zuweisungs-Menü

Fügen Sie ein Kanalfeld zu einer Entwickler-Einstellungsseite hinzu und rufen Sie setChannel() mit dem PR-Kanal-Namen auf.

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

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

Wer PR-Vorschauen verwendet

Jeder, der den Pull-Request überprüft, kann ihn auf einem Telefon überprüfen, nicht nur der Autor.

QA-Engineer

  • Testen Sie die PR-Web-Ausgabe auf Ihrem eigenen Gerät
  • Zwischen den PR-Kanälen wechseln, ohne die App neu zu installieren
  • Die Kanalbezeichnung entspricht der PR-Nummer, daher wissen Sie, welches code Sie ausführen

Projektmanager

  • Try a feature on a phone before it merges
  • Den QR-Code code auf der PR scannen
  • Feedback auf der PR selbst hinterlassen

Entwickler

  • Während der PR noch offen ist, Gerätefeedback erhalten
  • Jeder Push aktualisiert den PR-Kanal
  • Keine native Ausführung für JavaScript-Änderungen

Testen Sie Builds im Store gegen Capgo PR-Kanäle

  • Ein PR auf ein Smartphone bringen

    TestFlight/Play-Testen
    Native Build, Signierung und Store-Verarbeitung
    Capgo PR-Kanal
    Web-Build und Bundle-Upload aus CI

  • Zwischen PRs wechseln

    TestFlight/Play-Testen
    Ein anderes Build installieren
    Capgo PR-Kanal
    Ein anderes QR-Code code oder den Kanal wechseln

  • Reviewer-Einrichtung

    Testflug / Play-Testen
    Zunächst Einladung für Tester, dann jede Build installieren
    Capgo PR-Kanal
    Die App einmal installieren

  • Nativ code und Plugin-Änderungen

    Testflug / Play-Testen
    Ja
    Capgo PR-Kanal
    Nein, benötigt eine native Build

Lösungen nach Teamart

Finden Sie die Lösung, die den Bedürfnissen Ihres Teams entspricht

Unternehmen

Multi-app, multi-team Bereitstellungen

Startups

Shippen schnell ohne Überlastung

Solo-Entwickler

14-tägige kostenlose Testversion, CLI hochladen

Agenzien

Verwalten Sie mehrere Kunden-Apps

Apps, die mit Capacitor erstellt wurden

Produkt-Apps benötigen überprüfbare mobile Änderungen

Bei Lern-, Veranstaltungs- und Community-Apps können sich Anwender, Praktika, Live-Sessions und Abonnements gleichzeitig im Review-Prozess befinden. PR-Vorschauen ermöglichen es Produkt-, QA- und Support-Teams, eine mobilen-fertige Version zu überprüfen, bevor sie in die Mergin integriert werden.

StudySmarter - Schule &amp; Uni-App-Icon Bildung

StudySmarter - Schule &amp; Uni

Bildungsanwendung, bei der Lern-, Kurs- und Abonnementänderungen der Zustimmung von Stakeholdern bedürfen.

Google Play-Installationen
6,5 Mio.
Benennung des Geschäfts
4.8
Poll Everywhere App-Icon BUSINESS

Poll Everywhere App-Icon

App für Live-Engagement, bei dem Ereignisflüsse vor dem Merge getestet werden sollten.

Google Play-Installationen
1,1M
Store-Bewertung
3.2
lichess • Kostenlose Online-Schach-App SPIELBrett

lichess • Kostenlose Online-Schach

Die Turnier- und Analyse-Seiten profitieren von Gerätevoransichten in dieser Community-App.

Google Play-Installationen
11,3M
Store-Bewertung
4.3

Kundenbeweis

Was Teams mit Capgo sagen

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

Nate van Jole

CTO, Privat

‚Die Einrichtung dauerte weniger als einen Tag. Channel-basierte Rollouts ermöglichen es mir, auf meinem eigenen Gerät zu testen, bevor etwas an Produktionsbenutzer geht.&rdquo;

Portrait von Michael Haberler

Michael Haberler

Netzwerkkopf-Entwickler

Großartige Arbeit am Updater-Plugin. Es funktioniert für mich fehlerlos und Live-Updates sind ein Super-Boost für schnelle Testzyklen.

keine Tonart @ Webincode

Entwickler, Webincode

&ldquo;Es ist ein Leben rettender Vorteil, dass man Geräte-IDs zu bestimmten Gruppen hinzufügen und die Änderungen nur an bestimmten Gruppen durchführen kann.&rdquo;

FAQ

Frägt sich die Teams über PR-Vorschauen

Geradlinige Antworten für diejenigen, die CI einrichten und diejenigen, die überprüfen.

Brauchen Reviewer eine neue Build für jeden PR?

Nicht, wenn der PR nur die Web-Schicht ändert. Die Reviewer installieren die App einmal, und jeder PRs JavaScript, HTML, CSS und Assets gehen in ihren eigenen Kanal. Wenn der PR ein Plugin hinzufügt oder die native code ändert, benötigt es eine native Build. Durchführen Sie eine Build in CI, um das zu erkennen.

Was benötigt eine native Build

Kann der CI-Schlüssel unsere Produktionskanal berühren?

Not with an App Preview API key. It can create preview channels, upload bundles, and delete only the channel and bundle it created. It cannot change the default or main channel. In GitHub Actions, run the job on pull_request, not pull_request_target, and limit it to PRs from the same repository.

App Preview API keys

Wie öffnen die Rezensenten den Vorschau?

An admin enables previews once with app set --preview. After that, get-qr prints a QR code for the PR channel, and --url prints the web preview URL and deep link. Post them in a PR comment.

get-qr-Referenz

Was passiert mit alten PR-Kanälen und -Paketen?

Fügen Sie eine Aufgabe auf dem Pull-Request-Beendigungsevent hinzu, die die channel delete mit --delete-bundle und --success-if-not-found ausführt. Mit einem App-Vorschau-Schlüssel entfernt das die Kanal und das Paket, das mit ihm verknüpft ist. Pakete aus früheren Pushs können mit der bundle cleanup entfernt werden, mit einem Schlüssel, der Löschrechte hat.

channel CLI reference

Funktioniert das mit GitLab, Bitbucket oder Azure DevOps?

Ja. Die Schritte sind Capgo CLI Befehle, also laufen sie in jedem CI. Die Dokumentation hat Integrationshandbücher für GitHub Actions, GitLab CI, Bitbucket Pipelines und Azure DevOps.

CI/CD-Integrationen

Vorschau auf Ihren nächsten Pull-Request auf einem Smartphone

Fügen Sie die Upload-, QR- und Reinigungsschritte in Ihre CI ein und testen Sie sie auf Ihrem eigenen App während der kostenlosen Testphase.

14-tägige kostenlose Testphase, keine Kreditkarte. Änderungen an der Native-App benötigen einen neuen Build.