Einmaliger Setup-Checkliste

Eine Einrichtungsvorschlag mit den Installationsanweisungen und der vollständigen Markdown-Dokumentation für diesen Plugin kopieren

Sie haben abgeschlossen onboarding. Jetzt konfigurieren Sie Capgo einmal. Nachdem Sie das getan haben, ist die tägliche Arbeit nur Upload → Test → Deploy.

Regel: Kanäle sind Release-Pfade (development, production), nicht Tickets, Funktionen oder Entwicklernamen.

Einmaliger Einrichtungscheckliste

Kanäle erstellen: Wählen Sie die kleinstmögliche Menge, die passt (siehe unten).
Standard-Upload-Kanal setzen in Anwendungs-Einstellungen:
- Einzige Anwendung → production
- Team → development
Produktionskanal: öffentlich an, Gerät selbst auf Storno, Blockiere Updates unter native an, Auto-Update-Schutz an major.
Testkanal (development / staging): öffentlich aus, Gerät selbst auf Storno für QA.
Upload aus CI mit --delta (Prüfsumme und native Abhängigkeiten sind automatisch):
Terminalfenster
```
npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta
```
Der --bundle Wert muss gültig sein semantische VersionsverwaltungÜberprüfen Sie es in der SemVer-Tester bevor Sie es hochladen.
Erstellen Sie eine Produktion nur nachdem Sie getestet haben, von der Oberfläche oder CLI.
Team & Sicherheit: einladen Sie einmal, mit den geringsten Rechten 2FA für die Organisation, eine API-Schlüssel in CI.

Verschlüsselung, min_update_version, Metadaten und Vorschau aus es sei denn, Sie haben einen klaren Grund.

Wählen Sie Ihre Größe

Einfach: 1 App, 1 Kanal: production

Team: development + productionUpload in Dev, deploy in Prod.

Nativversionen: Fügen Sie Kanäle nur dann hinzu, wenn nötig, z.B. production-9.0 + test-9.0. Halten Sie Store-Benutzer auf der Hauptproduktionskanal.

Viele Apps: dasselbe einfache Modell pro App (in der Regel eines) production jedes. Erstellen Sie keine zusätzlichen Kanäle nur weil das Unternehmen groß ist.

Release-Train (optional): staging → rc → production. Das gleiche Template auf jeder App, die es benötigt.

Bündelname vs Kommentar

Paketnamen sind erforderlich um semantische Versionsierung zu folgen Semantic VersioningCapgo verwendet semver für Kompatibilitätsprüfungen, Kanal-Update-Regeln und Rollover. Capgo überprüft alle Namen mit dem SemVer-Tester vor dem Hochladen.

Name = semver aus CI, z.B. 1.8.0, 1.8.0-beta.1oder 1.8.0-20260629.42
Kommentar = freitext für Menschen → commit abc1234 run 28059070270

Verwenden Sie semver Vorabversion Beschriftungen (der Teil nach -) wenn Sie viele Builds unter dem gleichen MAJOR.MINOR.PATCHVerwenden Sie zum Beispiel 1.8.0 und fügen Sie das Datum oder die Buildnummer in der Vorabversion ein: 1.8.0-20260629.1, 1.8.0-beta.2Verwenden Sie nicht eigene Formate wie fix-login-bug oder 2.5.2026062306Verwenden Sie stattdessen

Fügen Sie die Release-Notes in --commentund nicht in der Bundle-Name.

Siehe auch Zielgruppenspezifische Version und Bundle-Versionierung.

Deltaload

--delta eine hochladen Manifest so laden Geräte nur die geänderten Dateien und nicht das gesamte Bundle herunter. Der Prüfsummenwert wird immer automatisch berechnet. Sie übergeben keine Prüfsummenflagge.

Standard: `--delta` (Manifest + Zip-Backup)

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --delta

Dies ist die empfohlene Standard-Einstellung für die meisten Apps. Capgo speichert das Manifest und erhält den vollständigen Zip als Sicherungskopie. Gut, wenn der Speicherplatz nicht Ihr Hauptanliegen ist.

Speicherplatz einsparen: `--delta-only`

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta-only

Verwenden Sie --delta-only wenn Sie möchten, dass Sie __CAPGO_KEEP_0__ Speicherplatz reduce Capgo storagewenn Sie möchten, dass Sie __CAPGO_KEEP_0__ Speicherplatz reduzieren.

Kompromiss: Ohne den Zip-Backup auf dem Server hängt ihr voll auf dem Manifest-Pfad. Überspringen --delta-only es sei denn, ihr benötigt tatsächlich die Speichereinsparung.

Keine zusätzliche Plugin-Konfiguration ist auf dem Gerät erforderlich. Der Updater liest das Manifest und lädt nur geänderte Dateien herunter.

Taglicher Workflow

Upload to development (--delta)
  → test
  → deploy to production
  → don't touch channel settings again

Häufige Fehler

Fehler	Lösung
Voraussetzung, dass OTA vor einer neuen Store-Veröffentlichung verfügbar ist	Neubau und Versand des nativen Apps nach Hinzufügen des Plugins
Hochladen eines Bundles, aber nicht bereitstellen in einem Kanal	Zuweisen des Bundles an einen Kanal (z.B. `production`)
Kanal pro Feature, Ticket oder Entwickler	Verwenden Sie nur dauerhafte Release-Wege
Dynamische CI-Kanalnamen	Feste Namen: `development`, `production`
Zu viele Kanäle für eine einfache App	Mit 1-2 Kanälen beginnen
Gerät selbst auf Produktionsmodus gesetzt	Aus für Produktionskanäle, an für Testkanäle
Überspringen `--delta`	Hinzufügen `--delta` zu Uploads; verwenden `--delta-only` nur wenn Sie Speicherplatz sparen müssen
Nicht-semver-Kanalnamen	Folgen der semantischen Versionsnummerierung und in der SemVer-Tester
Änderung der Versionsierung über die Zeit	Behalte SemVer bei; verwende Vorabversionen für zusätzliche Builds (`1.8.0-20260629.1`)
Metadaten / Vorschau aktiviert ohne Grund	Standardmäßig ausgeschaltet

Erkundige dich weiter

Kanäle Standardeinstellungen, Vorrang und Routen.

Deltahinweise Wozu und wie man --delta verwendet.

CI/CD Auf Uploads und Deployments automatisieren.

Bündel Prüfsumme, Abhängigkeiten und Metadaten.