Erstellen Sie für jeden Pull Request eine dedizierte Capgo-Kanal. Teilen Sie einen Link mit Ihrem Team und sie können die genauen Änderungen auf ihrem Gerät testen - keine App-Wiederinstallation, keine TestFlight, keine Wartezeit.
Menschliche Unterstützung von Martin
Entwickler öffnet Pull Request
Code ist bereit für die Überprüfung. Doch bevor jemand es testen kann, muss es erst gebaut und auf TestFlight hochgeladen werden.
Bauen und Hochladen
Das App-Image lokal oder in CI bauen. Archivieren. Auf App Store Connect hochladen. Warten auf die Verarbeitung. 15-30 Minuten Mindestzeit.
Verteilen an Tester
Testern, die noch nicht in TestFlight sind, hinzufügen. Einladungen senden. Warten, bis sie akzeptieren. Erklären, wie man es installiert.
Testen des falschen Builds
Testern laden das Build herunter. Dev pusht eine Korrektur. Jetzt müssen alle Schritte 2-3 wiederholen, um das aktualisierte Build zu erhalten.
Gesamte Zeit, um einen Pull Request zu testen: 45-60 Minuten. Pro Pull Request. Pro Tester. Für jede Aktualisierung.
15-30 Minuten
TestFlight-Verarbeitungszeit
Jedes aufgeladene Build muss von Apple verarbeitet werden, bevor Tester darauf zugreifen können. Dies geschieht pro Build, jede Zeit.
67%
Von QA-Zeit, die auf Warten ausgelegt ist
QA-Engineeure berichten, dass sie 67% ihrer Zeit damit verbringen, auf Builds zu warten, anstatt tatsächlich zu testen. Das sind 5+ Stunden pro Tag verlorener Produktivität.
340 €/PR
Versteckter Kostenbeitrag pro Pull-Request
Wenn man die Wartezeit der Entwickler, die QA-Blockzeit und die verzögerte Rückmeldung berücksichtigt, kostet jeder PR durchschnittlich 340 € an verlorener Produktivität.
Erstelle für jeden PR einen Capgo-Kanal. Tester wechseln die Kanäle in Sekunden. Keine App-Wiederinstallierung. Keine Wartezeit.
CI baut die App automatisch und erstellt einen Capgo-Kanal mit dem Namen des PR-Nummern.
Automatisch
Die gebaute Bundle wird im Hintergrund auf Capgo hochgeladen. Keine Verarbeitungsverzögerung.
< 30 Sekunden
Der Tester öffnet die App, wechselt zum PR-Kanal und erhält das Build sofort.
< 10 Sekunden
QA-Tests auf einem realen Gerät. Dev pusht Fixes. Der Tester erhält Updates sofort. Keine Neininstallation erforderlich.
Instant Iteration
name: PR Preview
on:
pull_request:
types: [opened, synchronize]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Setup & Build
run: |
npm ci
npm run build
# Create a channel named after your PR
- name: Create PR Channel
run: npx @capgo/cli channel add pr-$${{ github.event.pull_request.number }}
# Upload the build to that channel
- name: Upload to Capgo
run: npx @capgo/cli bundle upload --channel pr-$${{ github.event.pull_request.number }}
# Post a comment with the test link
- name: Comment on PR
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 }}`'
})Die Einrichtung dauert 5 Minuten. Kopieren Sie diese Workflow und passen Sie ihn an Ihre CI an.
Die integrierte Erschütterungsgeste ermöglicht die Aktivierung. Tester erschüttern ihr Gerät, um ein Menü zu öffnen, das alle verfügbaren Kanäle anzeigt.
// capacitor.config.ts
CapacitorUpdater: {
shakeMenu: true // Enable for testing
}Erstellen Sie eine benutzerdefinierte Benutzeroberfläche für das Wechseln von Kanälen. Perfekt für eine Einstellungsseite in Ihrer App.
// Switch channel from your app
import { CapacitorUpdater } from '@capgo/capacitor-updater'
await CapacitorUpdater.setChannel({
channel: 'pr-123'
})TechFlow
B2B-Software-as-a-Service - Team-Kollaborations-App
The real pain came during crunch weeks. When multiple PRs needed testing simultaneously, QA had to constantly reinstall different TestFlight builds. Testers got confused about which version they were running. Bugs got reported on already-fixed code.
Der echte Schmerz kam während der Crunch-Wochen. Wenn mehrere Pull Requests gleichzeitig getestet werden mussten, musste QA ständig verschiedene TestFlight-Builds neu installieren. Die Tester waren verwirrt darüber, welcher Version sie liefen. Fehler wurden auf bereits behobene Capgo gemeldet.
Unsere QA-Team war von ständiger Frustration zu echter Zufriedenheit übergegangen. Sie genießen jetzt sogar das Testen, weil sie nicht mehr warten müssen. Wir liefern doppelt so viele Features pro Sprint.
— Lisa Wong, Engineering Manager bei TechFlow
PR Preview verändert die Art und Weise, wie Ihr gesamtes Team an der mobilen Entwicklung zusammenarbeitet.
TestFlight / Beta
Capgo Vorabansicht
Finden Sie die Lösung, die Ihren Teams Bedürfnissen entspricht
Apps, die mit Capacitor erstellt wurden
Bei Lern-, Veranstaltungs- und Community-Apps können gleichzeitig Überprüfungen von Einstellungen, Übungen, Live-Sessions und Abonnements durchgeführt werden. Die Preview-Funktion für Pull Requests ermöglicht es Produkt-, QA- und Support-Teams, einen mobilen-fertigen Build zu überprüfen, bevor er in die Hauptquelle integriert wird.
BILDUNG
Eine Bildung-App, bei der Lektion, Kurs- und Abonnement-Änderungen von Stakeholdern überprüft werden müssen.
BUSINESS
Live-Engagement-App, bei der sich Ereignisflüsse vor dem Merge testen sollten.
BUSINESS
Community-Anwendung, bei der Turnier- und Analyse-Screens von Vorlesegeräten profitieren.
Ihrem QA-Team steht mehr als nur das Anzeigen von Fortschrittsbalken zur Verfügung. Geben Sie ihnen Zugriff auf jeden Pull Request.
Ihr Team verdient es, besser als nur Fortschrittsbalken zu sehen. Geben Sie ihnen Zugriff auf jeden Pull Request.
Dokumentation ansehen