Kanäle

Eine Live-Update-Kanal zeigt auf eine bestimmte JS-Bundle-Build Ihres Apps, die an alle Geräte weitergegeben wird, die auf das Abonnieren dieses Kanals für Updates konfiguriert sind. Wenn Sie den Capgo Live-Updates SDK in Ihrer App installieren, überprüfen alle native Binärdateien, die auf diesen Kanal konfiguriert sind, bei jedem Start der App nach verfügbaren Updates. Sie können die Build, auf die ein Kanal zeigt, jederzeit ändern und können auch auf vorherige Builds zurückkehren, wenn nötig.

Kanäle bieten keine Vertraulichkeit

Kanäle bestimmen die Aktualisierungsbedingungen, nicht die Paketgeheimhaltung. Selbst wenn ein Kanal privat ist oder die Selbstzuweisung deaktiviert ist, sollte ein unverschlüsselter Paketupload auf Capgo immer noch als öffentliches Asset behandelt werden, das an die Kunden weitergegeben wird. Die Verschlüsselung schützt den Übertragungsweg und die Authentizität der Updates, aber die verschickten 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 Details.

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

When ein Gerät eine Aktualisierung überprüft, Capgo entscheidet, welchen Kanal zu verwenden ist, in dieser strengen Reihenfolge (höchste Priorität zuerst):

1. Zwangsmapping von Geräten (Dashboard) – Ein bestimmtes Geräte-ID manuell auf einen Kanal festlegen. Verwenden Sie dies für dringende Debugging oder kontrollierte Tests mit einem einzelnen echten Benutzer.
2. Cloud-Übernahme (pro-Gerät) via Dashboard oder API – Erstellt, wenn Sie die Gerätekanal im Dashboard oder via API ändern. Verwenden Sie dies für QA-Benutzer, die zwischen Feature- / PR-Kanälen wechseln oder um ein Benutzerproblem nachzubilden. Eine erneute Installation des Binärs löscht ihn nicht; die Löschung der Geräte-Einträge tut es.

Instant Channel Switching mit setChannel()

Ab Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion) setChannel() anders funktioniert: Es kontaktiert den Backend, um zu validieren dass der Kanal zugelassen ist (Überprüfung, ob 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 sogleich für die nächste Aktualisierungskontrolle—keine Wartezeit für die Replikation.

Zuvor setChannel() hatte die Speicherung der Kanalüberschreibung im Backend-Datenbank (wie Dashboard oder API Änderungen) und die 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 die Kanalwechsel sofort macht.

Hinweis: Even wenn ein Kanal nach der lokalen Einstellung verboten wird, wird das Backend den Kanal während der Aktualisierungskontrollen nochmals validieren, sodass die Sicherheit gewährleistet ist.

Wichtig: Wenn Kanaländerungen über das Dashboard oder API vorgenommen werden, besteht immer noch eine Replikationsverzögerung 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 mit dem Backend und setzt den Kanal lokal für sofortigen Effekt.

3. Capacitor Konfiguration defaultChannel (Testbau Standard) – Wenn diese im capacitor.config.* und keine Zwangs-/Überladung existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123). Für TestFlight- / interne Builds so konfiguriert, dass Tester automatisch auf einem Vorkabel-Kanal landen. Produktion Builds lassen diesen normalerweise ungesetzt.
4. Cloud-Standardkanal (Hauptpfad ~99% der Benutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endbenutzer (keine Zwangs-, keine Überladung, keine Konfigurations-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. Das Ignorieren des Cloud-Standard-Kanals ist erlaubt; in diesem Fall muss das Gerät auf Schritte 1-3 abgestimmt sein, um Updates zu erhalten.

Empfehlung:

• Behandeln Sie 1-3 als Ausnahmen / Testebenen; wenn Sie einen Cloud-Standard setzen, sollten echte Benutzer in ihn fließen. Wenn Sie ihn nicht setzen, sollten Sie sich bewusst sein, wie Benutzer sich anbinden (typischerweise via defaultChannel in der Konfiguration oder per-Geräte-Überladungen).
• Konfigurieren Sie nur defaultChannel in Binaries, die Sie explizit an Tester verschicken. Das Ignorieren dieses Feldes hält die Produktionslogik zentral im Dashboard.
• Verwenden Sie es sparsam in der Produktion—hauptsächlich für QA oder gezielte Diagnosen. setChannel() 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 > Override > Config

> Cloud Standard. defaultChannel Standardverhalten des Kanals

Abschnitt mit dem Titel “Standardverhalten des Kanals”

im __CAPGO_KEEP_0__-Konfigurationen, Updates. defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• Einziger Standard (am häufigsten) – Wenn ein Kanal iOS, Android und Electron aktiviert ist, wird er der einzige Standard; jedes Gerät ohne Überschreibungen wird hier anhaften.
• Plattform-spezifische Standards – Wenn Sie die Kanäle nach Plattform aufteilen (z.B. nur iOS aktiviert, ios-production mit nur iOS aktiviert, android-production mit nur Android aktiviert, und electron-production mit nur Electron aktiviert), markieren Sie jede als Standard für ihre Plattform. iOS-Geräte gehen auf den iOS-Standard, Android-Geräte auf den Android-Standard und Electron-Anwendungen auf den Electron-Standard.

Denken Sie daran, dass der Cloud-Standard und defaultChannel in capacitor.config.* beide denselben Entscheidungsschicht besetzen. Wenn Sie einen Cloud-Standard setzen, benötigen Sie nicht, die Werte in Ihrem Capacitor-Konfiguration zu duplizieren—lassen Sie defaultChannel leer für Produktionsbuilds. Reserve defaultChannel für Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie möchten, dass sie auf einem Nicht-Produktionskanal starten, selbst wenn der Cloud-Standard anders ist.

Sie können die Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, folgen neue Geräte sofort den neuen Routen und bestehende Geräte folgen den normalen Vorzugregeln die nächste Zeit, wenn sie sich anmelden.

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 weitere Kanäle später hinzuzufügen:

1. Gehe zur „Kanäle“-Sektion des Capgo-Dashboards
2. Klicke auf den „Neuen Kanal“-Button
3. Gib einem Kanal einen Namen und klicke auf „Erstellen“

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie besteht darin, 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 Ihre QA-Team, um Updates vor einer breiteren Veröffentlichung zu überprüfen
• Staging - für die endgültige Überprüfung in einem Produktionsumfeld
• Production - für die Version Ihres Apps, die Benutzer von den App-Stores erhalten

Kanal konfigurieren in Ihrer App

Mit Ihren Kanälen erstellt, müssen Sie Ihre App so konfigurieren, dass sie auf den entsprechenden Kanal hört. In diesem Beispiel verwenden wir das Development Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json) Datei. Unter der plugins Abschnitt, optional setzen Sie defaultChannel für Test Builds (intern / QA). Für Produktionsbuilds bevorzugen Sie die Unterdrückung, 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ächsten, bauen Sie Ihre Web-App und führen Sie npx cap sync um die aktualisierte Konfigurationsdatei in Ihre iOS-, Android- und Electron-Projekte zu kopieren. Wenn Sie diesen Synchronisierungs-Schritt überspringen, werden Ihre native Projekte weiterhin diejenige Kanal verwenden, für die sie zuvor konfiguriert waren.

Achtung

Kanalwahl-Reihenfolge: Zwang > Überschreiben (setChannel / Dashboard) > Konfiguration defaultChannel > Cloud Standard.

Verwenden defaultChannel nur in Test-/Internen Builds; lassen Sie es für die Produktion aus, damit die Benutzer die Cloud-Standard (wenn gesetzt) anstelle der Duplizierung der Routen in der native Konfiguration folgen.

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

Kanalnamen 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 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 Routingszenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
• Deaktivieren Sie die automatische Downgrade unter native: Verhindert die Übermittlung einer Aktualisierung, wenn die Geräte-App-Version neuere ist als die Kanal-Bundle (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Zulassen Sie Entwicklungsbuilds: Ermöglichen Sie Updates für Entwicklungsbuilds (nützlich für die Testung).
• Zulassen Sie Emulatordaten: Ermöglichen Sie Updates für Emulatoren/Simulator (nützlich für die Testung).
• Zulassen Sie die Selbstzuweisung des Geräts: Lassen Sie die App zu diesem Kanal umschalten, wenn setChannel Wenn deaktiviert, setChannel funktioniert nicht für diesen Kanal.

Deaktivieren Sie die Auto-Update-Strategien

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

• major: Blocken Updates zwischen verschiedenen Hauptversionen (0.0.0 → 1.0.0). Kleine und Patches-Updates sind weiterhin erlaubt.
• minor: Blocken Updates zwischen verschiedenen Minor-Versionen (z.B. 1.1.0 → 1.2.0) und Hauptversionen. Patches-Updates sind weiterhin erlaubt. Hinweis: Blockt nicht 0.1.0 → 1.1.0.
• patch: Sehr streng. Erstellt nur Patches-Updates, die innerhalb der gleichen Haupt- und Minor-Version erhöht werden. Beispiele: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata: Erfordert eine Mindestversion von Update-Metadaten in jedem Bundle. Konfigurieren Sie dies über CLI mit oder . Wenn fehlend, wird der Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis dies gesetzt ist. --min-update-version none: Erlaubt alle Updates entsprechend semver-Kompatibilität. --auto-min-update-versionErhalten Sie weitere Details und Beispiele in Disable updates strategy unter /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy.
• Beispiel (__CAPGO_KEEP_0__):

Learn more details and examples in Disable updates strategy at /docs/cli/commands/#disable-updates-strategy.

Example (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

__CAPGO_KEEP_0__

Der setChannel() Methode ermöglicht es Ihrer App, den Kanal programmatisch bei Laufzeit 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-Flüsse
• Feature-Flag-Implementierungen
• Szenarien für A/B-Tests

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 (lesend): Ein Anfrage wird an den Capgo-Backend gesendet, um zu überprüfen, ob der Kanal zugelassen ist (Überprüfung der Selbstzuweisungsrechte)
2. Lokales Speicher aktualisieren: Wenn die Validierung erfolgreich ist, wird der Kanal im Gerätespeicher gespeichert als defaultChannel
3. Echtzeit-Effekt: Die nächste Aktualisierungskontrolle verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Warum das wichtig ist: In älteren Versionen setChannel() speicherte 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 vom Backend (für die Validierung) und speichert lokal, was den Kanal-Wechsel sofort wirksam macht.

Sicherheitshinweis: Even if a channel’s permissions change after being set locally (e.g., self-assignment is disabled), the backend will still validate the channel during update checks, ensuring security is maintained.

Vergleich der Methoden zur Änderung des Kanals:

Methode	Wirkdauer	Gespeichert in	Verwendungszweck
setChannel() aus Plugin	Echtzeit	Geräteseitig (lokale)	Benutzerinitiierte Kanalwechsel innerhalb der App
Übernahme durch das Gerätedashboard	Bis zu 2 Minuten	Hintergrund-Datenbank	Administrativ initiierte Änderungen für bestimmte Geräte
API-Kanalzuweisung	bis zu 2 Minuten	Hintergrund-Datenbank	Automatisierte Hintergrundintegrationen

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

5.4.0 oder 6.2.0 5.34.0, 6.34.0, 7.34.0(abhängig von Ihrer Hauptversion). Jeder Minor-Version-Nummer entspricht demselben 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 8.0.0 Plugin-Installation für Versions-Labels. plugin installation for version tags

Ein Bundle zu einem 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 zu Kanälen aus der „Bundles“-Sektion des Capgo-Dashboards zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie „Zu 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 an mehrere Kanäle zugewiesen werden.

Bei der Versionsnummerierung Ihrer Bundles empfehlen wir die Verwendung von semantischen Versionsnummern semver mit Voreinstellungen für Vorabversionen für Kanal-spezifische 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 Versionsnummern über Kanäle hinweg, was Verwirrung reduziert.
• Es ermöglicht klare Rückschrittspfade. 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 Kanal-Konfiguration 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.

Die Verwendung von semver mit Präfix-Identifikatoren ist eine empfohlene Vorgehensweise, aber nicht strikt erforderlich. Das Wesentliche ist, eine Versionsverwaltung zu finden, die die Beziehungen zwischen Ihren Builds klar kommuniziert und mit Ihrem Teams Entwicklungsprozess übereinstimmt.

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-Übersicht:

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 die Krone-Schaltfläche
3. Bestätigen Sie die Aktion

Die ausgewählte Build wird sofort wieder die 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.

Zurücksetzen auf ein Gerät

Da Sie nun die Kanäle verstehen, sind Sie 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 zuzuhören
3. Hochladen Sie eine Build und zuweisen Sie sie diesem Kanal
4. Starten Sie die App und warten Sie auf die Aktualisierung!

Für eine detailliertere Anleitung, sehen Sie sich das Live-Updates bereitstellen Richtlinie an. 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:

• Funktionsschalter für verschiedene Benutzerstufen
• A/B-Test
• Schrittweise Einführung neuer Funktionen
• Beta-Testprogramme

Erfahren Sie, wie Sie diese komplexen Anwendungsfälle in unserer Anleitung umsetzen: Wie Benutzer nach Tarif und Kanälen segmentieren und Feature-Flags und A/B-Tests durchführen.