Kanäle

Ein Live-Update-Kanal verweist auf eine bestimmte JS-Bundle-Build Ihres Apps, die mit allen Geräten konfiguriert ist, um auf Updates zu hören. Wenn Sie den Capgo Live-Updates SDK installieren, überprüfen alle native Binärdateien, die auf diesen Kanal konfiguriert sind, bei jedem App-Start nach verfügbaren Updates. Sie können die Build, auf die ein Kanal verweist, jederzeit ändern und auch auf vorherige Builds zurückrollen, wenn erforderlich.

Kanäle bieten keine Vertraulichkeit bereit.

Kanäle bestimmen die Berechtigung für Updates, nicht die Geheimhaltung von Paketen. Selbst wenn ein Kanal privat ist oder die Selbstzuweisung deaktiviert ist, sollte ein unverschlüsselter Paketupload an Capgo immer noch als öffentliches Asset behandelt werden, das an Clients geliefert wird. Die Verschlüsselung schützt den Transportweg und die Authentizität von Updates, aber verschickte Pakete können immer noch mit genügend Anstrengung rückgängig gemacht werden, weil der öffentliche Schlüssel Teil des Clients ist. Siehe Live-Update-Verschlüsselung für weitere Informationen.

Wie ein Gerät einen Kanal auswählt (Priorität)

Wenn ein Gerät nach einem Update sucht, entscheidet Capgo, welcher Kanal in dieser strengen Reihenfolge (höchste Priorität zuerst) verwendet wird:

1. Zwangslauf der Gerätemap (Dashboard) – Manually pin a specific device ID to a channel. Use for urgent debugging or controlled testing with a single real user. This always wins. Capgo removes the mapping 90 days after the last override write. See API entfernt die Zuweisung 90 Tage nach dem letzten Überprüfungs-Schreiben. Siehe .
2. Console und API-Überprüfungen verfallen nach 90 Tagen Cloud-Überprüfung (pro Gerät) via Dashboard oder API
3. Plugin setChannel() lokale Kanal – Erstellt, wenn die App setChannel() und der Backend überprüft, dass der Zielkanal die Selbstzuweisung zulässt. Der ausgewählte Kanal wird lokal auf dem Gerät gespeichert, wirkt sofort und wird nicht im Geräte-Überschreibungs-UI angezeigt.

Instantanerweiterung des Kanals mit setChannel()

Ab der Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion), setChannel() fungiert anders: es kontaktiert den Backend, um zu überprüfen dass der Kanal zugelassen ist (Überprüfung, ob die Selbstzuweisung für diesen Kanal aktiviert ist), dann speichert den Kanal lokal auf dem Gerät als defaultChannel. Dies bedeutet, dass der neue Kanal sofort wirksam wird schnell für die nächste Aktualisierungskontrolle—keine Wartezeit für die Replikation.

Zuvor setChannel() speicherte man den Kanal-Übertrag in der Backend-Datenbank (wie Dashboard oder API-Änderungen) und die Geräte mussten auf die Datenreplikation (bis zu 2 Minuten) warten, bevor der neue Kanal erkannt wurde. Die neue Verhaltensweise liest nur vom Backend (für die Validierung) und speichert lokal, was die Kanalwechsel sofort ermöglicht.

Da setChannel() ist lokal nur, es schafft nicht eine Geräte-Übertragungseintrag in der Capgo-Oberfläche. Die Geräte-Übertragungs-UI zeigt nur die von der Oberfläche oder dem öffentlichen API erstellten Überschreibungen an.

Hinweis: Even wenn ein Kanal nach der lokalen Einstellung verboten wird, wird der Backend die Kanalvalidierung während der Aktualisierungskontrollen durchführen, sodass die Sicherheit aufrechterhalten wird.

Wichtig: Wenn Änderungen an den Kanälen über das Dashboard oder API vorgenommen werden, besteht ein Reproduktionsverzug von bis zu 2 Minuten, bevor alle Edge-Server die Änderung widerspiegeln. Für einen sofortigen Kanälschaltvorgang verwenden Sie setChannel() aus Ihrer App code—es validiert mit dem Backend und setzt den Kanal lokal für einen sofortigen Effekt.

4. Capacitor-Konfiguration defaultChannel (Standardbau für Testversionen) – Wenn vorhanden in capacitor.config.* und kein Zwang/Übernahme/lokaler Kanal existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123Zweck: Testversionen / interne Builds, damit Tester automatisch auf einem Vorkassenkanal landen. Produktionsbuilds lassen diesen normalerweise ungesetzt.
5. Standardkanal im Cloud (Hauptpfad ~99% der Benutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endbenutzer (kein Zwang, keine Dashboard/API-Übernahme, kein Plugin-Standardkanal, keine Konfiguration Standardkanal) hier angewiesen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen – kein neuer Binary. Wenn Sie plattform-spezifische Standards (z.B. ein iOS-only, ein Android-only, ein Electron-only) haben, landet jeder Gerät auf dem Standard, der seiner Plattform entspricht. Wenn Sie den Standardkanal im Cloud nicht setzen, ist das erlaubt; in diesem Fall muss das Gerät Schritt 1–4 erfüllen, um Updates zu erhalten.

Empfehlung:

• Behandeln Sie 1–4 als Ausnahmen / Testebenen; wenn Sie einen Standardkanal im Cloud setzen, sollten sich echte Benutzer in ihn einfließen. Wenn Sie keinen setzen, seien Sie bei der Zuweisung der Benutzer (typischerweise über defaultChannel in der Konfiguration oder per-Geräte-Überschreibungen).
• Konfigurieren Sie nur defaultChannel in Binärdateien, die Sie explizit an Tester weitergeben.
• Verwenden Sie setChannel() sparsam in der Produktion – hauptsächlich für QA oder gezielte Diagnosen.

Wenn ein Kanal für die Plattform (iOS/Android/Electron-Toggle) deaktiviert ist, wenn er sonst ausgewählt werden würde, springt die Auswahlprozess darüber hinweg und geht weiter mit der Liste.

Zusammenfassung: Force > Dashboard/API Override > Plugin setChannel() lokaler Kanal > Konfiguration defaultChannel > Cloud-Standard.

Console und API-Überschreibungen verfallen nach 90 Tagen

Zwangsabbildungen und Dashboard- oder öffentliche API-Kanal-Überschreibungen werden als per-Geräte-Zuweisungen in Capgo gespeichert. Ein Reinigungsjob löscht diese Zuweisungen. 90 Tage nach der letzten ÜberschreibungsänderungBei der Überprüfung auf eine Aktualisierung wird dieser Zeitraum nicht zurückgesetzt. Nur die erneute Schreibweise (oder das Löschen durch dich selbst) ändert den Timestamp.

Dies ist nicht dasselbe wie Geräteinventar-Retention. Inventar entfernt Geräte, die sich in den letzten 90 Tagen nicht mit Capgo verbunden haben. Die Überprüfung auf eine Aktualisierung entfernt die Zuordnung, selbst wenn das Gerät noch aktiv ist.

Für eine Zuweisung, die durch diese Überprüfung nicht entfernt wird:

• Setzen defaultChannel in capacitor.config.* (überlebt eine Wiederinstallation; erfordert ein neues natives Binärdatei, um es später zu ändern).
• Aufrufen setChannel() aus der App. Bei Plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 und später ist diese Zuweisung lokal und wird durch diese Überprüfung nicht entfernt. Eine Wiederinstallation der App löscht es, daher muss die App setChannel() wieder aufrufen, wenn Sie diese Kanal noch haben möchten.

Der Kanal Geräte Klicken Sie auf die Schaltfläche "Überschreiben" und wählen Sie das Gerät aus, das Sie in der Konsole und im öffentlichen API-Zuweisungsverzeichnis sehen möchten. Sie sehen nicht alle Geräte auf dem Kanal und sehen keine lokalen setChannel() Zuweisungen.

Warnung vor der Überschreibezeit auf der Kanal-Geräte-Tabelle.

Standardverhalten des Kanals

Die Festlegung eines Cloud-Standards ist optional, aber es dient normalerweise als Default-Pfad für neue Geräte. Ohne einen solchen Standard werden nur Geräte, die auf zwingenden Zuweisungen, Überschreibungen oder einem defaultChannel Capacitor-Konfigurationseinstellung übereinstimmen, Updates erhalten. Wenn Sie sich entscheiden, Standards zu setzen, beachten Sie diese Muster:

• Einziger Standard (am häufigsten) - Wenn ein Kanal iOS, Android und Electron aktiviert hat, wird er zum einzigen Standard; jedes Gerät ohne Überschreibungen wird hier angewiesen.
• Plattform-spezifische Standards – Wenn Sie die Kanäle nach Plattform aufteilen (z.B. nur iOS aktiviert, nur Android aktiviert und nur Electron aktiviert), markieren Sie jede als Standard für ihre Plattform. iOS-Geräte gehen auf den iOS-Standard, Android-Geräte gehen auf den Android-Standard und Electron-Anwendungen gehen auf den Electron-Standard. ios-production Denken Sie daran, dass der Cloud-Standard und android-production beide denselben Entscheidungsschicht besetzen. Wenn Sie einen Cloud-Standard setzen, müssen Sie den Wert nicht in Ihrer __CAPGO_KEEP_0__-Konfiguration duplizieren – lassen Sie ihn electron-production leer für Produktionsbuilds. Reservieren Sie

für Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie möchten, dass sie auf einem nicht-produktiven Kanal starten, auch wenn der Cloud-Standard anders ist. defaultChannel Sie können Standards jederzeit im Dashboard ändern. Öffnen Sie den Kanal, dann capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel Manage in App settings defaultChannel Manage in App settings

Manage in App settings Manage in App settings, das Sie zu Anwendungsinformationen. Die Standard-Einstellung ist nicht mehr ein Schalter auf der Kanal-Seite. Wenn Sie eine Standard-Einstellung austauschen, folgen neue Geräte sofort den neuen Routings und bestehende Geräte folgen den normalen Vorrangregeln beim nächsten Mal, wenn sie sich anmelden.

Ein Kanal einrichten

Während der Einrichtung erstellen Sie den ersten Kanal (die meisten Teams nennen ihn „Produktion“), aber nichts ist gesperrt – Sie können den Kanal umbenennen oder löschen, wann immer Sie möchten. Um zusätzliche Kanäle später hinzuzufügen:

1. Gehe zur „Kanäle“-Sektion der Capgo-Oberfläche
2. Klicke auf den „Neuen Kanal“-Button
3. Gib dem Kanal einen Namen ein und klicke auf „Erstellen“

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie ist es, Kanäle Ihren Entwicklungsstufen zuzuordnen, wie zum Beispiel:

• Development - für die Überprüfung von Live-Updates auf lokalen Geräten oder Emulatoren
• QA - für Ihren QA-Team, um Updates vor einer breiteren Veröffentlichung zu überprüfen
• Staging - für die endgültige Testung in einem Produktionsumfeld
• Production - für die Version Ihres Apps, die die Endnutzer von den App-Stores erhalten

Konfiguration des Kanals in Ihrer App

Nachdem Sie Ihre Kanäle erstellt haben, müssen Sie Ihre App so konfigurieren, dass sie auf den entsprechenden Kanal hört. In diesem Beispiel verwenden wir den Development Öffnen Sie Ihr

(oder capacitor.config.ts )-Datei. Unter der capacitor.config.jsonAbschnitt, setzen Sie optional plugins für defaultChannel Testversionen Builds (intern / QA). Für Produktionsbuilds bevorzugen Sie die Unterlassung, damit Geräte die Cloud-Standard verwenden, es sei denn, dies wird explizit überschrieben.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Nächstens bauen Sie Ihre Webanwendung und führen npx cap sync aus, um die aktualisierte Konfigurationsdatei in Ihre iOS-, Android- und Electron-Projekte zu kopieren. Wenn Sie diesen Synchronisierungsstep überspringen, werden Ihre native Projekte weiterhin diejenige Kanal verwenden, für die sie zuvor konfiguriert waren.

Vorsicht

Kanalwahl-Reihenfolge: Zwang > Dashboard/API Geräteüberschreibung > Plugin setChannel() lokaler Kanal > Konfiguration defaultChannel > Cloud-Standard.

Verwenden defaultChannel nur in Test-/internen Builds; lassen Sie es für Produktionszwecke heraus, damit die Benutzer den Cloud-Standard (wenn gesetzt) befolgen, anstatt die Routen in der native Konfiguration zu duplizieren.

Sie können ein Gerät noch immer zwingen (festlegen) oder eine Überschreibung anwenden – diese überschreiben die Konfigurationswerte sofort.

Channelnamen sind case sensitive.

Kanaloptionen und Strategien

Kanäle haben mehrere Optionen, die steuern, wer Updates erhalten kann und wie Updates geliefert werden. Die wichtigsten sind unten aufgeführt. Sie können diese im Web-App, der CLI, oder der öffentlichen API konfigurieren.

• Standardkanal: Optional markieren Sie den Kanal oder Plattform-spezifischen Kanäle, die neue Geräte anbinden. Im Konsole lebt dies auf App-Informationen (Verwalten Sie in den App-Einstellungen aus der Kanal-Seite). Siehe “Standardkanalverhalten” für Routingszenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Androidoder Electron Geräte pro Kanal.
• Deaktivieren Sie die automatische Downgrade unter native: Verhindert die Sendung eines Updates, wenn das Geräte-native-App-Version neuer ist als der Kanal-Bundle (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Ermöglichen Sie Entwicklungsbuilds: Ermöglichen Sie Updates für Entwicklungsbuilds (nützlich für Tests). CLI: --dev / --no-dev.
• Allow production builds: Permit updates to production (store) builds. Leave this on for channels that serve real users. CLI: --prod / --no-prod.
• Allow emulator devices: Permit updates to emulators/simulators (useful for testing). CLI: --emulator / --no-emulator.
• Allow physical devices: Permit updates to real phones and tablets. Leave this on for production channels. CLI: --device / --no-device.
• Geräte selbst zuweisen: Lassen Sie die App während der Ausführung auf diesem Kanal wechseln, indem Sie setChannelbenutzen. Wenn dies deaktiviert ist, setChannel will fail for this channel. CLI: --self-assign / --no-self-assign.
• Paketaktualisierung: Wählen Sie aus, ob Geräte ein vollständiges Zip-Datei-Paket, eine Delta-Liste der geänderten Dateien oder beide herunterladen sollen (all, zip, delta, zip_from_builtin, delta_from_builtinSiehe Paketaktualisierung für die Konsole und die Dropdown-Liste und erfahren Sie, wann jede dieser Optionen nützlich ist.

Progressive Rollouts

Aus einem Kanal kann ein stabiler Paketbundle beibehalten werden, während ein separater Rollout-Ziel für eine stöckige Gerätegruppe allmählich freigegeben wird. Sie können das Update aussetzen, wieder aufnehmen, vorziehen, rückgängig machen und eine automatische Fehlerantwort konfigurieren, ohne dass der Kanal für alle Benutzer geändert wird. Siehe Progressive Rollouts für das Liefermodell, das Dashboard-Workflow, API Felder und CLI Befehle.

Automatische Aktualisierungsstrategien deaktivieren

Verwenden Sie dies, um festzulegen, welche Arten von Updates der Kanal automatisch liefern wird. Optionen:

• major: Blockiert ein Ziel-Paket, dessen Hauptversion höher ist als die native Gerätegrundlage (version_buildBeispiel: 1.2.3 -> 2.0.0 ist blockiert; 1.2.3 -> 1.9.0 ist erlaubt.
• minor: Blockiert ein Ziel-Paket, dessen Haupt- oder Minorversion sich von version_buildBeispiel: 1.2.3 -> 1.3.0 blockiert; 1.2.3 -> 1.2.4 erlaubt.
• Patch: Striktster Modus. Blockiert jede Änderung an der Haupt-, Minor- oder Patchversion. Nur Suffix-Änderungen sind erlaubt, während MAJOR.MINOR.PATCH bleibt identisch. Beispiele: 1.0.0-beta.1 -> 1.0.0-beta.2 erlaubt; 1.0.0+build.1 -> 1.0.0+build.2 erlaubt; 1.0.0 -> 1.0.1 blockiert.
• Metadaten: Erfordert eine Mindestversion von Updates-Metadaten auf jedem Bundle. Konfigurieren Sie über CLI --min-update-version oder --auto-min-update-versionbleibt identisch. Beispiele:
• erlaubt, erlaubt, oder blockiert..

Diese Strategien vergleichen das Zielbundle des Kanals mit der native Baseline, die als version_build, nicht das aktuell heruntergeladene Bundle, das als version_name.

Weitere Details und Beispiele finden Sie in der Disable-Updates-Strategie unter /docs/cli/commands/#disable-updates-strategie.

Beispiel (CLI). Der Kanal muss bereits existieren (channel set er wird nicht erstellt):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

Mit setChannel() aus Ihrer App

Die setChannel() Methode ermöglicht es Ihrer App, Kanäle programmatisch während der Ausführung zu wechseln. Dies ist insbesondere nützlich für:

• QA/Debug-Menüs, bei denen Tester zwischen Kanälen wechseln können
• Beta-Programm-Opt-in-Flows
• Feature-Flag-Implementierungen
• A/B-Test-Szenarien

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Wie setChannel() funktioniert (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Wenn setChannel() wird aufgerufen:

1. Hintergrundvalidierung (nur Lesen): Ein Anfrage wird an den Capgo Backend gesendet, um die Zulässigkeit des Kanals zu überprüfen (Überprüfung der Selbstzuweisungsrechte)
2. Lokale Speicheraktualisierung: Wenn die Überprüfung erfolgreich ist, wird der Kanal im Gerätespeicher als defaultChannel
3. Instant Effekt: Die nächste Aktualisierungskontrolle verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Weshalb das wichtig ist: In älteren Versionen, setChannel() gespeichert wurde der Kanal-Übertrag in der Backend-Datenbank (gleich wie Dashboard oder API-Änderungen). Geräte mussten auf die Backend-Replikation (bis zu 2 Minuten) warten, bevor der Kanal-Wechsel wirksam wurde. Jetzt setChannel() liest nur noch vom Backend (für die Validierung) und speichert lokal, was den Kanal-Wechsel sofort wirksam macht.

Dashboard-Ansicht: Eine mit dem Plugin gesetzte Kanal-Einstellung macht das Gerät nicht als Geräte-Übertragung im Capgo-UI sichtbar. Nur Kanal-Zuweisungen, die aus dem Dashboard oder dem öffentlichen API erstellt wurden, werden dort aufgelistet. Verwenden Sie das Dashboard oder API , wenn Sie eine admin-sichtbare Übertragung benötigen.

Sicherheitshinweis: Even wenn sich die Berechtigungen eines Kanals nach der lokalen Einstellung ändern (z.B. Selbstzuweisung ist deaktiviert), wird der Backend die Kanal-Überprüfung während der Aktualisierungskontrollen durchführen, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanal-Änderungsmethoden:

Methode	Effektzeit	Gedächtnisort	Angezeigt im Geräte-Überschreibungs-UI	Ablaufdatum	Verwendungsbereich
setChannel() Von Plugin	Instant	Gerät nur (lokal)	Nein	Nein (bis du es änderst oder neu installierst)	Benutzerinitiierte Kanalwechsel in-app
Geräteübersicht-Überschreibung	Bis zu 2 min	Backend-Datenbank	Ja	90 Tage nach der letzten Überprüfung	Admin-gesteuerte Änderungen für bestimmte Geräte
API Kanalzuweisung	Bis zu 2 min	Backend-Datenbank	Ja	90 Tage nach der letzten Überprüfung	Automatisierte Backend-Integrationen

Für die beste Benutzererfahrung bei der Erstellung von UIs für den Kanalwechsel, verwenden Sie immer das Plugin setChannel() Methode.

Mindestversionen für die lokale Kanalwechselung: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 (abhängig von Ihrer Hauptversion). Jede Minorversionennummer entspricht demselben Funktionsumfang in allen Hauptversionen (z.B. X.34.0 enthält die gleichen Funktionen, egal ob X 5, 6, 7 oder 8 ist). Siehe Plugininstallation für Versionsetiketten.

Zuweisung eines Bundles an einen Kanal

Um eine Live-Update zu deployen, müssen Sie ein neues JS-Bundle-Build hochladen und es einem Kanal zuweisen. Sie können dies in einem Schritt mit dem Capgo CLI durchführen:

npx @capgo/cli@latest bundle upload --channel=Development

Dies wird Ihre gebauten Webassets hochladen und das neue Bundle als aktives Build für den Development Kanal. Jeder App, die auf diesen Kanal eingestellt ist, erhält die Aktualisierung beim nächsten Mal, wenn sie nach einer aktualisiert wird.

Sie können auch Builds auf Kanäle aus der "Bundles"-Sektion des Capgo-Dashboards zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie "Zuweisen an Kanal" aus, um den Kanal für diesen Build auszuwählen.

Bündelversionierung und Kanäle

Es ist wichtig zu beachten, dass Bündel in Capgo global für Ihre App sind und nicht spezifisch auf einzelne Kanäle beschränkt sind. Das gleiche Bündel kann auf mehrere Kanäle zugewiesen werden.

Bei der Versionsnummerierung Ihrer Bündel empfehlen wir die Verwendung von semantischer Versionsnummerierung mit Capgo’s Semver-Tester und Voreinstellungen für kanalbezogene Builds. Zum Beispiel könnte eine Beta-Version als 1.2.3-beta.1.

In der CI-Umgebung wird empfohlen, wenn die lokale Version bereits hochgeladen wurde, zu verwenden npx @capgo/cli@latest bundle upload --auto-bump optional major, minor, patch/fix, metadataoder aiso dass CLI bis zu einem freien Namen von den kanalverbundenen Bündeln springt. ai, Arbeiter AI schätzt den Level aus dem lokalen vs. vorherigen Delta-Manifest (fällt zurück auf patch mit keinem vorherigen Capgo-Version. Sie können es nicht kombinieren mit --bundle. Siehe und die __CAPGO_KEEP_0__-Referenz CLI reference.

Es kommuniziert die Beziehung zwischen Builds klar.

• ist offensichtlich eine Vorschau von 1.2.3-beta.1 Es ermöglicht die Wiederverwendung von Versionsnummern über Kanäle hinweg, was Verwirrung reduziert. 1.2.3.
• Es ermöglicht klare Rollback-Pfade. Wenn Sie von
• zurückrollen müssen, wissen Sie 1.2.3CI/CD-Integration 1.2.2 ist die vorherige stabile Version.

Hier ist ein Beispiel dafür, wie Sie Ihre Bundle-Versionen mit einer typischen Kanal-Konfiguration ausrichten können:

• Development Kanal: 1.2.3-dev.1, 1.2.3-dev.2usw.
• QA Kanal: 1.2.3-qa.1, 1.2.3-qa.2usw.
• Staging Kanal: 1.2.3-rc.1, 1.2.3-rc.2usw.
• Production Kanal: 1.2.3, 1.2.4usw.

Mit semver mit Voreinstellungen ist eine empfohlene Vorgehensweise, aber nicht streng erforderlich. Der Schlüssel besteht darin, eine Versionsierungsschematik zu finden, die die Beziehungen zwischen Ihren Builds klar kommuniziert und mit Ihrem Teams Entwicklungsprozess übereinstimmt.

Rückgängig machen eines Live-Updates

Wenn Sie ein Live-Update bereitstellen, das einen Fehler einführt oder anderweitig rückgängig gemacht werden muss, können Sie leicht auf einen vorherigen Build zurückkehren. Aus der ‘Kanäle’-Sektion der Oberfläche:

1. Klicken Sie auf den Namen des Kanals, auf den Sie zurückkehren möchten
2. Finden Sie den Build, auf den Sie zurückkehren möchten, und klicken Sie auf das Krönchen-Symbol
3. Bestätigen Sie die Aktion

Der ausgewählte Build wird sofort wieder der aktive Build für diesen Kanal. Apps erhalten die zurückgekehrte Version beim nächsten Mal, wenn sie nach einer Aktualisierung suchen.

Automatisierung der Bereitstellung

Für fortgeschrittene Workflows können Sie Ihre Live-Update-Bereitstellungen automatisieren, indem Sie sie als Teil Ihres CI/CD-Pipelines integrieren. Indem Sie Capgo in Ihren Build-Prozess integrieren, können Sie neue Pakete automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Zweige pushen oder neue Releases erstellen.

Besuchen Sie die CI/CD-Integration docs to learn more about automating Capgo live updates.

Mindestberechtigte Pull-Request-Vorschau

Einen App-Vorschau API-Schlüssel verwenden, wenn CI einen temporären Kanal pro Pull-Request benötigt, aber bestehende Haupt-/Standardkanäle nicht verwalten muss. Der Schlüssel bleibt an die eigenen Organisation und die ausgewählte App gebunden; er hat einfach keine Organisationsebene. Jeder nicht öffentliche Vorschaukanal, den es erstellt, erhält seine eigene automatische, kanal-geschachtelte Lifecycle-Berechtigung.

1. Haben Sie einen Organisation administrator einen sicheren API-Schlüssel erstellen, der nur für die Vorschau-App beschränkt ist und wählen Sie App-Vorschau. Siehe API-Schlüssel.
2. Verwenden Sie ein einzigartiges, nicht öffentliches Kanal wie pr-123Passen Sie keine --default, --self-assignausrollen Sie Optionen oder --delete-linked-bundle-on-upload.
3. Hochladen und das PR-Paket in einer Befehlszeile promoten, dann löschen Sie das Kanal und das Paket, wenn der PR geschlossen ist:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel Erstellt ein fehlendes Kanal, lädt das Paket hoch und promotet es in einer einzigen Fluss. Die Reinigung ist atomar und eignungsüberprüft: Die Schlüssel kann nur ein Kanal löschen, den sie erstellt hat und ihr verbundenes, nicht geteiltes Paket. Sie kann nicht ändern, promoten oder löschen ein bestehendes Haupt-/Standardkanal, ein anderes Vorschau-Schlüssels Kanal oder ein anderes Schlüssels Paket.

Wenn Rezensionen eine QR code oder eine Vorschau-URL benötigen, muss ein Administrator die Vorschau einmal für die App aktivieren:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Ein App-Vorschau-Schlüssel kann die Vorschau nicht selbst aktivieren, da er keine Anwendungseinstellungen-Rechte hat. In GitHub Aktionen, führen Sie geheime Vorschau-Aufgaben auf pull_request, nicht pull_request_target, und beschränken sie auf PRs mit gleicher Repository github.event.pull_request.head.repo.full_name == github.repository.

Auf einem Gerät bereitstellen

Jetzt, da du die Kanäle verstehst, bist du bereit, Live-Updates auf echten Geräten zu deployen. Der grundlegende Prozess ist:

1. Installieren Sie die Capgo SDK in Ihrer App
2. Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu hören
3. Ein Build hochladen und diesem Kanal zuweisen
4. Die App starten und auf die Aktualisierung warten!

Für eine detailliertere Anleitung siehe das Live-Updates deployen Leitfaden. Viel Spaß beim Aktualisieren!

Erweiterte Kanalnutzung: Benutzersegmentierung

Kanäle können für mehr als nur Entwicklungsstufen verwendet werden. Sie sind ein mächtiges Werkzeug für die Benutzersegmentierung, das Funktionen wie:

• Feature-Flags für verschiedene Benutzertiere
• A/B-Test
• Graduelle Funktionserweiterungen
• Betaversionstests

Erhalten Sie weitere Informationen, wie Sie diese erweiterten Anwendungsfälle umsetzen können, in unserem Leitfaden: Wie Sie Benutzer nach Plan und Kanälen segmentieren und Feature-Flags und A/B-Test durchführen.

Fortsetzung von Kanälen

Wenn Sie Kanäle verwenden um Kanalrouting und eine aufgeteilte Rolloutplanung zu gestalten, verbinden Sie es mit Kanäle Kanäle Kanäle Kanäle Testlösung zur Produktionsablauf in der Testlösung Zielgruppenzielorientierung zur Produktionsablauf in der Zielgruppenzielorientierung Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID zum praktischen Kontext in Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID