Einmaliger Einrichtungskalender

Eine Setup-Anweisung mit den Installations-Schritten 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 Hochladen → Testen → Bereitstellen.

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

Einmaliger Einrichtungscheckliste

Kanäle erstellen: Wählen Sie die kleinstmögliche Menge, die passt (siehe unten).Fehlersuche
Standardmäßige Upload-Kanal setzen in Anwendungs-Einstellungen:
- Solo-Anwendung → production
- Team → development
Produktionskanal: Öffentlich auf, Gerät selbstsetzen aus, Updates unter Native auf blockieren, Auto-Update-Wächter auf major.
Testkanal: öffentlich aus, Gerät selbstsetzen für QA an (development / stagingVon CI hochladen
mit (Prüfsumme und native Abhängigkeiten sind automatisch): --delta (checksum and native dependencies are automatic):
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
```
Die --bundle Wert muss gültig sein Semantic Versionierung. Überprüfen Sie es im SemVer-Tester bevor Sie es hochladen.
Erst nach Testen in die Produktion deployen. nur nach Testen Dashboard oder CLI.
Team & Sicherheit: Einladen, so wenig Rechte wie möglich. Zwei-Faktor-Authentifizierung für die Organisation, ein API-Schlüssel in der CI.

Verschlüsselung, min_update_versionMetadaten, Vorschau Aus nur wenn Sie einen klaren Grund haben.

Wählen Sie Ihre Größe

Einfach: 1 App, 1 Kanal: production

Team: development + production. Hochladen auf dev, deployen auf prod.

Native Versionen: Hinzufügen von Kanälen nur wenn nötig, z.B. production-9.0 + test-9.0. Behalten Sie die Store-Benutzer auf dem Hauptproduktionskanal.

Viele Apps: gleiche einfache Modell pro App (in der Regel eines production . Erstellen Sie keine extra Kanäle nur weil das Unternehmen groß ist.

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

Bundle-Name vs Kommentar

Bundle-Namen sind erforderlich um zu folgen semantische Versionsnummerierung. Capgo verwendet semver für Kompatibilitätsprüfungen, Kanal-Automatik-Update-Regeln und Rollbacks. Überprüfen Sie jeden Namen in der SemVer-Tester vor dem Upload.

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

Verwende semver Vorabversion Labels (der Teil nach -) wenn Sie viele Builds unter dem gleichen MAJOR.MINOR.PATCHBeispiel, behalten Sie 1.8.0 und fügen Sie das Datum oder den Buildzähler in der Vorabversion hinzu: 1.8.0-20260629.1, 1.8.0-beta.2. Erstellen Sie keine eigenen Formate wie " oder ". Sie sind keine gültigen Semver und Uploads werden fehlschlagen oder unvorhersehbar verhalten. fix-login-bug Legen Sie die Release Notes in 2.5.2026062306, nicht im Bundle-Namen.

Siehe auch --commentVersion-Ziel

und Bundle-Versionierung Delta-Upload Abschnitt mit dem Titel „Delta-Upload“.

hochlädt ein

--delta Put release notes in __CAPGO_KEEP_0__ , not in the bundle name. manifest so devices download nur geänderte Dateien anstatt der vollständigen Bundle jede Zeit. Die Prüfsumme wird immer automatisch berechnet. Sie übergeben keine Prüfsummenflagge.

Standard: `--delta` Abschnitt mit dem Titel „Standard: --delta (manifest + zip backup)“

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

This is the recommended default for most apps. Capgo stores the manifest behält das vollständige Zip als Sicherungskopie bei. Gut, wenn der Speicherplatz nicht Ihr Hauptanliegen ist. Speicher sparen:

Abschnitt mit dem Titel „Speicher sparen: --delta-only“ `--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 die Capgo-Speicherung reduzierenSpeichern Sie nur die Delta- und Manifestdateien, nicht den gesamten Zip-Ordner. Wählen Sie diese Option für große Apps oder hohe Upload-Volumina, bei denen sich der Speicher aufsummiert.

Gegenleistung: Ohne den Zip-Backup auf dem Server müssen Sie sich vollständig auf die Manifest-Pfad abstützen. Auslassen --delta-only es sei denn, Sie benötigen tatsächlich die Speichereinsparungen.

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

Tägliche Arbeitsablauf

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

Häufige Fehler

Fehler	Lösung
Wartete auf OTA vor einer neuen Ladenveröffentlichung	Rebuild und versenden Sie die native App nach dem Hinzufügen des Plugins
Ein Bundle hochladen, aber nicht in einen Kanal deployen	Ein Bundle einem Kanal zuweisen (z.B. `production`)
Ein Kanal pro Feature, Ticket oder Entwickler	Nur permanente Release-Wege verwenden
Dynamische CI-Kanalnamen	Feste Namen: `development`, `production`
Zu viele Kanäle für eine einfache App	Mit 1-2 Kanälen beginnen
Geräte selbst auf Produktionsumgebung einstellen	Aus für Produktionskanäle, an für Testkanäle
Überspringen `--delta`	Hinzufügen `--delta` zum Hochladen; verwenden Sie `--delta-only` nur dann, wenn Sie Speicherplatz sparen müssen
Nicht-semver-Paketnamen	Folgen Sie der semantischen Versionsnummerierung und überprüfen Sie in der SemVer-Tester
Ändern Sie die Versionsnummerierung im Laufe der Zeit nicht	Halten Sie semver; verwenden Sie Vorabversionen für zusätzliche Builds (`1.8.0-20260629.1`)
Metadaten / Vorschau aktivieren ohne Grund	Lassen Sie es standardmäßig aus

Mehr erfahren

Kanäle Standardeinstellungen, Vorrang und Routing.

Delta-Updates Warum und wie man --delta verwendet.

CI/CD Automatischer Upload und Deploy.

Bundles Prüfsumme, Abhängigkeiten und Metadaten.