Einmaliger Einrichtungscheckliste

Einen Setup-Erinnerung mit den Installationsanweisungen und der vollständigen Markdown-Dokumentation für diesen Plugin kopieren.

Sie haben abgeschlossen die Einrichtung. Jetzt konfigurieren Sie Capgo einmal. Nachdem Sie das getan haben, ist die tägliche Arbeit nur Hochladen → Testen → Bereitstellen.

Regel: Kanäle sind Release-Linien (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 App-Einstellungen:
- Solo-App → production
- Team → development
Produktionskanal: Öffentlich an, Gerät selbstsetzen aus, Updates unter Native an, Auto-Update-Schutz an major.
Testkanal (development / stagingÖffentlich: ausgeschaltet, Gerät selbstgesetzt für QA.
Hochladen von 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 Upload from CI. Überprüfen Sie es vor dem Hochladen. SemVer-Tester bevor Sie es hochladen.
Deploy in die Produktion nur nach Testen, von der dashboard oder CLI.
einmal einladen, mit den geringsten Rechten, Einladung einmal, geringste Berechtigungen. 2FA für die Organisation, ein API-Schlüssel im CI.

Validate it in the 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 auf dev, deploy auf prod.

NativversionenHinzufügen von Kanälen nur wenn nötig, z.B. production-9.0 + test-9.0Halten Sie Store-Benutzer auf dem Hauptproduktionskanal.

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

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

Bundle-Name vs Kommentar

Bundle-Namen sind erforderlich zu beachten semantische Versionsnummer.Capgo verwendet semver für Kompatibilitätsprüfungen, Kanal-Update-Regeln und Rollover. Überprüfen Sie jeden Namen in der SemVer-Tester vor dem Hochladen.

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

Verwende semver Vorabversion Etiketten (der Teil nach -) wenn Sie viele Builds unter dem gleichen MAJOR.MINOR.PATCH. Zum Beispiel behalten Sie 1.8.0 und fügen Sie das Datum oder den Buildzähler in der Vorabversion ein: 1.8.0-20260629.1, 1.8.0-beta.2. Erfinden Sie keine eigenen Formate wie fix-login-bug oder 2.5.2026062306Sie sind keine gültigen semver und Uploads werden fehlschlagen oder unvorhersehbar verhalten.

Setze Release-Notizen ein --commentnicht im Bundle-Namen.

Siehe auch , nicht in der Bundle-Name ein. And Bundleversionierung.

Deltahochladen

--delta uploads Deltadateien Somit laden Geräte nur geänderte Dateien und nicht das gesamte Bundle. Der Prüfsummenwert wird immer automatisch berechnet. Sie müssen keine Prüfsummenflagge übergeben.

Standard: `--delta` (Deltadateien + Zip-Sicherung)

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 die Delta-Dateien und bewahrt die vollständige Zip als Sicherungskopie. Geräte mit einer alten Plugin-Version ohne Delta-Unterstützung verwenden die Zip. Gut, wenn der Speicherplatz nicht Ihr Hauptanliegen ist.

Speicherplatzersparnis: `--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 --delta-only wenn Sie möchten, dass Sie den __CAPGO_KEEP_0__-Speicherplatz reduzieren Sie den Capgo SpeicherplatzNur die Delta-Dateien werden gespeichert, nicht die vollständige Zip. Wählen Sie diese für große Apps oder hohe Upload-Volumina aus, bei denen sich der Speicherplatz addiert.

Trade-off: without the zip backup on the server, you rely fully on delta files, and devices on an old plugin version without Delta support cannot update. Skip --delta-only solange Sie die Speicherungserlasse nicht benötigen.

Keine zusätzliche Plugin-Konfiguration ist auf dem Gerät erforderlich. Der Updater liest die Liste der Delta-Dateien und lädt nur geänderte Dateien her.

Taglicher Workflow

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

Gemeinsame Fehler

Fehler	Lösung
Erwarten Sie OTA vor einer neuen Ladenveröffentlichung	Neubau und Versand des nativen Apps nach Hinzufügen des Plugins
Hochladen eines Bundles, aber nicht bereitstellen in einem Kanal	Zuweisen des Bundles zu einem Kanal (z.B. `production`)
Kanal pro Feature, Ticket oder Entwickler	Verwenden Sie nur dauerhafte Releasebahnen
Dynamische CI-Kanalnamen	Festgelegte Namen: `development`, `production`
Zu viele Kanäle für eine einfache App	Mit 1-2 Kanälen beginnen
Gerät selbst auf Produktionsumgebung eingestellt	Aus für Produktionskanäle, an für Testkanäle
Überspringen `--delta`	Hinzufügen `--delta` Zu Uploads; verwenden Sie `--delta-only` nur wenn Sie Speicherplatz sparen müssen
Keine semver-basierten Paketnamen	Folgen semantische Versionsnummerierung und überprüfen SemVer-Tester validieren
Versionierungsschema ändern	Halten Sie sich an semver; verwenden Sie Vorabversionen für zusätzliche Builds (`1.8.0-20260629.1`)
Metadaten / Vorschau aktiviert ohne Grund	Standardmäßig ausgeschaltet lassen

Mehr erfahren

Channels Standards, Vorrang und Routen.

Delta-Updates Warum und wie Sie --delta verwenden.

CI/CD Automatisieren Sie das Hochladen und Bereitstellen.

Bundle Prüfsumme, Abhängigkeiten und Metadaten.

Einmaliger Einrichtungscheckliste