Kanäle

Eine Live-Update-Kanäle verweist auf eine bestimmte JS-Bundle-Build Ihres Apps, die mit allen Geräten konfiguriert ist, um auf diese Kanäle für 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 sich ein Kanal bezieht, jederzeit ändern und auch auf vorherige Builds zurückrollen, wenn erforderlich.

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 Clients geliefert wird. Die Verschlüsselung schützt den Transportweg und die Authentizität der Updates, aber verschiffte Pakete können immer noch umgekehrt entwickelt werden, wenn genügend Anstrengung aufgewendet wird, 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 einer Aktualisierung sucht, entscheidet Capgo in dieser strengen Reihenfolge (höchste Priorität zuerst), welchen Kanal zu verwenden ist:

1. Zwangslaufgerstellung (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 Console und API-Überprüfungen verfallen nach 90 Tagen.
2. Cloud-Überprüfung (pro Gerät) via Dashboard oder API – Erstellt, wenn Sie den Kanal des Geräts im Dashboard oder über API ändern. Verwenden Sie dies für QA-Benutzer, die zwischen Feature- / PR-Kanälen wechseln oder um ein Benutzerproblem nachzustellen. Eine erneute Installation des Binärs löscht es nicht; die Löschung der Geräte-Überprüfung tut es. Die gleiche 90-Tage-Rückhalteregelung gilt.
3. Plugin setChannel() lokaler Kanal – Erstellt, wenn die App aufgerufen wird 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.

Instantaner Kanalwechsel mit setChannel()

Ab Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion), setChannel() funktioniert anders: Es kontaktiert das Backend, um zu überprüfen dass der Kanal zugelassen ist (Überprüfung, ob die Selbstzuweisung für diesen Kanal aktiviert ist), dann wird der Kanal lokal auf dem Gerät gespeichert 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 macht.

Da setChannel() ist lokal nur, es erstellt 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 während der Aktualisierungskontrollen den Kanal noch immer validieren, sodass die Sicherheit gewährleistet ist.

Wichtig: Wenn Änderungen an den Kanälen über das Dashboard oder API vorgenommen werden, besteht nach einer Reproduktion von bis zu 2 Minuten ein Verzögerung, bevor alle Edge-Server die Änderung widerspiegeln. Für einen sofortigen Kanalwechsel 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/Übertragung/lokaler Kanal existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123Zielgruppe: Testflug/Innere Builds, damit Tester automatisch auf einem Vorkassenkanal landen. Produktionsbuilds lassen dies 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-Übertragung, kein Plugin-Lokalkanal, keine Konfiguration Standardkanal) hier angewiesen. Ä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 Schritt 1–4 erfüllen, um Updates zu erhalten.

Empfehlung:

• Behandeln Sie 1–4 als Ausnahmen/Testing Layers; wenn Sie einen Cloud-Standard setzen, sollten sich echte Benutzer in ihn einfließen. Wenn Sie keinen setzen, seien Sie bei der Zuweisung der Benutzer (typischerweise via 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 worden wäre, 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.

Console und API-Überschreibungen erlöschen nach 90 Tagen

Zwangszuweisungen 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 dem letzten Überschreibeschreiben. Überprüfen Sie, ob ein Update verfügbar ist, ohne die Uhr zu zurücksetzen. Nur das erneute Schreiben der Überschreibung (oder das Löschen durch Sie selbst) ändert den Timestamp.

This is not the same as Geräteinventar-Retention. Inventar entfernt Geräte, die sich seit 90 Tagen nicht mit Capgo verbunden haben. Die Überprüfung der Überschreibung entfernt die Zuordnung, selbst wenn das Gerät noch aktiv ist.

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

• Set defaultChannel in capacitor.config.* (überlebt eine Wiederinstallation; erfordert ein neues natives Binärdatei, um es später zu ändern).
• Aufrufen setChannel() context: Appflow-Migrationschritt 2 setChannel() aus der App. Ab 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 sie, daher muss die App erneut aufrufen, wenn Sie das Kanal noch haben möchten.

Der Kanal Geräte Kanal und das Geräte-Überschreibungs-UI nur Liste Konsole und öffentliche API Zuweisungen. Sie listen nicht alle Geräte auf dem Kanal und sie listen nicht lokale setChannel() Zuweisungen.

Überschreibungs-Hinweis auf dem Kanal Geräte-Tab.

Standardverhalten des Kanals

Die Festlegung eines Cloud-Standards ist optional, aber es dient normalerweise als Sammelweg für neue Geräte. Ohne einen solchen, erhalten nur Geräte, die sich an gezwungenen Zuweisungen, Überschreibungen oder einem defaultChannel Capacitor Konfigurationsmuster, Updates.

• Einziger Standard (am häufigsten) – Wenn ein Kanal iOS, Android und Electron aktiviert ist, wird er zum einzigen Standard; jedes Gerät ohne Überschreibungen wird hier hinzugefügt.
• Plattform-spezifische Standards – Wenn Sie Kanäle nach Plattformen aufteilen (z.B. nur iOS aktiviert, nur Android aktiviert und nur Electron aktiviert), markieren Sie jeden als Standard für seine Plattform. iOS-Geräte gehen zum iOS-Standard, Android-Geräte gehen zum Android-Standard und Electron-Anwendungen gehen zum 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 Platform-specific defaults defaultChannel – If you split channels by platform (for example,

with only iOS enabled, with only Android enabled, and , 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.

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 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 einen Namen für den Kanal ein 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 Ihren 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 Ihres Apps, die die Endnutzer von den App-Stores erhalten

Kanal konfigurieren 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 Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json)-Datei. Unter der plugins Abschnitt, 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 Web-Anwendung 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.

Die Namen der Kanäle 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, im CLI, oder im öffentlichen API konfigurieren.

• Standardkanal: Optional markieren Sie den Kanal oder die plattform-spezifischen Kanäle, die neue Geräte anbinden. Im Konsole lebt dies auf App-Informationen (In den App-Einstellungen verwalten vom Kanal-Seite aus). Siehe “Standardkanalverhalten” für Routingszenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Androidoder Electron Geräte pro Kanal.
• Automatische Downgrade unter native deaktivieren: Verhindert die Übermittlung eines Updates, wenn das Geräte-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).
• Entwicklerversionen zulassen: Ermöglichen Sie Updates für Entwicklerversionen (nützlich für Tests). CLI: --dev / --no-dev.
• Produktionsbuilds zulassen: Genehmigen Sie Updates für Produktionsbuilds (Laden). Lassen Sie dies an für Kanäle, die echte Benutzer bedienen. CLI: --prod / --no-prod.
• Emulatoren zulassen: Genehmigen Sie Updates für Emulatoren/Simulator (nützlich für die Testung). CLI: --emulator / --no-emulator.
• Physische Geräte zulassen: Genehmigen Sie Updates für echte Smartphones und Tablets. Lassen Sie dies an für Produktionskanäle. CLI: --device / --no-device.
• Geräte selbst zuweisen lassen: Lassen Sie die App während der Ausführung auf diesen Kanal wechseln, indem Sie setChannelbenutzen. Wenn dies deaktiviert ist, setChannel fehlschlägt für diesen Kanal. CLI: --self-assign / --no-self-assign.
• Update-Paket wählen: Wählen Sie, ob Geräte ein vollständiges Zip-Datei, eine Differenz der geänderten Dateien oder beide (all, zip, delta, zip_from_builtin, delta_from_builtin) herunterladen. Siehe Update-Paket für die Konsole und wenn jede Modus nützlich ist.

Fortschrittliche Rollouts

Aus einem Kanal kann ein stabiler Bundle beibehalten werden, während ein separater Rollout-Ziel für eine treue Gerätekohorte allmählich freigegeben wird. Sie können das Update aussetzen, wieder aufnehmen, vorziehen, zurückrollen und eine automatische Fehlerantwort konfigurieren, ohne den Kanal für alle zu ändern. 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-Bundle, 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-Bundle, 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 Patchnummer. 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: Erfordern Sie eine Mindestversion von Updates-Metadaten auf jedem Bundle. Konfigurieren Sie dies über CLI unter Verwendung von --min-update-version oder --auto-min-update-versionkeine: Allen Updates zulassen, gemäß
• kompatibel keine.

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

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

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

# 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

Mithilfe von 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-Flüsse
• 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() aufgerufen wird:

1. Hintergrundvalidierung (nur Lesen): Ein Anfrage wird an den Capgo Backend gesendet, um die Kanal zuzulassen (Überprüfung der Selbstzuweisungsrechte)
2. Speicherung in der lokalen Zwischenablage: Wenn die Validierung erfolgreich ist, wird der Kanal 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 die Kanal-Überschreibung im Backend-Datenbank (gleich wie Dashboard oder API Änderungen). Geräte mussten auf die 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 macht.

Dashboard-Ansicht: Eine mit dem Plugin gesetzte Kanal-Einstellung 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 sich die Berechtigungen eines Kanals nach der lokalen Einstellung ändern (z.B. Selbstzuweisung ist deaktiviert), wird der Backend die Kanalvalidierung während der Aktualisierungskontrollen durchführen, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanaländerungsverfahren:

Verfahren	Ereigniszeit	Persistiert in	Angezeigt in Geräte-Übernahme-UI	Abläuft	Anwendungsbereich
setChannel() von Plugin	Instant	Nur Gerät (lokal)	Nein	Nein (bis du es änderst oder neu installierst)	Benutzerinitiierte Kanalwechsel in-app
Übernahme-Geräte-Überwachung	bis zu 2 min	Hintergrund-Datenbank	Ja	90 Tage nach der letzten Überprüfung	Admin-gesteuerte Änderungen für bestimmte Geräte
API-Kanalzuweisung	bis zu 2 min	Hintergrund-Datenbank	Ja	90 Tage nach der letzten Überprüfung	Automatisierte Hintergrundintegrationen

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

Mindestversionen für die lokale Kanalwechsel: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 je nach Ihrer Hauptversion. Jeder Minor-Version-Nummer 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.

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 Web-Assets hochladen und das neue Bundle als aktives Build für das Development Kanal. Jeder App, die auf diesen Kanal eingestellt ist, erhält die Aktualisierung beim nächsten Mal, wenn sie nach einer aktualisiert.

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.

Bundle-Versionierung und Kanäle

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

Bei der Versionsnummerierung Ihrer Bundles empfehlen wir die Verwendung von semantischer Versionsnummerierung mit Capgo’s Semver-Tester und Prä-Release-Identifikatoren für kanal-spezifische Builds. Zum Beispiel könnte eine Beta-Version als 1.2.3-beta.1.

Bei der CI, wenn die lokale Version bereits hochgeladen war, verwenden Sie npx @capgo/cli@latest bundle upload --auto-bump (optional) major, minor, patch/fix, metadata, oder ai) so dass CLI bis zu einem freien Namen auf den Kanal des verknüpften Bundles springt. Mit ai, Workers AI bestimmt 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 mit --bundle. Siehe CI/CD-Integration und das CLI-Referenz.

Dieser Ansatz hat mehrere Vorteile:

• Es kommuniziert die Beziehung zwischen Builds klar. 1.2.3-beta.1 ist offensichtlich eine Vorschau von 1.2.3.
• Es ermöglicht die Wiederverwendung von Versionsnummern über Kanäle hinweg, was Verwirrung reduziert.
• Es ermöglicht klare Rückschritswege. Wenn Sie von 1.2.3zurückrollen müssen, 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ö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 Versionsierungsschablone 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 ein vorheriges Build zurückgreifen. Aus der „Kanäle“-Sektion der Dashboard-Übersicht:

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

Das ausgewählte Build wird sofort wieder der aktive Build für diesen Kanal. Apps erhalten die rückgängig gemachte 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 Bundles automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

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

Mindestberechtigte Pull-Request-Vorschau

Verwenden Sie ein App-Vorschau Eine API-Schlüssel, wenn CI eine temporäre Kanal pro Pull-Request benötigt, aber bestehende Haupt-/Standardkanäle nicht verwalten muss. Der Schlüssel bleibt der eigenen Organisation und dem ausgewählten App gebunden; er hat einfach keine Organisationsebene.

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-VorschauAnschauen Sie sich API-Schlüssel.
2. Verwenden Sie ein einzigartiges, nicht öffentliches Kanal wie pr-123Passen Sie nicht --default, --self-assign, Rollout-Optionen oder --delete-linked-bundle-on-upload.
3. Laden Sie das PR-Bundle hoch und fördern Sie es in einem Befehl, löschen Sie dann das Kanal und das Bundle, 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 Bundle hoch und fördert es in einem Workflow. Die Reinigung ist atomar und wird überprüft, ob der Schlüssel das Kanal und das verbundene, nicht geteilte Bundle erstellt hat. Der Schlüssel kann nur das Kanal löschen, das er erstellt hat, und das verbundene, nicht geteilte Bundle. Er kann jedoch nicht ändern, fördern oder löschen, wenn es sich um ein bestehendes Haupt-/Standardkanal, ein Kanal eines anderen Vorschau-Schlüssels oder ein Kanal eines anderen Schlüssels handelt.

Wenn Rezensenten 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 Berechtigung für die App-Einstellungen hat. In GitHub Actions, 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.

Zum Gerät bereitstellen

Jetzt, da Sie 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 zu hören
3. Ein Build hochladen und diesem Kanal zuweisen
4. Die App starten und auf das Update warten!

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

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 Benutzerstufen
• A/B-Test
• Schrittweise Einführung neuer Funktionen
• Betaversionstests

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

Fortsetzung von Kanälen

Wenn Sie Kanäle verwenden um Kanalrouting und eine rollierende Veröffentlichung zu planen, verbinden Sie es mit Kanäle Kanäle Kanäle Kanäle Testlösung zur Produktionsablauf in Testlösung Zielgruppenziel-Lösung zur Produktionsablauf in Zielgruppenziel-Lösung Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID zur praktischen Umgebung in Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID