Ihr CI lädt jede Pull-Request-Webbuild in eine eigene Capgo-Kanal hoch. Die Rezensenten scannen eine QR-code-Vorschau oder wechseln in der App in 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 benötigen jedoch eine neue Build.
Menschliche Unterstützung von Martin
Das Problem
Entwickler öffnen einen PR
Die Änderung ist zum Überprüfen bereit, aber niemand kann sie noch auf einem Telefon ausprobieren.
Bauen, signieren und hochladen
Jemand baut eine native Binärdatei für die Zweig, signiert sie, lädt sie auf TestFlight oder eine Play-Test-Track hoch und wartet auf die Verarbeitung.
Einladen und installieren
Die Rezensenten müssen als Tester hinzugefügt und die genaue Version installiert werden.
Wiederholen für jeden Fix
Jeder Rezensionskommentar, der code ändert, bedeutet eine weitere Build, eine weitere Hochladung und eine weitere Installation.
Jeder Runden der Überprüfung wartet auf eine native Build, selbst wenn nur JavaScript geändert wurde.
Jedes Build
Wartet auf die Verarbeitung im Store
Jedes Build, das Sie zu TestFlight oder einer Play-Test-Track hochladen, wird vorher verarbeitet, bevor es von Testern installiert werden kann. Das passiert für jeden Build.
Jeder PR
Benötigt eine eigene native Build zum Testen.
Ohne Live-Updates können Reviewer nur nach einem Branch ausprobieren, nachdem jemand gebaut, unterschrieben und einen neuen Binär hochgeladen hat, auch für eine web-only-Änderung
Späte Rückmeldung
Die Review passiert, nachdem der Autor weitergegangen ist
Wenn die Review auf Builds wartet, kommt die Rückmeldung später, der Autor ist an einem anderen Projekt und der Branch driftet von main ab
Wie es funktioniert
Four CI steps: set up a scoped key once, upload per push, share the preview, clean up on close. Every command below is from the Capgo docs.
Ein Administrator erstellt einen App-Vorschau-Schlüssel API für CI. Dieser kann Vorschaukanäle erstellen und Bundles hochladen, kann jedoch die Standard- oder Produktionskanäle nicht ändern. Vorschauen werden einmal pro App aktiviert.
# once, run by an admin (not the preview key)
npx @capgo/cli@latest app set com.example.app --previewBei jedem Push baut CI die Web-App 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"get-qr druckt eine QR-code für den Kanal oder die Vorschau-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" \
--urlFühre diesen auf dem Pull-Request-Schließen-Ereignis aus. Mit einem App-Vorschau-Schlüssel werden nur der Kanal und der mit diesem Schlüssel erstellte Bundle gelöscht.
npx @capgo/cli@latest channel delete \
"pr-$PR_NUMBER" com.example.app \
--apikey "$CAPGO_PREVIEW_KEY" \
--delete-bundle \
--success-if-not-foundBeide benötigen einen Kanal, der Selbstzuweisung ermöglicht. Eine App-Vorschau-Schlüssel stellt das nicht her, daher teilen Sie die QR-Vorschau oder setzen Sie eine Geräteüberschreibung in der Konsole.
Aktivieren Sie das Menü zum Schütteln in internen Builds. Tester schütteln das Gerät, um das Testmenü von Capgo zu öffnen, und der Kanalwahlassistent lässt sie einen Kanal auswählen.
// capacitor.config.ts (internal builds)
CapacitorUpdater: {
shakeMenu: true,
}Fügen Sie einem Entwickler-Einstellungs-Bildschirm einen Kanalfeld hinzu und rufen Sie setChannel() mit dem PR-Kanalnamen auf.
import { CapacitorUpdater } from '@capgo/capacitor-updater'
await CapacitorUpdater.setChannel({
channel: 'pr-123',
triggerAutoUpdate: true,
})Jeder, der den Pull-Request überprüft, kann ihn auf einem Telefon überprüfen, nicht nur der Autor.
Finde die Lösung, die den Bedürfnissen deines Teams entspricht
Apps, die mit Capacitor erstellt wurden
Bei Lern-, Veranstaltungs- und Community-Apps können sich Anwender gleichzeitig auf ein Onboarding, eine Übung, eine Live-Sitzung oder eine Abonnement-Änderung vorbereiten. PR-Vorschauen ermöglichen es Produkt-, QA- und Support-Teams, einen mobilen-fertigen Build zu überprüfen, bevor er in die Produktion übernommen wird.
Bildung
Bildungsanwendung, bei der Änderungen an Lektionen, Kursen und Abonnementsmustern von Stakeholdern genehmigt werden müssen.
BUSINESS
Ein Live-Engagement-App, bei der Ereignisflüsse vor dem Merge getestet werden sollten.
SPIELBrett
Community-App, bei der Turnier- und Analyse-Screens von Geräte-Vorschauen profitieren.
Kundenbeweis
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 die Produktionsbenutzer geht.’
Netzwerkkopf-Entwickler
Großartige Arbeit am Updater-Plugin. Es funktioniert für mich fehlerfrei und Live-Updates sind ein Super-Boost für schnelle Testzyklen.
Entwickler, Webincode
“Es ist ein Leben rettender Vorteil, dass man bestimmten Geräten IDs hinzufügen und die Änderungen nur an bestimmten Gruppen durchführen kann.”
FAQ
Geradherige Antworten für diejenigen, die CI einrichten und diejenigen, die überprüfen.
Nein, 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 er eine native Build. In CI muss eine Build durchgeführt werden, um das zu erkennen.
Wat benötigt eine native BuildNicht mit einer App-Vorschau-Schlüssel API. Es kann Vorschaukanäle erstellen, Uploads von Bundeln durchführen und nur den Kanal und den Bund löschen, den es erstellt hat. Es kann jedoch nicht den Standard- oder Hauptkanal ändern. In GitHub Aktionen, führen Sie die Aufgabe auf pull_request, nicht auf pull_request_target, und beschränken Sie sie auf PRs aus demselben Repository.
App-Vorschau-Schlüssel APIEin Administrator aktiviert die Vorschau einmal mit app set --preview. Anschließend druckt get-qr einen QR-code für den PR-Kanal aus und --url gibt die Web-Vorschau-URL und die tiefe Verlinkung aus. Posten Sie sie in einem PR-Kommentar.
get-qr-ReferenzFügen Sie eine Aufgabe auf dem Ereignis 'pull request closed' hinzu, die die Aufgabe 'channel delete' mit --delete-bundle und --success-if-not-found ausführt. Mit einem App-Vorschau-Schlüssel entfernt das die Kanäle und die mit ihnen verbundenen Bundel. Bundel aus früheren Pushs können mit der Bündelreinigung entfernt werden, wobei ein Schlüssel mit Löschrechten erforderlich ist.
Kanal CLI-ReferenzJa. Die Schritte sind Capgo CLI Befehle, also laufen sie in jedem CI. Die Dokumentation enthält Integrationsanleitungen für GitHub Aktionen, GitLab CI, Bitbucket Pipelines und Azure DevOps.
CI/CD-IntegrationenFügen Sie die Upload-, QR- und Reinigungsschritte Ihrem CI hinzu und probieren Sie sie anhand Ihres eigenen Apps während der kostenlosen Testphase.
Menschliche Unterstützung von Martin
14-tägige kostenlose Testphase, keine Kreditkarte. Native Änderungen benötigen einen neuen Build.