Native + OTA Kanal-Workflow

Ein häufiges Capgo-Setup verwendet einen Entwicklungs Kanal und einen Produktionskanal Kanal. CI lädt alle OTA-Bundles hoch, devdann promotet es zu production als du bereit bist. Teams fügen oft hinzu --fail-on-incompatible damit CI versehentlich keine lebende Aktualisierung versendet, die neue native code benötigt.

Dieses Dokument beantwortet die folgende Frage: Was tust du, wenn du absichtlich eine Paketversion benötigst, die mit den aktuellen native Paketen des Kanals inkompatibel ist?

Wenn du den Hintergrund über, warum Capgo native Pakete vergleicht, wissen möchtest, beginne mit Native Kompatibilität. Für eine vollständige CI-Zweig, der OTA vs Capgo Build automatisch auswählt, siehe Auto OTA oder Native.

Empfehlenswerter Kanalayout

Diese Anleitung geht davon aus, dass die dev und production Kanäle bereits existieren. Erstellen Sie sie zuerst, wenn nötig:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

Kanal	Wer bekommt es	Typischer Upload
dev	Innere / QA-Builds	Jeder CI-Push von JS (und absichtliche native Baselines)
production	Benutzer im Store	Erstellt oder hochgeladen, wenn das Release bereit ist

--fail-on-incompatible ist eine gute Voreinstellung für beide Kanäle bei Alltägliche OTA-Uploads. Es vergleicht die native Pakete im Bundle, das Sie hochladen, mit dem aktuellen Bundle auf diesem Kanal . Wenn sie sich unterscheiden, beendet der Upload mit einem Fehlercode und nichts wird verschickt.Alltägliche OTA (Flag behalten)

Abschnitt mit dem Titel “Alltägliche OTA (Flag behalten)”

Terminalfenster

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible blockt einen ungewollten nativen Abdrift. --auto-min-update-version erforderlich bei jedem Upload, sobald das Kanal das metadata Strategie (empfohlen unten). Wenn der Kanal noch nicht auf metadata ist, können Sie --auto-min-update-version bis Sie umschalten.

Optional CI-Sperre vor dem Upload:

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

Intentionaler nativer Bump (setzen Sie die Flagge einmal ab)

Sie context: Sie Definition. Seite/Area: Capgo Marketing-Website. Rolle: Langen Marketing- oder Rechtsparagraphen. Gesehen in: Seite Disclaimer.astro, Seite Rückkehr.astro. Nachrichten Schlüssel `you_definition` (Sie Definition). ein Bundle hochladen, das eine neue native code benötigt, während man --fail-on-incompatible. Diese Flag ist vorhanden, um genau diesen Fall zu blockieren. Wenn ein Plugin, die Capacitor Version oder eine andere native Abhängigkeit absichtlich geändert wird:

1. Das passende natives Binärdatei (App Store / Play Store oder Capgo Build).
2. Das passende JS-Bundle hochladen ohne --fail-on-incompatible.
3. Vorziehen --auto-min-update-version mit dem Kanal auf der metadata Strategie, damit Geräte, die noch auf der alten Binärdatei sind, das neue Bundle nicht erhalten, bis sie die neue App installieren.
4. Nach dieser Basis-Hochladung, legt man --fail-on-incompatible wieder auf normale OTA CI (und behalten Sie) --auto-min-update-version während der Kanal weiterhin auf metadata).

1. Einmalig pro Kanal: Metadaten-Zugriff aktivieren

   npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

   Wiederholen für dev Wenn das Kanal auch absichtliche native Baselines erhält. Nach diesem Wechsel müssen alle Uploads an den Kanal die Baseline enthalten. --auto-min-update-version oder --min-update-version.

2. Versenden Sie das native Binärpaket

   Bauen und übermitteln Sie die iOS/Android-Anwendung, die die neuen Plugins oder native Änderungen enthält. Bis die Benutzer das Binärdatei installieren, können sie eine Abhängigkeit nicht sicher ausführen, die auf jenen native Paketen basiert.

3. Hochladen Sie die entsprechende OTA-Basis (keine) --fail-on-incompatible)

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --auto-min-update-version

   Dies registriert die neuen native Pakete auf dem Kanal. Später bundle releaseType / --fail-on-incompatible Überprüft, dass sich an dieser Basislinie nichts geändert hat.

4. Wiederaufnahme der geschützten OTA-Uploads

   Spätere JS-only-Veröffentlichungen verwenden beide Flags erneut:

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --fail-on-incompatible \
     --auto-min-update-version

Tip

Behandeln Sie die native-Baseline-Uploads als eine dedizierte CI-Aufgabe (oder einen manuellen Release-Schritt), nicht als eine Ausnahme, die Sie in die Standard-OTA-Aufgabe einfügen. --fail-on-incompatible, und auf einem metadata es sollte auch auf dem Kanal bleiben --auto-min-update-version.

FAQ

und trotzdem einen inkompatiblen native-Bundle pushen? --fail-on-incompatible Kaninhaltsabschnitt mit Titel “FAQ”

Nein. Wenn sich die native Pakete des Uploads von den Kanal-Bundles unterscheiden, versagt der Flag auf Absicht. Für eine geplante native Erhöhung lassen Sie den Flag auf dieser einen Upload (und verwenden Sie --auto-min-update-version Wenn Sie können).

Ein einmaliger Upload ohne den Flag ist die richtige Vorgehensweise?

Ja. Das ist die unterstützte Methode, um die native Basis des Kanals nach dem Versand eines neuen Binärs voranzutreiben. Halten Sie den Flag auf jedem anderen OTA-Upload so, dass zufällige native Drift CI immer noch versagt.

Muss ich zuerst auf dev und dann auf Produktionsumgebung hochladen? dev Zuerst, dann production?

Ja, wenn das Ihrem Prozess entspricht. Führen Sie die gleichen Regeln pro Kanaldann: Die Kompatibilitätsprüfung erfolgt gegenüber dem, was auf dem Zielkanal live ist. Verschieben Sie oder laden Sie nur nach production nachdem dev gut aussieht, und verwenden Sie eine native-Baseline-Upload (kein --fail-on-incompatible) auf jedem Kanal, der die neuen native Pakete aufnehmen muss.

Was passiert, wenn ich das neue native Bundle mit der Flagge noch hochlade?

Der CI-Fehler und Capgo schicken das Upload nicht. Das ist die erwartete Ausgabe. Entweder war der Änderungszuweisung unabsichtlich (korrigieren Sie die native Pakete und versuchen Sie es erneut als OTA), oder es war absichtlich (verwenden Sie den native Weg oben).

Welche Flagge geht auf welche Aufgabe?

Weg	Wann	Upload-Flags
OTA	JS nur; native Pakete entsprechen dem Kanal	--fail-on-incompatible + --auto-min-update-version (erforderlich, wenn der Kanal auf “ metadata)
Native Basis	Neuer natives Binär + passende JS-Bundle	Nein --fail-on-incompatible; behalten --auto-min-update-version

Zugehörige

Native Kompatibilität

Wie Capgo native Paketdrift erkennt und was unkompatibel für Geräte bedeutet.

Auto OTA oder Native

Wire bundle releaseType GitHub Aktionen oder GitLab so, dass CI den richtigen Weg wählt.

Zielgruppenorientierte Versionen

context: Seite/ Bereich: Capgo-Lösungen-Marketingseite. Rolle: Abschnitt oder Seiteüberschrift. Gesehen in: Seite Lösungen/Zielgruppenorientierte Versionen.astro. Nachrichtenschlüssel `solutions_version_targeting_title` (Lösungen Zielgruppenorientierte Versionen Titel). | Seite/ Bereich: Capgo-Lösungen-Marketingseite. Rolle: Kurze Benutzeroberflächeneinheit oder Navigationselement. Gesehen in: Seite Lösungen/Zielgruppenorientierte Versionen.astro. Nachrichtenschlüssel `solutions_version_targeting` (Lösungen Zielgruppenorientierte Versionen).

CLI: bundle

__CAPGO_KEEP_0__: Paket

Referenz für Upload, Kompatibilität, releaseType und verwandte Flags.

Wenn Sie “Native + OTA-Kanal-Workflow” verwenden Native + OTA-Kanal-Workflow um Live-Updates sicher über Native-Releases hinweg zu halten, verbinden Sie es mit Native-Kompatibilität für die Paket-Vergleichsregeln Auto OTA oder Native für CI-Branching Zielgruppenermittlung context: Seite/Bereich: Capgo-Lösungen-Marketing-Seite. Rolle: Abschnitts- oder Seitenüberschrift. Gesehen in: Seite Lösungen/Zielgruppenermittlung.astro. Nachrichtenschlüssel `solutions_version_targeting_title` (Lösungen-Zielgruppenermittlung-Titel). | Seite/Bereich: Capgo-Lösungen-Marketing-Seite. Rolle: Kurzer UI-Label oder Navigationselement. Gesehen in: Seite Lösungen/Zielgruppenermittlung.astro. Nachrichtenschlüssel `solutions_version_targeting` (Lösungen-Zielgruppenermittlung) Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ Bundle-Referenzpaket