Kanäle

Ein Live Update Channel verweist auf einen spezifischen JS-Bundle-Build deiner App, der an alle Geräte verteilt wird, die so konfiguriert sind, dass sie auf Updates für diesen Channel hören. Wenn du installiere das Capgo Live Updates SDK In deiner App prüft jede native Binary, die für diesen Channel konfiguriert ist, beim App-Start auf verfügbare Updates. Du kannst den Build, auf den ein Channel zeigt, jederzeit ändern und bei Bedarf auch auf vorherige Builds zurückrollen.

Channels in Aktion

Betrachte einen Channel als einen benannten Pointer auf ein Update: production kann deine Release-App ausliefern, während es beta Tester bedient. Diese drei kurzen Videos zeigen, wie ein Gerät einem Channel zugewiesen wird. Sie haben optionale Hintergrundmusik ohne Voiceover; die Erklärungen unten beschreiben dieselben Schritte.

1. Den Default-Channel nutzen

Ein Gerät, das gerade v1.1.0 fragt Capgo nach einem Update. Ohne Device-Assignment oder App-konfigurierten Channel prüft Capgo den Cloud-Default, production, und gibt dessen v1.2.0 Bundle. Das dev und staging Channel behalten ihre eigenen Bundles, ohne dieses Gerät zu beeinflussen.

Video zum Standard-Channel herunterladen (MP4).

Setze deinen Production-Default in App-Informationen. Normale Production-Builds können defaultChannel leer lassen, damit du das Routing über Capgo verwalten kannst.

2. Einem Gerät einen Channel zuweisen

Diese Anleitung nutzt setChannel() und unsetChannel() von @capgo/capacitor-updater auf Android und iOS; diese Methoden werden im Browser nicht unterstützt. Sie nutzt das local-channel-Verhalten von updater 5.34.0+, 6.34.0+, 7.34.0+, oder 8.0.0+ für die Major-Version deines Plugins. Ältere Versionen schrieben stattdessen ein Backend-Override; diese Zuweisungen folgen den Console- und API-Aufbewahrungsregeln für Overrides.

Ein Tester aktiviert Beta-Updates in deiner App. Deine App ruft CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true }). Capgo prüft, ob beta die Device Self-Assignment zulässt, dann speichert das Plugin die Auswahl lokal für zukünftige Update-Checks. Andere Geräte behalten ihr bestehendes Routing.

Video zur Geräte-Selbstzuweisung herunterladen (MP4).

Aktivieren Sie Geräten erlauben, sich selbst zu trennen/verbinden auf dem Zielkanal, bevor sie genutzt werden setChannel(). Diese lokale Auswahl führt zu keiner Überschreibung in der Konsole. Auf Android und iOS mit dem Updater 8.51.0 oder neuer, persistDefaultChannelOnReinstall standardmäßig auf true, bleibt die Wahl nur bei einer Neuinstallation erhalten, wenn das Betriebssystem die App-Daten wiederherstellt, und persistDefaultChannelOnReinstall bleibt true. Rufe unsetChannel() die lokale Wahl zu löschen; Console- und API Overrides folgen weiterhin der untenstehenden Priorität.

3. Ein Gerät über die Console zuweisen

Öffne in der Capgo Console Apps, wähle deine App, öffne Geräteund wähle ein Gerät. Ändere den Channel-Überschreibung zu dev. Capgo leitet das Gerät nun auf devum, während der Cloud-Standard der App production.

Video zum Console Device Override herunterladen (MP4).

Nutze Overrides für gezieltes Testing oder Support. Diese haben Vorrang vor dem lokalen Device-Channel und dem Cloud-Default, sofern kein Forced Mapping vorliegt. Console- und API Overrides laufen 90 Tage nach dem letzten Override-Schreibvorgang ab.

Bereit zum Ausprobieren? Erstelle einen Channel in der Console, dann lade ein Bundle hoch damit dieser ausgeliefert werden kann.

Channels bieten keine Vertraulichkeit

Channels steuern die Berechtigung für Updates, nicht die Geheimhaltung von Bundles. Selbst wenn ein Channel privat ist oder Self-Assignment deaktiviert wurde, sollte jedes unverschlüsselte Bundle, das an Capgo hochgeladen wird, als öffentliches Asset behandelt werden. Verschlüsselung schützt den Delivery-Pfad und die Authentizität der Updates, aber Bundles können mit ausreichend Aufwand aus der verteilten App zurückentwickelt werden, da der Public Key Teil des Clients ist. Siehe Live Update Verschlüsselung für Details.

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

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

1. Erzwungenes Device-Mapping (Dashboard) – Manuelles Pinning einer spezifischen Device ID auf einen Channel. Ideal für dringendes Debugging oder kontrollierte Tests mit einem echten User. Dies hat immer Vorrang. Capgo entfernt das Mapping 90 Tage nach dem letzten Override. Console- und API Overrides laufen nach 90 Tagen ab.
2. Cloud-Override (pro Gerät) via Dashboard oder API – Wird erstellt, wenn du den Channel des Geräts im Dashboard oder via API änderst. Nutze dies für QA-User, die zwischen Feature- oder PR-Channels wechseln, oder um User-Issues zu reproduzieren. Eine Neuinstallation der Binary löscht dies nicht; das Löschen des Device-Overrides hingegen schon. Es gilt dieselbe 90-Tage-Frist.
3. Plugin setChannel() lokaler Channel – Wird erstellt, wenn die App aufruft setChannel() und das Backend validiert, dass der Ziel-Channel eine Selbstzuweisung erlaubt. Der gewählte Channel wird lokal auf dem Gerät gespeichert, wirkt sofort und wird nicht in der Device Override UI angezeigt.

Sofortiges Channel-Switching mit setChannel()

Ab Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von deiner Major-Version), setChannel() funktioniert anders: Es kontaktiert das Backend, um zu validieren, ob der Channel erlaubt ist (Prüfung, ob Self-Assignment für diesen Channel aktiv ist), und speichert den Channel dann lokal auf dem Gerät als defaultChannel. Das bedeutet, der neue Channel wird sofort beim nächsten Update-Check aktiv – ohne auf die Replikation zu warten.

Bisher wurde setChannel() der Channel-Override in der Backend-Datenbank gespeichert (wie bei Dashboard- oder API Änderungen), und Geräte mussten auf die Datenreplikation warten (bis zu 2 Minuten), bevor der neue Channel erkannt wurde. Das neue Verhalten liest nur vom Backend (zur Validierung) und speichert lokal, wodurch Channel-Wechsel sofort erfolgen.

Da setChannel() nur lokal arbeitet, wird es nicht keinen Device Override-Eintrag im Capgo Dashboard erstellen. Die Device Override UI zeigt nur Overrides an, die über das Dashboard oder den öffentlichen API erstellt wurden.

Hinweis: Selbst wenn ein Channel nach der lokalen Einstellung nicht mehr erlaubt ist, validiert das Backend den Channel weiterhin bei Update-Checks, sodass die Sicherheit gewährleistet bleibt.

Wichtig: Wenn Channel-Änderungen über das Dashboard oder API vorgenommen werden, gibt es weiterhin eine Replikationsverzögerung von bis zu 2 Minuten, bis alle Edge-Server die Änderung übernehmen. Für sofortige Channel-Wechsel nutze setChannel() über dein App code — dies validiert mit dem Backend und setzt den Channel dann lokal für eine sofortige Wirkung.

4. Capacitor Konfiguration defaultChannel (Standard für Test-Builds) – Falls vorhanden in capacitor.config.* und kein Force-/Override-/Local-Channel existiert, startet die App auf diesem Channel (z. B. beta, qa, pr-123). Dient für TestFlight / interne Builds, damit Tester automatisch auf einem Pre-Release-Channel landen. Production-Builds lassen diesen Wert meist ungesetzt.
5. Cloud Default Channel (Primärpfad für ~99 % der Nutzer) – Wenn du im Dashboard einen Default-Channel festlegst, verbinden sich alle normalen Endnutzer (ohne Force, ohne Dashboard/API Override, ohne Plugin Local-Channel, ohne config defaultChannel) hier. Ändere ihn für sofortige Rollouts oder Rollbacks – ohne neues Binary. Bei plattformspezifischen Defaults (z. B. einer für iOS, eine für Android, eine für Electron) landet jedes Gerät auf dem passenden Default für seine Plattform. Den Cloud Default ungesetzt zu lassen ist erlaubt; in diesem Fall müssen die Schritte 1–4 übereinstimmen, damit das Gerät Updates erhält.

Best Practice:

• Betrachte 1–4 als Ausnahme- / Test-Layer; wenn du einen Cloud Default setzt, sollten echte Nutzer darauf landen. Wenn du keinen setzt, plane genau, wie Nutzer sich verbinden (typischerweise über defaultChannel in der Config oder per Device-Override).
• Konfiguriere defaultChannel nur in Binaries, die du explizit an Tester auslieferst. Ungesetzt zu lassen hält die Production-Logik zentral im Dashboard.
• Nutze setChannel() sparsam in Produktion einsetzen – vor allem für QA oder gezielte Diagnosen.

Wenn ein Channel für die Plattform (iOS/Android/Electron-Toggles) deaktiviert ist, obwohl er sonst ausgewählt würde, überspringt der Auswahlprozess ihn und fährt mit der Liste fort.

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

Console- und API Overrides laufen nach 90 Tagen ab

Forced Mappings sowie Channel-Overrides über Dashboard oder Public API werden als gerätespezifische Zuweisungen in Capgo gespeichert. Ein Cleanup-Job löscht diese Zuweisungen 90 Tage nach dem letzten Override-Schreibvorgang. Das Abrufen eines Updates setzt diesen Timer nicht zurück. Nur ein erneutes Schreiben des Overrides (oder das manuelle Löschen) aktualisiert den Zeitstempel.

Das ist nicht dasselbe wie die Aufbewahrungsfrist der Device Inventory. Das Inventory entfernt Geräte, die sich seit 90 Tagen nicht bei Capgo gemeldet haben. Ein Override-Cleanup entfernt das Mapping auch dann, wenn das Gerät noch aktiv ist.

Für eine Zuweisung, die durch diesen Cleanup nicht entfernt wird:

• Setze defaultChannel in capacitor.config.* (übersteht Neuinstallation; erfordert später ein neues Native Build).
• Rufe setChannel() aus der App. Ab Plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 wird diese Zuweisung lokal gespeichert und nicht durch diesen Cleanup entfernt. Auf Android und iOS mit Updater 8.51.0 oder neuer persistDefaultChannelOnReinstall standardmäßig auf true, sodass die Zuweisung eine Neuinstallation nur übersteht, wenn das Betriebssystem die App-Daten wiederherstellt und persistDefaultChannelOnReinstall bleibt true. Nutze unsetChannel() , um sie explizit zu löschen.

Der Channel Geräte Tab und die Device Override UI listen nur Console- und Public API Assignments auf. Sie listen nicht jedes Gerät des Channels auf und zeigen keine lokalen setChannel() Assignments an.

Override Retention Hinweis im Channel Devices Tab.

Standard Channel Verhalten

Ein Cloud-Default ist optional, dient aber meist als Catch-all-Pfad für neue Geräte. Ohne Default erhalten nur Geräte Updates, die auf Forced Mappings, Overrides oder eine defaultChannel Konfiguration in der Capacitor config passen. Wenn du Defaults festlegst, beachte diese Muster:

• Einzelner Default (am häufigsten) – Wenn ein Channel iOS, Android und Electron aktiviert hat, wird dies zum einzigen Default; alle Geräte ohne Overrides werden hier angehängt.
• Plattformspezifische Defaults – Wenn du Channels nach Plattformen trennst (zum Beispiel, ios-production nur iOS aktiviert, android-production nur Android aktiviert und electron-production nur Electron aktiviert), markiere jeden als Default für seine Plattform. iOS-Geräte nutzen den iOS-Default, Android-Geräte den Android-Default und Electron-Apps den Electron-Default.

Beachte, dass der Cloud-Default und defaultChannel in capacitor.config.* beide befinden sich auf derselben Entscheidungsebene. Wenn du einen Cloud-Standard festlegst, musst du den Wert nicht in deiner Capacitor Konfiguration duplizieren – lass ihn einfach defaultChannel für Production-Builds leer. Nutze defaultChannel für Binaries, die du gezielt an Tester oder QA auslieferst, damit diese auf einem Non-Production-Channel starten, selbst wenn der Cloud-Default anders ist.

Du kannst Defaults jederzeit im Dashboard ändern. Öffne den Channel, dann In den App-Einstellungen verwalten, das dich weiterleitet zu App-Informationen. Der Standard ist kein Toggle mehr auf der Channel-Seite. Wenn du den Standard änderst, folgen neue Geräte sofort dem neuen Routing, während bestehende Geräte bei ihrem nächsten Check-in den normalen Prioritätsregeln folgen.

Einen Channel einrichten

Während des Onboardings erstellst du den ersten Channel (die meisten Teams nennen ihn „Production“), aber nichts ist fixiert – du kannst jeden Channel jederzeit umbenennen oder löschen. Um später weitere Channels hinzuzufügen:

1. Gehe zum Bereich „Channels“ im Capgo Dashboard
2. Klicke auf den Button „New Channel“
3. Gib einen Namen für den Channel ein und klicke auf „Create“

Channel-Namen können frei gewählt werden. Eine gängige Strategie ist es, die Channels an deine Entwicklungsphasen anzupassen, wie zum Beispiel:

• Development - zum Testen von Live Updates auf lokalen Geräten oder Emulatoren
• QA - für dein QA-Team, um Updates vor dem breiten Release zu verifizieren
• Staging - für finale Tests in einer produktionsnahen Umgebung
• Production - für die Version deiner App, die Endnutzer aus den App Stores erhalten

Den Channel in deiner App konfigurieren

Nachdem du deine Channels erstellt hast, musst du deine App so konfigurieren, dass sie auf den richtigen Channel hört. In diesem Beispiel nutzen wir den Development Channel.

Öffne deine capacitor.config.ts (oder capacitor.config.json) Datei. Unter dem plugins Bereich kannst du optional defaultChannel für Test-Builds (intern / QA). Für Production-Builds sollte es weggelassen werden, damit Geräte den Cloud Default nutzen, sofern nichts anderes festgelegt ist.

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.
    },
  },
};

Baue als Nächstes deine Web-App und führe npx cap sync aus, um die aktualisierte Config-Datei in deine iOS-, Android- und Electron-Projekte zu kopieren. Wenn du diesen Sync-Schritt überspringst, nutzen deine nativen Projekte weiterhin den zuvor konfigurierten Channel.

Achtung

Reihenfolge der Channel-Auswahl: Force > Dashboard/API Device Override > Plugin setChannel() lokaler Channel > Config defaultChannel > Cloud-Standard.

Nutze defaultChannel nur in Test-/Internal-Builds; lass es in der Production weg, damit Nutzer dem Cloud Default folgen (falls gesetzt), statt das Routing in der nativen Config zu duplizieren.

Du kannst ein Gerät trotzdem erzwingen (pinnen) oder später einen Override anwenden – diese überschreiben den Config-Wert sofort.

Channel-Namen sind case-sensitive.

Channel-Optionen und Strategien

Channels bieten verschiedene Optionen, um zu steuern, wer Updates erhält und wie diese ausgeliefert werden. Die wichtigsten sind unten aufgeführt. Du kannst diese über die Web-App, das CLI oder die öffentliche API konfigurieren.

• Standard-Channel: Optional kannst du den Channel oder plattformspezifische Channels festlegen, an die sich neue Geräte verbinden. In der Console findest du dies unter App Information (In den App-Einstellungen verwalten auf der Channel-Seite). Details zu Routing-Szenarien findest du unter „Default Channel Behavior“.
• Platform filters: Enable or disable delivery to iOS, Android, oder Electron Geräte pro Channel.
• Auto-Downgrade unter Native deaktivieren: Verhindert das Senden eines Updates, wenn die native App-Version des Geräts neuer ist als das Bundle des Channels (z. B. Gerät auf 1.2.3, während der Channel 1.2.2 hat).
• Development Builds erlauben: Updates für Development Builds zulassen (praktisch zum Testen). CLI: --dev / --no-dev.
• Production-Builds zulassen: Erlaubt Updates für Production-Builds (Store). Aktivieren Sie dies für Channels, die echte Nutzer bedienen. CLI: --prod / --no-prod.
• Emulator erlauben: Updates für Emulatoren/Simulatoren zulassen (ideal zum Testen). CLI: --emulator / --no-emulator.
• Physische Geräte erlauben: Updates für echte Smartphones und Tablets zulassen. Für Production-Kanäle aktiviert lassen. CLI: --device / --no-device.
• Device Self-Assignment erlauben: Ermöglicht der App, zur Laufzeit mithilfe von setChannel. Wenn deaktiviert, setChannel schlägt der Vorgang für diesen Kanal fehl. CLI: --self-assign / --no-self-assign.
• Download-Format: Wählen Sie, ob Geräte ein vollständiges ZIP, nur die geänderten Delta-Dateien oder die beste Kombination laden (all, zip, delta, zip_from_builtin, delta_from_builtin). Siehe Download-Format für das Dropdown im Console-Dashboard und wann welcher Modus sinnvoll ist.

Progressive Rollouts

Ein Channel kann ein stabiles Bundle bereitstellen, während er schrittweise ein separates Rollout-Target für eine feste Gerätegruppe freigibt. Du kannst pausieren, fortsetzen, promoten, zurückrollen und eine automatische Fehlerreaktion konfigurieren, ohne den Channel für alle zu ändern. Siehe Progressive Rollouts für das Delivery-Modell, den Dashboard-Workflow, API Felder und CLI Befehle.

Auto-Update-Strategien deaktivieren

Nutze dies, um einzuschränken, welche Arten von Updates der Channel automatisch ausliefert. Optionen:

• major: Blockiert ein Target-Bundle, dessen Major-Version höher ist als die native Baseline des Geräts (version_build). Beispiel: 1.2.3 -> 2.0.0 wird blockiert; 1.2.3 -> 1.9.0 ist erlaubt.
• minor: Blockiert ein Target-Bundle, dessen Major- oder Minor-Version von version_build. Beispiel: 1.2.3 -> 1.3.0 ist blockiert; 1.2.3 -> 1.2.4 ist erlaubt.
• patch: Strengster Modus. Blockiert jede Änderung der Major-, Minor- oder Patch-Nummer. Nur Suffix-Änderungen sind erlaubt, während MAJOR.MINOR.PATCH identisch bleibt. Beispiele: 1.0.0-beta.1 -> 1.0.0-beta.2 ist erlaubt, 1.0.0+build.1 -> 1.0.0+build.2 ist erlaubt, 1.0.0 -> 1.0.1 ist blockiert.
• metadata: Erfordert ein Minimum an Update-Version-Metadaten pro Bundle. Konfiguration via CLI mit --min-update-version oder --auto-min-update-version. Falls dieser fehlt, wird der Channel als fehlerhaft markiert und Updates werden abgelehnt, bis er konfiguriert ist.
• none: Allow all updates according to semver-Kompatibilität erlauben.

Diese Strategien vergleichen das Ziel-Bundle des Channels mit dem nativen Baseline-Bundle, das als version_build, nicht mit dem aktuell heruntergeladenen Bundle, das als version_name.

Weitere Details und Beispiele findest du unter Disable updates strategy in /docs/cli/commands/#disable-updates-strategy.

Beispiel (CLI). Der Channel 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

Verwendung von setChannel() in deiner App

Die @capgo/capacitor-updater Methode setChannel() ermöglicht es deiner Android- oder iOS-App, Channels zur Laufzeit programmatisch zu wechseln. Das ist besonders nützlich für:

• QA/Debug-Menüs zum Wechseln der Channels durch Tester
• Opt-in-Flows für Beta-Programme
• Implementierungen von Feature Flags
• A/B-Testing-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
});

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

Wann setChannel() wird aufgerufen:

1. Backend-Validierung (read-only): Eine Anfrage wird an das Capgo Backend gesendet, um die Berechtigung des Channels zu prüfen (Self-Assignment-Permissions)
2. Update des Local Storage: Wenn die Validierung erfolgreich ist, wird der Channel im lokalen Speicher des Geräts als gespeichert: defaultChannel
3. Sofortige Wirkung: Der nächste Update-Check nutzt den neuen Channel sofort (kein Warten auf Replikation)

Warum das wichtig ist: In älteren Versionen setChannel() wurde der Channel-Override in der Backend-Datenbank gespeichert (wie bei Änderungen im Dashboard oder via API). Geräte mussten auf die Backend-Replikation warten (bis zu 2 Minuten), bevor der Channel-Wechsel wirksam wurde. Jetzt setChannel() liest nur vom Backend (zur Validierung) und speichert lokal, wodurch Channel-Wechsel sofort erfolgen.

Sichtbarkeit im Dashboard: Ein via Plugin gesetzter Channel führt nicht dazu, dass das Gerät als Device Override in der Capgo UI erscheint. Dort werden nur Channel-Zuweisungen gelistet, die über das Dashboard oder die öffentliche API erstellt wurden. Nutze das Dashboard oder API, wenn du einen für Admins sichtbaren Override benötigst.

Sicherheitshinweis: Selbst wenn sich die Berechtigungen eines Channels nach der lokalen Setzung ändern (z. B. wenn Self-Assignment deaktiviert wird), validiert das Backend den Channel weiterhin bei den Update-Checks, um die Sicherheit zu gewährleisten.

Vergleich der Methoden zum Channel-Wechsel:

Methode	Effektzeit	Speicherort	In Device Override UI sichtbar	Läuft ab	Anwendungsfall
setChannel() vom Plugin	Sofort	Nur Gerät (lokal)	Nein	Kein automatisches Ablaufdatum; löschen mit unsetChannel() (Neuinstallation kann es erhalten)	In-App-Channelwechsel durch User
Dashboard Device Override	Bis zu 2 Min.	Backend-Datenbank	Ja	90 Tage nach letztem Override	Admin-gesteuerte Änderungen für Geräte
API Channel-Zuweisung	Bis zu 2 Min.	Backend-Datenbank	Ja	90 Tage nach letztem Override	Automatisierte Backend-Integrationen

Für die beste User Experience beim Bauen von UIs zum Kanalwechsel nutze immer die des Plugins setChannel() Methode.

Mindestversionen für lokales Kanalwechseln: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 (abhängig von deiner Major-Version). Jede Minor-Versionsnummer entspricht dem gleichen Feature-Set über alle Major-Versionen hinweg (z. B. enthält X.34.0 dieselben Features, egal ob X 5, 6, 7 oder 8 ist). Siehe Plugin-Installation für Version-Tags.

Ein Bundle einem Channel zuweisen

Um ein live update bereitzustellen, musst du einen neuen JS-Bundle-Build hochladen und ihn einem Channel zuweisen. Das geht in einem Schritt mit dem Capgo CLI:

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

Damit werden deine Web-Assets hochgeladen und das neue Bundle als aktiver Build für den Development Channel. Alle Apps, die so konfiguriert sind, dass sie auf dieses Channel hören, erhalten das Update beim nächsten Check.

Du kannst Builds auch im Bereich „Bundles“ im Capgo Dashboard Channels zuweisen. Klicke auf das Menü-Icon neben einem Build und wähle „Assign to Channel“, um den passenden Channel auszuwählen.

Bundle-Versioning und Channels

Wichtig zu wissen: Bundles in Capgo sind global für deine App und nicht an einzelne Channels gebunden. Dasselbe Bundle kann mehreren Channels zugewiesen werden.

Für das Versioning deiner Bundles empfehlen wir Semantic Versioning mit dem Capgo Semver Tester und Pre-Release-Identifikatoren für channel-spezifische Builds. Ein Beta-Release könnte zum Beispiel so versioniert werden: 1.2.3-beta.1.

In der CI: Falls die lokale Version bereits hochgeladen wurde, verwende npx @capgo/cli@latest bundle upload --auto-bump (optional major, minor, patch/fix, metadata, oder ai) damit CLI aus dem mit dem Channel verknüpften Bundle hochgestuft wird, bis ein freier Name gefunden wird. Mit ai, leitet Workers AI die Ebene aus dem Delta-Manifest (lokal vs. vorherig) ab (Fallback auf patch ohne vorherige Capgo Version). Es kann nicht kombiniert werden mit --bundle. Siehe CI/CD-Integration und der CLI Referenz.

Dieser Ansatz bietet mehrere Vorteile:

• Er stellt die Beziehung zwischen den Builds klar dar. 1.2.3-beta.1 ist offensichtlich ein Pre-Release von 1.2.3.
• Es ermöglicht die Wiederverwendung von Versionsnummern über Channels hinweg, was Verwirrung reduziert.
• It enables clear rollback paths. If you need to roll back from 1.2.3weißt du, 1.2.2 ist das vorherige stabile Release.

Hier ist ein Beispiel, wie du deine Bundle-Versionen mit einem typischen Channel-Setup abstimmen kannst:

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

Verwendung SemVer mit Pre-Release-Identifiern ist ein empfohlener Ansatz, aber nicht zwingend erforderlich. Wichtig ist ein Versionierungsschema, das die Beziehungen zwischen deinen Builds klar kommuniziert und zu deinem Team-Workflow passt.

Rollback eines Live Update

Wenn du einen live update deployst, der einen Bug enthält oder anderweitig zurückgesetzt werden muss, kannst du einfach zu einem vorherigen Build zurückrollen. Im Dashboard unter „Channels“:

1. Klicke auf den Namen des Channels, den du zurückrollen möchtest
2. Finde den Build, zu dem du zurückkehren möchtest, und klicke auf das Kronen-Icon
3. Aktion bestätigen

Der ausgewählte Build wird sofort wieder zum aktiven Build für diesen Channel. Apps erhalten die zurückgerollte Version beim nächsten Update-Check.

Deployments automatisieren

Für fortgeschrittene Workflows kannst du deine live update Deployments als Teil deiner CI/CD-Pipeline automatisieren. Durch die Integration von Capgo in deinen Build-Prozess kannst du neue Bundles automatisch hochladen und ihnen Channels zuweisen, sobald du in bestimmte Branches pushst oder neue Releases erstellst.

Schau dir die CI/CD-Integration Docs an, um mehr über die Automatisierung von Capgo Live Updates zu erfahren.

Least-privilege PR Previews

Verwende einen App-Vorschau API Key, wenn die CI pro Pull Request einen temporären Channel benötigt, aber keine bestehenden Main/Default-Channels verwalten darf. Der Key bleibt an die jeweilige Organisation und die ausgewählte App gebunden; er hat lediglich keine organisationsweite Rolle. Jeder nicht öffentliche Preview-Channel, den er anlegt, erhält eine eigene, automatisch auf den Channel begrenzte Lifecycle-Berechtigung.

1. Lass einen Administrator der Organisation einen sicheren API Key erstellen, der auf die Preview-App beschränkt ist, und wähle App-Vorschau. Siehe API Schlüssel.
2. Use a unique, non-public channel such as pr-123. Geben Sie nicht --default, --self-assign, Rollout-Optionen oder --delete-linked-bundle-on-upload.
3. Lade das PR-Bundle mit einem Befehl hoch und promote es, um den zugehörigen Channel und das Bundle nach dem Schließen des PRs automatisch zu löschen:

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 den fehlenden Channel, lädt das Bundle hoch und promotet es in einem Durchgang. Das Cleanup erfolgt atomar und mit Ownership-Check: Ein Key kann nur den Channel und das verknüpfte, nicht geteilte Bundle löschen, das er selbst erstellt hat. Er kann keinen bestehenden Main/Default-Channel, den Channel eines anderen Preview-Keys oder das Bundle eines anderen Keys ändern, promoten oder löschen.

Wenn Reviewer einen QR code oder eine Preview-URL benötigen, muss ein Administrator die Previews einmalig 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 Preview Key kann keine Previews selbst aktivieren, da er keine Berechtigung für App-Einstellungen hat. Führe in GitHub Actions Preview-Jobs mit Secrets auf pull_request, nicht pull_request_target, und beschränke sie auf PRs im selben Repository mit github.event.pull_request.head.repo.full_name == github.repository.

Deployment auf ein Gerät

Nachdem du Channels verstanden hast, kannst du mit dem Deployment von Live Updates auf echte Geräte beginnen. Der Prozess sieht so aus:

1. Installiere das Capgo SDK in deiner App
2. Konfiguriere die App so, dass sie auf deinen gewünschten Channel hört
3. Lade einen Build hoch und weise ihn diesem Channel zu
4. Starte die App und warte auf das Update!

Für eine detaillierte Anleitung schau dir die Live Updates Deployment Guide. Viel Spaß beim Updaten!

Erweiterte Channel-Nutzung: User-Segmentierung

Channels können für mehr als nur Entwicklungsphasen genutzt werden. Sie sind ein mächtiges Tool für die User-Segmentierung und ermöglichen Features wie:

• Feature Flags für verschiedene User-Tiers
• A/B-Testing
• Schrittweise Feature-Rollouts
• Beta-Testprogramme

Erfahre in unserem Guide, wie du diese fortgeschrittenen Use Cases implementierst: Nutzer nach Plan und Channels segmentieren für Feature Flags und A/B-Testing.

Weiterlesen zu Channels

Wenn du es nutzt Channels um Channel-Routing und Staged Rollouts zu planen, verbinde es mit Channels für Details zur Implementierung in Channels, Channels für Details zur Implementierung in Channels, Beta-Testing-Lösung für den Produkt-Workflow in der Beta-Testing-Lösung, Version-Targeting-Lösung für den Produkt-Workflow in der Version-Targeting-Lösung, und Capgo Environment Best Practices: Staging mit einer Mobile App ID für den praktischen Kontext in Capgo Best Practices für die Umgebung: Staging mit einer einzigen Mobile App ID.