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 von Updates für diesen Kanal konfiguriert sind. Wenn Sie den Capgo Live-Updates-SDK 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 sich ein Kanal bezieht, jederzeit ändern und können auch auf vorherige Builds zurückkehren, wenn nötig.

Kanäle bieten keine Vertraulichkeit

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

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

Wenn ein Gerät nach einer Aktualisierung sucht, Capgo bestimmt in dieser strengen Reihenfolge (höchste Priorität zuerst), welchen Kanal zu verwenden ist:

1. Zwangsmapping eines Geräts (Dashboard) – Ein bestimmtes Geräte-ID manuell an einen Kanal anhängen. Verwenden Sie dies für dringende Debugging oder kontrollierte Tests mit einem einzelnen echten Benutzer. Dies gewinnt immer.
2. Cloud-Übernahme (pro-Gerät) via Dashboard oder API – Erstellt, wenn Sie den Kanal des Geräts im Dashboard oder via 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 ihn nicht; die Löschung der Geräte-Einträge tut es.
3. Plugin setChannel() lokaler Kanal – Erstellt, wenn die App setChannel() und der Backend validiert, dass das Zielkanal Selbstzuweisung zulässt. Das ausgewählte Kanal wird lokal auf diesem Gerät gespeichert, wirkt sofort und wird nicht im Geräte-Überschreibungs-UI angezeigt.

Instantaner Kanalwechsel mit setChannel()

Ab der Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion) setChannel() funktioniert anders: es kontaktiert das Backend, um zu validieren dass der Kanal zugelassen ist (Überprüfung, ob Selbstzuweisung für diesen Kanal aktiviert ist), dann speichert es den Kanal lokal auf dem Gerät als defaultChannel. Das bedeutet, der neue Kanal wirkt unmittelbar für die nächste Aktualisierung überprüfen—warten Sie nicht auf die Replikation.

Zuvor setChannel() Die Kanalüberschreibung wurde zum Backend-Datenbank (wie Dashboard oder API Änderungen) gespeichert, 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 eine sofortige Kanalwechsel ermöglicht.

Da setChannel() ist lokal nur, es schafft es nicht eine Geräteüberschreibungseinträge im Capgo Dashboard zu erstellen. Die Geräteüberschreibungsoberfläche zeigt nur Überschreibungen an, die aus dem Dashboard oder dem öffentlichen API erstellt wurden.

Hinweis: Even wenn ein Kanal nach der lokalen Einstellung verboten wird, wird der Backend die Kanalvalidierung während der Aktualisierung überprüfen, sodass die Sicherheit gewährleistet ist.

Wichtig: Wenn Kanaländerungen über das Dashboard oder API vorgenommen werden, besteht immer noch ein Replikationsverzug von bis zu 2 Minuten, 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 sofortigen Effekt.

4. Capacitor Konfiguration defaultChannel (Testbau-Standard) – Wenn vorhanden in capacitor.config.* und keine Zwang/Übernahme/Lokal-Kanal existiert, startet die App auf diesem Kanal (z. B.) beta, qa, pr-123. Intended for TestFlight / interne Builds, damit Tester automatisch auf einem Vorkabel-Kanal landen. Produktionsbuilds lassen diesen normalerweise ungesetzt.
5. Cloud-Standardkanal (Hauptpfad ~99% der Benutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endbenutzer (kein Zwang, keine Dashboard/API-Übernahme, keine Plugin-Lokalkanal, keine Konfigurations-Standardkanal) hier angeschlossen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen – kein neuer Binärdatei. 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-Standardkanals ist erlaubt; in diesem Fall muss das Gerät auf Schritte 1–4 abgestimmt sein, um Updates zu erhalten.

Best Practice:

• Treat 1–4 als Ausnahmen / Testebenen; wenn Sie einen Cloud-Standard setzen, sollten sich echte Benutzer in ihn einfließen. Wenn Sie keinen setzen, sollten Sie bewusst sein, wie Benutzer angeschlossen werden (typischerweise via) defaultChannel Konfiguration oder per-Geräte-Übernahmen.
• Nur konfigurieren Sie defaultChannel im Binärdateien, die Sie explizit an Tester verschicken. Das Ignorieren dieses Feldes hält die Produktionslogik zentral im Dashboard.
• Verwenden setChannel() Verwenden Sie es sparsam in der Produktion—hauptsächlich für QA oder gezielte Diagnosen.

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

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

Standardverhalten des Kanals

Die Festlegung eines Cloud-Standards ist optional, aber es dient normalerweise als allgemeiner Pfad für neue Geräte. Ohne einen solchen, erhalten nur Geräte, die sich an gezwungenen Zuordnungen, Überschreibungen oder einem defaultChannel im Capacitor-Konfigurationsdatei angegebenen Muster, Updates.

• Wenn Sie sich entscheiden, Standards zu markieren, beachten Sie diese Muster: Einziger Standard (am häufigsten)
• Plattform-spezifische Standards – Wenn Sie die Kanäle nach Plattform aufteilen (z.B. nur iOS aktivieren, nur Android aktivieren und nur Electron aktivieren), 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 sie auf einem nicht-produktiven Kanal starten möchten, auch wenn der Cloud-Standard anders ist. defaultChannel Sie können Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, folgen neue Geräte dem neuen Routing sofort und bestehende Geräte folgen den normalen Vorherrschaftsregeln beim nächsten Mal, wenn sie sich anmelden. 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 Plattform-spezifische Standards defaultChannel – Wenn Sie die Kanäle nach Plattform aufteilen (z.B. nur iOS aktivieren, nur Android aktivieren und nur Electron aktivieren), 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.

Denken Sie daran, dass der Cloud-Standard und

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 leer für Produktionsbuilds. Reservieren Sie für Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie sie auf einem nicht-produktiven Kanal starten möchten, auch wenn der Cloud-Standard anders ist. Sie können Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, folgen neue Geräte dem neuen Routing sofort und bestehende Geräte folgen den normalen Vorherrschaftsregeln 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 weitere Kanäle später hinzuzufügen:

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

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie 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

Einrichtung des Kanals in Ihrer App

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

Öffnen Sie Ihr capacitor.config.ts Datei (oder capacitor.config.jsonDatei). Unter der plugins Abschnitt, setzen Sie optional defaultChannel für Testversionen (intern / QA). Für Produktionsversionen 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ächste, bauen Sie Ihre Web-App und führen Sie npx cap sync aus, um die aktualisierte Konfigurationsdatei in Ihre iOS-, Android- und Electron-Projekte zu kopieren. Wenn Sie diesen Synchronisierungsstep überspringen, verwenden Ihre native Projekte weiterhin den Kanal, auf den sie zuvor konfiguriert waren.

Achtung

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

Verwenden defaultChannel nur in Test-/Internbuilds; löschen Sie es für die Produktion, damit die Benutzer dem Cloud Standard (wenn gesetzt) folgen, anstatt das Routing im native Config zu duplizieren.

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

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 markiere das Standardkanal oder das plattform-spezifische Kanal, an das neue Geräte angeschlossen sind. Siehe “Standardkanalverhalten” für Routingszenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
• Unter native deaktivieren: Verhindert die Übermittlung eines Updates, 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).
• Entwicklerversionen zulassen: Ermöglichen Sie Updates für Entwicklerversionen (nützlich für Tests).
• Simulatoren zulassen: Ermöglichen Sie Updates für Emulatoren/Simulatoren (nützlich für Tests).
• Geräte selbst zuweisen lassen: Lassen Sie die App zu diesem Kanal umschalten, indem Sie setChannelbenutzen. Wenn deaktiviert, setChannel versagen Sie für diesen Kanal.

Schrittweise Rollouts

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

Automatische Update-Strategien 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ätebasis (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: Strictest-Modus. Blockiert jede Änderung an der Haupt-, Minor- oder Patchversion. Nur Suffix-Änderungen sind während MAJOR.MINOR.PATCH bleiben 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 mit --min-update-version oder --auto-min-update-version. Wenn fehlend, wird das Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis sie gesetzt werden.
• alle Updates entsprechend kompatibel sind..

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 im Disable-Updates-Strategie-Artikel unter /docs/cli/commands/#disable-updates-strategie.

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, 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
• Opt-in-Flüsse für Beta-Programme
• Funktionsflag-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 zu überprüfen, ob der Kanal zugelassen ist (Überprüfung der Selbstzuweisungsrechte)
2. Speicherung in der lokalen Zwischenablage: Wenn die Überprüfung erfolgreich ist, wird der Kanal als "Instant effect" in der Gerätespeicherung gespeichert defaultChannel
3. Instant effect: Die nächste Aktualisierungskontrolle verwendet das neue Kanal sofort (keine Wartezeit für die Replikation)

Weshalb das wichtig ist: Bei älteren Versionen, setChannel() speicherte die Überlagerung des Kanals 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: Ein Kanal, der mit dem Plugin gesetzt wurde, macht das Gerät nicht als Geräte-Überlagerung 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 Überlagerung benötigen.

Sicherheitshinweis: Even wenn sich die Berechtigungen eines Kanals nach der lokalen Festlegung ä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:

Methode	Wirkungsdauer	Persistiert Wo	Angezeigt im Geräte-Überschreibungs-UI	Verwendungsfall
setChannel() Von Plugin	Instant	Nur Gerät (lokal)	Nein	Benutzerinitiierte Kanalwechsel in-app
Übersichtsgerät-Überschreibung	Höchstens 2 min	Hintergrund-Datenbank	Ja	Administrationsinitiierte Änderungen für bestimmte 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 Funktion des Plugins. setChannel() Mindestversionen für lokale Kanalwechsel:

oder 5.34.0, 6.34.0, 7.34.0(abhängig von Ihrer Hauptversion). Jede kleine Versionennummer entspricht demselben Funktionsumfang in allen Hauptversionen (z.B. X.34.0 enthält die gleichen Funktionen, egal ob X 5, 6, 7 oder 8 ist. Siehe 8.0.0 Plugin-Installation Admin-eingeleitete Änderungen für bestimmte Geräte zur Versionsbezeichnung.

Ein Bundle einer Kanal zuweisen

Um eine Live-Update zu deployen, müssen Sie ein neues JS-Bundle-Build hochladen und ihm einen Kanal zuweisen. Dies können Sie 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 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 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 auf mehrere Kanäle zugewiesen werden.

When Sie Ihre Pakete versionieren, empfehlen wir die Verwendung von semantischer Versionsnummerierung mit Capgo’s Semver-Tester und Vorklauselidentifikatoren für Kanal-spezifische Builds. Zum Beispiel könnte eine Beta-Version als 1.2.3-beta.1.

versioniert werden. In CI, wenn die lokale Version bereits hochgeladen wurde, verwenden Sie npx @capgo/cli@latest bundle upload --auto-bump (optional major, minor, patch/fix, metadata, oder ai) so dass CLI von dem Kanal-basierten Bundle bis zu einem freien Namen gefunden wird. Mit ai, erkennt Workers AI 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 kombinieren. Siehe und das CI/CD-Integration CLI Referenz.

Dieser Ansatz hat mehrere Vorteile:

• Es kommuniziert offensichtlich die Beziehung zwischen Builds. 1.2.3-beta.1 ist offensichtlich eine Vorschau von 1.2.3.
• Es ermöglicht die Wiederholung von Versionsnummern über Kanäle, was die Verwirrung reduziert.
• Es ermöglicht klare Rückschrittspfade. 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önnten:

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

Verwendung mit Voreinstellungen für vorab veröffentlichte Versionen ist eine empfohlene Vorgehensweise, aber nicht strikt erforderlich. Der Schlüssel ist es, eine Versionsverwaltung 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 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 die Version, die Sie zurücksetzen möchten, und klicken Sie auf das Krönchen-Symbol
3. Bestätigen Sie die Aktion

Die ausgewählte Version wird sofort wieder die aktive Version für diesen Kanal. Apps erhalten die zurückgesetzte 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. Indem Sie Capgo in Ihren Build-Prozess integrieren, können Sie neue Pakete automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

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

die Dokumentation, um mehr über die Automatisierung von __CAPGO_KEEP_0__-Live-Updates zu erfahren.

Verwenden Sie einen App-Vorschau API-Schlüssel, wenn CI einen temporären Kanal pro Pull-Request benötigt, aber bestehende Haupt-/Standardkanäle nicht verwalten soll. Der Schlüssel bleibt der eigenen Organisation und der ausgewählten App zugeordnet; er hat einfach keine Organisationsebene. Jeder nicht öffentliche Vorschaukanal, den es erstellt, erhält seine eigene automatische, kanal-basierte Lifecycle-Berechtigung.

1. Haben Sie einen Organisation administrator einen sicheren API-Schlüssel erstellen lassen, der nur auf die Vorschau-App beschränkt ist und App-Vorschauanwählen. Siehe API-Schlüssel.
2. Verwenden Sie einen eindeutigen, nicht öffentlichen Kanal wie pr-123keinen --default, --self-assign, --delete-linked-bundle-on-upload.
3. oder

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 einen fehlenden Kanal, lädt das Bundle hoch und promotet es in einem Workflow. Die Reinigung ist atomar und wird auf die Eigentümerschaft überprüft: Der Schlüssel kann nur einen Kanal löschen, den er erstellt hat und dessen verbundenes, nicht geteiltetes Bundle. Er kann einen bestehenden Haupt-/Standardkanal, einen Kanal eines anderen Preview-Schlüssels oder ein anderes Schlüssel-Bundle nicht ändern, promoten oder löschen.

Wenn Rezensenten eine QR-Code code oder eine Preview-URL benötigen, muss ein Administrator die Vorabansichten 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 Vorabansichten nicht selbst aktivieren, da er keine App-Einstellungen-Rechte hat. In GitHub Actions, führen Sie geheime Preview-Aufgaben in pull_request, nicht pull_request_target, und beschränken Sie sie auf PRs mit github.event.pull_request.head.repo.full_name == github.repository.

Auf einem 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 das Capgo SDK in Ihrer App
2. Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu hören
3. Hochladen Sie eine Build und zuweisen Sie sie diesem Kanal
4. Lancieren Sie die App und warten Sie auf die Aktualisierung!

Für eine detailliertere Anleitung, sehen Sie sich das Lebendige Updates bereitstellen Richtlinie an.

Glückliche Aktualisierung!

Abschnitt mit dem Titel “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-Testung,
• Testprogramme für Beta-Versionen

Erhalten Sie Informationen, wie Sie diese komplexen Anwendungsfälle in unserer Anleitung umsetzen können: Wie Sie Benutzer nach Tarif und Kanälen segmentieren und für Feature-Flags und A/B-Tests verwenden können.

Fortsetzung von Kanälen

Wenn Sie Kanäle verwenden Kanäle Kontext: Capgo-Funktionsname für die Veröffentlichungs-Kanäle. Seite/Bereich: Capgo-Marketingseite für Lösungen. Rolle: Kurzer Benutzerschnittstelle-Label oder Navigationspunkt. Gesehen in: Seite solutions/white-label.astro. Nachrichten Schlüssel `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value). Kanäle Kontext: Capgo-Funktionsname für die Veröffentlichungs-Kanäle. Seite/Bereich: Capgo-Marketingseite für Lösungen. Rolle: Kurzer Benutzerschnittstelle-Label oder Navigationspunkt. Gesehen in: Seite solutions/white-label.astro. Nachrichten Schlüssel `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value). Kanäle Kontext: Capgo-Funktionsname für die Veröffentlichungs-Kanäle. Seite/Bereich: Capgo-Marketingseite für Lösungen. Rolle: Kurzer Benutzerschnittstelle-Label oder Navigationspunkt. Gesehen in: Seite solutions/white-label.astro. Nachrichten Schlüssel `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value). Testlösung für Beta-Phase zur Produktionsablauf in Testlösung für Beta-Phase Zielsystem für Versionsziele zur Produktionsablauf in Zielsystem für Versionsziele, und Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID zur praktischen Kontext in Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID.