Kanäle

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

Ein Live-Update-Kanal verweist auf eine bestimmte JS-Bundle-Build Ihres Apps, die mit allen Geräten geteilt wird, die auf das Hören dieses Kanals für Updates konfiguriert sind. Wenn Sie das __CAPGO_KEEP_0__ Live-Updates-__CAPGO_KEEP_1__ installieren install the Capgo Live Updates SDK In Ihrer App prüft jede native Binärkonfiguration, die diesem Kanal zugeordnet ist, bei jedem Start der App nach verfügbaren Updates. Sie können das Ziel des Build-Kanals jederzeit ändern und können auch auf vorherige Builds zurückkehren, wenn erforderlich.

Details.

When a device checks for an update, Capgo decides which channel to use in this strict order (highest priority first):

Wenn ein Gerät nach einem Update sucht, entscheidet __CAPGO_KEEP_0__, welcher Kanal in dieser strengen Reihenfolge (höchste Priorität zuerst) verwendet wird: Zwangsmapping des Geräts (Dashboard)
Cloud override (per‑device) via Dashboard or API – Erstellt, wenn Sie das Gerätekanal im Dashboard oder über API ändern. Verwenden Sie es für QA-Benutzer, die zwischen Feature/PR-Kanälen wechseln oder um ein Benutzerproblem nachzuvollziehen. Eine erneute Installation des Binärs löscht ihn nicht; die Löschung der Geräte-Einträge tut es auch nicht.
Plugin setChannel() lokaler 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.

Ab der Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion), setChannel() arbeiten Sie 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 es den Kanal auf dem Gerät lokal als defaultChannel. Dies bedeutet, dass der neue Kanal sofort wirksam wird unmittelbar für die nächste Aktualisierungsprüfung—keine Wartezeit für die Replikation.

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

Da setChannel() ist lokal nur, es erstellt keine Geräte-Überladungseintrag im __CAPGO_KEEP_0__ Dashboard. Die Geräte-Überladung-UI zeigt nur die von der Dashboard oder dem öffentlichen __CAPGO_KEEP_1__ erstellten Überladungen an. create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Note: Even wenn ein Kanal nach lokaler Einstellung gesperrt wird, wird der Backend den Kanal während der Update-Überprüfungen noch immer validieren, so dass die Sicherheit gewährleistet ist.

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

Capacitor-Konfiguration defaultChannel (Standardbau für Testversion) – Wenn vorhanden in capacitor.config.* und keine Zwang/Übernahme/Lokalkanal existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123). Für TestFlight/innere Builds gedacht, damit Tester automatisch auf einem Vorkabel-Kanal landen.
Hauptkanal 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-Lokalkanal, keine Konfiguration defaultChannel) hier anhängen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen—kein neuer Binary. Wenn Sie plattform-spezifische Standards (z.B. eine iOS nur, eine Android nur, eine Electron nur) haben, landet jeder Gerät auf dem Standard, der seiner Plattform entspricht. Das Ignorieren des Cloud-Standards ist erlaubt; in diesem Fall muss das Gerät Schritte 1–4 erfüllen, um Updates zu erhalten.

Empfehlung:

Behandeln Sie 1–4 als Ausnahmen / Testebenen; wenn Sie eine Cloud-Standardkonfiguration setzen, sollten sich echte Benutzer in sie einfließen. Wenn Sie keine setzen, sollten Sie sich bewusst sein, wie Benutzer sich (typischerweise über defaultChannel in der Konfiguration oder per-Geräte-Überprüfungen) anbinden.
Nur in defaultChannel binärer Form konfigurieren, die Sie explizit an Tester verschicken. Wenn Sie es ungesetzt lassen, bleibt die Produktionslogik im Dashboard zentralisiert.
Verwenden Sie setChannel() seltener 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: Zwang > Dashboard/API Überschreibung > Plugin setChannel() lokaler Kanal > Konfiguration defaultChannel > Cloud-Standard.

Standardverhalten des Kanals

Ein Cloud-Standard setzen ist optional, aber es dient normalerweise als allgemeiner Pfad für neue Geräte. Ohne einen solchen Standard erhalten nur Geräte, die auf zwingenden Zuordnungen, Überschreibungen oder einem defaultChannel im Capacitor-Konfiguration, Updates.

Wenn Sie sich entscheiden, Standards zu markieren, 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 angeschlossen. Plattform-spezifische Standards ios-production – Wenn Sie Kanäle nach Plattformen aufteilen (z.B. android-production mit nur iOS aktiviert electron-production mit nur Android aktiviert

mit nur Electron aktiviert defaultChannel ), markieren Sie jeden als Standard für seine Plattform. iOS-Geräte gehen zum iOS-Standard, Android-Geräte zum Android-Standard und Electron-Anwendungen zum Electron-Standard. 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 leer für Produktionsbuilds. Reservieren Sie defaultChannel für Binaries, die Sie absichtlich an Tester oder QA liefern möchten, wenn Sie ihnen einen nicht-produktiven Kanal wünschen, selbst wenn der Cloud-Standard anders ist.

Sie können die Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, befolgen neue Geräte den neuen Routing sofort und bestehende Geräte folgen den normalen Vorrangregeln beim nächsten Check-in.

Einrichten eines Kanals

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

Gehe zur „Kanäle“-Sektion des Capgo-Dashboards
Klicke auf den „Neuen Kanal“-Button
Geben Sie einen Namen für den Kanal ein und klicken Sie auf „Erstellen“

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie besteht darin, Kanäle Ihren Entwicklungsstufen zuzuordnen, wie z.B.:

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

Kanal konfigurieren in Ihrer App

Nachdem Sie die 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 Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json)-Datei. Unter der plugins Sektion, setzen Sie optional defaultChannel für Testversionen (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 den sie zuvor konfiguriert waren.

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. Diese können Sie von der Webanwendung, der CLI, oder der öffentlichen API konfigurieren.

Standardkanal: Optional markieren Sie den Kanal oder Plattform-spezifischen Kanäle, die neue Geräte anbinden. Siehe “Standardkanalverhalten” für Routing-Szenarien.
Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
Automatische Downgrade unter native deaktivieren: Verhindert die Übermittlung eines Updates, wenn das Geräte- native App-Version neuwärmer ist als der Kanal-Bundle (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
Entwicklungsbuilds zulassen: Ermöglichen Sie Updates für Entwicklungsbuilds (nützlich für Tests).
Emulatortechnik zulassen: Ermöglichen Sie Updates für Emulatoren/Simulator (nützlich für Tests).
Geräte selbst zuweisen zulassen: Lassen Sie die App zu diesem Kanal umschalten, sobald sie bereit ist. setChannel. Wenn deaktiviert, setChannel wird dies für diesen Kanal fehlschlagen.

Automatische Aktualisierungsstrategien deaktivieren

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

major: Blockieren Sie Updates zwischen verschiedenen Hauptversionen (0.0.0 → 1.0.0). Kleine und Patches-Updates sind weiterhin zulässig.
minor: Blockieren Sie Updates zwischen verschiedenen Minor-Versionen (z.B. 1.1.0 → 1.2.0) und Hauptversionen. Patches-Updates sind weiterhin zulässig. Hinweis: Blockiert nicht 0.1.0 → 1.1.0.
patch: Sehr streng. Erstellt nur Zuwächse von Patches-Versionen innerhalb derselben Haupt- und Minor-Version. Beispiele: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
metadata: Erfordert eine Mindestaktualisierungsversion-Metadaten auf jedem Bundle. Konfigurieren Sie über CLI mit --min-update-version oder --auto-min-update-versionWenn fehlend, wird der Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis sie gesetzt werden.
none: Zulässt alle Updates entsprechend semver-Kompatibilität.

Mehr Details und Beispiele finden Sie in der Strategie zur Deaktivierung von Updates unter /docs/cli/commands/#disable-updates-strategy.

Beispiel (CLI):

# 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

Mit setChannel() aus Ihrer App

Die setChannel() Methode ermöglicht es Ihrer App, programmatisch zwischen Kanälen umzuschalten. Dies ist insbesondere nützlich für:

QA/Debug-Menüs, bei denen Tester zwischen Kanälen umschalten können
Beta-Programm-Opt-in-Flows
Implementierungen von Feature-Flags
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
});

Wann setChannel() aufgerufen wird:

Hintergrundvalidierung (lesen nur): Ein Anfrage wird an den Capgo Backend gesendet, um zu überprüfen, ob der Kanal zugelassen ist (Überprüfung der Selbstzuweisungsrechte)
Speicherung in der lokalen Zwischenablage: Wenn die Überprüfung erfolgreich ist, wird der Kanal im Gerätespeicher als defaultChannel
Instant-Effekt: Die nächste Aktualisierungsprüfung verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Why dies es wichtig: Bei älteren Versionen, setChannel() speicherte die Kanalüberschreibung im Backend-Datenbank (gleich wie Dashboard oder API Änderungen). Geräte mussten auf Backend-Replikation (bis zu 2 Minuten) warten, bevor die Kanaländerung wirksam wurde. Jetzt, setChannel() liest nur vom Backend (für die Validierung) und speichert lokal, was die Kanalwechsel sofort wirksam macht.

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

Sicherheitshinweis: Even wenn die Kanalberechtigungen nach der lokalen Festlegung geändert werden (z.B. Selbstzuweisung deaktiviert), wird das Backend die Kanalüberprüfung während der Update-Überprüfungen durchführen, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanaländerungsverfahren:

Methode	Wirkungszeit	Gespeichert in	In der Geräteüberschreibungs-UI angezeigt	Anwendungsbereich
`setChannel()` aus Plugin	Instant	Gerät nur (lokal)	Nein	Benutzerinitiierte Kanalwechsel in der App
Übersichtsgeräteüberschreibung	bis zu 2 min	Hintergrund-Datenbank	Ja	Admin-gesteuerte Änderungen für spezifische Geräte
API Kanalzuweisung	bis zu 2 min	Hintergrund-Datenbank	Ja	Automatisierte Hintergrundintegrationen

Für die beste Benutzererfahrung bei der Erstellung von UIs für das Wechseln von Kanälen, verwenden Sie immer die setChannel() Methode.

Mindestversionen für die lokale Kanalwechselfunktion: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 (abhängig von Ihrer Hauptversion). Jede kleine Versionennummer entspricht dem gleichen Funktionsumfang in allen Hauptversionen (z.B. X.34.0 enthält die gleichen Funktionen, unabhängig davon, ob X 5, 6, 7 oder 8 ist). Siehe Plugin-Installation für Versionsetiketten.

Ein Bundle einer Kanal zuweisen

Um ein 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 der Capgo CLI: durchführen.

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

Dies wird Ihre gebauten Web-Assets hochladen und das neue Bundle als aktives Build für den Development Kanal setzen. Jeder App, die auf diesen Kanal lauscht, erhält das Update beim nächsten Mal, wenn sie nach einem Update suchen.

Sie können auch Builds auf Kanäle im ‘Bundles’-Abschnitt der Capgo-Oberfläche zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie ‘Auf Kanal zuweisen’ aus, um den Kanal für dieses Build auszuwählen.

Bundle-Versionierung und Kanäle

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

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

Diese Vorgehensweise hat mehrere Vorteile:

Es kommuniziert offensichtlich die Beziehung zwischen Builds. 1.2.3-beta.1 ist offensichtlich eine Vorabversion von 1.2.3.
Es ermöglicht die Wiederholung von Versionszahlen über Kanäle, was Verwirrung reduziert.
Es ermöglicht klare Rückkehrpfade. Wenn Sie von 1.2.3, wissen Sie 1.2.2 ist die vorherige stabile Version.

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

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

Verwendung Die Verwendung von semver mit Voreinstellungen ist eine empfohlene Vorgehensweise, aber nicht strikt erforderlich. Der Schlüssel ist es, eine Versionsierungsschematik zu finden, die die Beziehungen zwischen Ihren Builds klar kommuniziert und mit Ihrem Teams Entwicklungsprozess übereinstimmt. Rückgängigmachen eines Live-Updates

Abschnitt mit dem Titel „Rückgängigmachen eines Live-Updates“

Wenn Sie ein Live-Update bereitstellen, das einen Fehler enthält oder anderweitig rückgängig gemacht werden muss, können Sie leicht auf einen vorherigen Build zurückkehren. Aus der „Kanäle“-Sektion der Dashboard:

Klicken Sie auf den Namen des Kanals, den Sie zurückrollen möchten
Finden Sie das Build, das Sie wiederherstellen möchten, und klicken Sie auf das Krönchen-Symbol
Bestätigen Sie die Aktion

Das ausgewählte Build wird sofort wieder der aktive Build für diesen Kanal sein. Apps erhalten die zurückgerollte 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 als Teil Ihres CI/CD-Pipelines automatisieren. Durch die Integration von Capgo in Ihren Build-Prozess können Sie neue Bundles automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

Checken Sie die CI/CD-Integration Dokumentationen, um mehr über die Automatisierung von Capgo-Live-Updates zu erfahren.

Bereitstellung auf einem Gerät

Jetzt, da Sie die Kanäle verstehen, sind Sie bereit, live-aktualisierte Updates auf echte Geräte zu deployen. Der grundlegende Prozess ist:

Installieren Sie die Capgo SDK in Ihrer App
Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu hören
Hochladen Sie ein Build und zuweisen Sie es diesem Kanal
Starten Sie die App und warten Sie auf das Update!

Für eine detailliertere Anleitung, sehen Sie sich das Live-Updates bereitstellen Leitfaden an.

Glückwunsch zum Aktualisieren!

Abschnitt mit dem Titel “Erweiterte Kanalnutzung: Benutzersegmentierung”

Funktionsschalter für verschiedene Benutzerstufen
A/B-Prüfungen
Schrittweise Einführung von Funktionen
Beta-Testprogramme

Lernen Sie, wie Sie diese fortgeschrittenen Anwendungsfälle in unserer Anleitung umsetzen können: Wie man Benutzer nach Tarif und Kanälen segmentiert, um Funktionsschalter und A/B-Prüfungen durchzuführen.

Weiterhin von Kanälen

Wenn Sie Kanäle für die Planung von Kanalroutings und der schrittweisen Einführung verwenden, verbinden Sie sie mit Kanäle für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, Beta-Testlösung für den Produktworkflow in Beta-Testlösung, Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung, und Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID für den praktischen Kontext in Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID.