Channels

Un canal Live Update pointe vers une version spécifique du build JS de votre application qui sera partagée avec tous les appareils configurés pour écouter ce canal pour les mises à jour. Lorsque vous installez le Capgo Live Updates SDK dans votre application, tout binôme natif configuré pour ce canal vérifiera les mises à jour disponibles chaque fois que l'application est lancée. Vous pouvez modifier la version du build vers laquelle pointe un canal à tout moment et pouvez également revenir à des versions précédentes si nécessaire.

Les canaux ne fournissent pas de confidentialité.

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See Live Update chiffrement pour plus de détails.

Comment un appareil choisit un canal (préférence)

Lorsqu'un appareil vérifie une mise à jour, Capgo décide quel canal utiliser dans cet ordre strict (priorité la plus élevée en premier) :

1. Attribution forcé du dispositif (Tableau de bord) – Fixer manuellement un ID de dispositif spécifique à un canal. Utilisez pour des débogages urgents ou des tests contrôlés avec un seul utilisateur réel. Cela l'emporte toujours. Capgo supprime la mise à jour 90 jours après la dernière écriture de mise à jour. Console et mises à jour API expirent après 90 jours.
2. Surcharge Cloud (par appareil) via Tableau de bord ou API – Créée lorsque vous changez le canal de l'appareil dans le tableau de bord ou via API. Utilisez pour les utilisateurs QA qui passent entre les canaux de fonctionnalité / PR ou pour reproduire un problème d'utilisateur. La suppression du fichier de configuration ne supprime pas la mise à jour ; la suppression de la mise à jour du dispositif le fait. La même retenue de 90 jours s'applique.
3. Plugin setChannel() Canal local – Créé lorsque l'application appelle setChannel() et le serveur de backend valide que le canal cible autorise l'auto-assignation. Le canal sélectionné est stocké localement sur cet appareil, prend effet instantanément et n'est pas affiché dans l'interface de surclassement de l'appareil.

Switcher de canal instantané avec setChannel()

À partir de la version du plugin 5.34.0, 6.34.0, 7.34.0 ou 8.0.0 selon votre version majeure, setChannel() fonctionne différemment : il contacte le serveur de backend pour valider que le canal est autorisé (en vérifiant si l'auto-assignation est activée pour ce canal), puis stocke le canal localement sur l'appareil comme defaultChannel. Cela signifie que le nouveau canal prend effet instantanément pas d'attente pour la prochaine mise à jour.

Jusqu'alors, setChannel() les modifications du canal étaient enregistrées dans la base de données backend (comme le tableau de bord ou les modifications de API), et les appareils devaient attendre la réplication des données (jusqu'à 2 minutes) avant que le nouveau canal soit reconnu. Le nouveau comportement ne lit que dans le backend (pour la validation) et stocke localement, ce qui permet des changements de canal instantanés.

Puisque setChannel() est local-only, il ne not créez une entrée de surclassement de dispositif dans le tableau de bord Capgo. L'interface de surclassement de dispositif ne montre que les surclassements créés à partir du tableau de bord ou de l'espace public API.

Note: Même si un canal est interdit après avoir été configuré localement, le serveur vérifiera toujours le canal lors des vérifications de mise à jour, afin de maintenir la sécurité.

__CAPGO_KEEP_0__ Quand des modifications de canal sont effectuées via le tableau de bord ou API, il y a encore un retard de réplication de jusqu'à 2 minutes avant que tous les serveurs de bord réfléchissent la modification. Pour un changement de canal instantané, utilisez setChannel() from votre application code—il s'assure de la validation avec le serveur, puis définit le canal localement pour un effet immédiat.

4. Capacitor de configuration defaultChannel (défaut de build de test) – Si présent dans capacitor.config.* et qu'il n'y a pas de canal forcé/forcé/local, l'application démarre sur ce canal (par exemple, beta, qa, pr-123Intégré pour les builds TestFlight / internes afin que les testeurs atterrissent automatiquement sur un canal de pré-version. Les builds de production laissent généralement cela non défini.
5. Canal par défaut Cloud (chemin principal ~99% des utilisateurs) – Si vous marquez un canal par défaut dans le tableau de bord, tous les utilisateurs normaux (sans force, sans tableau de bord/API de surcharge, sans canal local de plugin, sans canal de configuration par défaut) s'y attachent. Modifiez-le pour lancer ou annuler instantanément—sans nouvelle version binaire. Si vous avez des valeurs par défaut spécifiques aux plateformes (par exemple, un seul iOS, un seul Android, un seul Electron), chaque appareil atterrit sur la valeur par défaut correspondant à sa plateforme. Laisser le canal par défaut cloud non défini est autorisé ; dans ce cas, l'appareil doit correspondre aux étapes 1-4 pour recevoir des mises à jour.

Meilleure pratique :

• Traitez 1-4 comme des couches d'exception / de test ; lorsque vous définissez un canal par défaut cloud, les utilisateurs réels devraient s'y connecter. Si vous ne le définissez pas, soyez délibéré sur la façon dont les utilisateurs s'y attachent (généralement via defaultChannel in config or per-device overrides).
• Seul configurez defaultChannel en binaires que vous envoyez explicitement aux testeurs. Laisser cela non défini garde la logique de production centralisée dans le tableau de bord.
• Utilisez setChannel() Seulement en production—principalement pour les tests ou les diagnostics ciblés.

Si un canal est désactivé pour la plateforme (iOS/Android/Electron) lorsqu'il serait autrement choisi, le processus de sélection le passe et continue plus bas dans la liste.

Résumé : Force > Tableau de bord/API Survol > Plugin setChannel() canal local > Config defaultChannel > Défaut du Cloud.

La console et les API survol expirent après 90 jours

Les mappages forcés et les survol de Tableau de bord ou de canal public API sont stockés comme affectations par appareil dans Capgo. Un job de nettoyage supprime ces affectations 90 jours après la dernière écriture de survolVérifiez l'actualisation sans réinitialiser l'horloge. Seule la réécriture de l'override (ou sa suppression manuelle) modifie la date de dernière mise à jour.

Cela n'est pas le même que la conservation de l'inventaire des appareils. L'inventaire supprime les appareils qui n'ont pas été connectés à Capgo pendant 90 jours. La suppression de l'override supprime la correspondance même si l'appareil est toujours actif.

Pour une affectation qui n'est pas supprimée par cette suppression :

• Fixer defaultChannel in capacitor.config.* (survit une réinstallation; nécessite un nouveau binaire natif pour changer plus tard).
• Call setChannel() from the app. On plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 and later, that assignment is local and is not removed by this cleanup. Reinstalling the app clears it, so the app must call setChannel() recommencez si vous souhaitez toujours ce canal.

Le canal Appareils La console et les affectations publiques API ne sont listées que dans la liste d'override UI. Ils ne listent pas tous les appareils du canal, et ils ne listent pas les appareils locaux setChannel() assignments.

Supprimez la notice de conservation sur l'onglet appareils du canal.

Comportement de la Chaîne par Défaut

Setting a cloud default is optional, but it usually serves as the catch-all path for new devices. Without one, only devices that match on forced mappings, overrides, or a defaultChannel dans la Capacitor config, les mises à jour seront appliquées. Lorsque vous choisissez de conserver les valeurs par défaut, gardez à l'esprit ces modèles :

• Canaux par défaut spécifiques à un appareil – Si un canal a iOS, Android et Electron activés, il devient le canal par défaut unique ; tout appareil sans surcharges attachera ici.
• Single default (most common) – Si vous divisez les canaux par plateforme (par exemple, ios-production avec uniquement iOS activé, android-production avec uniquement Android activé, et electron-production avec uniquement Electron activé), marquez chaque canal comme le canal par défaut de sa plateforme. Les appareils iOS se connectent au canal par défaut iOS, les appareils Android se connectent au canal par défaut Android, et les applications Electron se connectent au canal par défaut Electron.

Rappelez-vous que le canal par défaut cloud et defaultChannel in capacitor.config.* Les deux occupent le même niveau de décision. Si vous définissez un paramètre par défaut dans Cloudflare, vous n'avez pas besoin de dupliquer la valeur dans votre fichier de configuration Capacitor. defaultChannel Réservé pour les builds de production. defaultChannel for binaries you intentionally ship to testers or QA when you want them to start on a non-production channel even if the cloud default is different.

Vous pouvez modifier les paramètres par défaut à tout moment dans le tableau de bord. Ouvrez le canal, puis Gérer les paramètres de l'application, qui vous mène à Informations sur l'applicationLa valeur par défaut n'est plus un commutateur sur la page du canal. Lorsque vous changez une valeur par défaut, les nouveaux appareils suivent les nouvelles règles de routage immédiatement et les appareils existants suivent les règles de priorité normales la prochaine fois qu'ils se connectent.

Configuration d'un Canal

Lors de l'inscription, vous créez le premier canal (la plupart des équipes le nomment « Production »), mais rien n'est verrouillé — vous pouvez renommer ou supprimer n'importe quel canal à tout moment. Pour ajouter des canaux supplémentaires ultérieurement :

1. Allez dans la section « Canaux » de votre tableau de bord Capgo
2. Cliquez sur le bouton « Nouveau Canal »
3. Entrez un nom pour le canal et cliquez sur « Créer »

Les noms de canal peuvent être n'importe quoi. Une stratégie courante est de correspondre les canaux à vos étapes de développement, comme :

• Development pour tester les mises à jour en direct sur des appareils locaux ou des émulateurs
• QA - pour que votre équipe QA vérifie les mises à jour avant une large diffusion
• Staging - pour les tests finals dans un environnement simulant la production
• Production - for the version of your app that end users receive from the app stores

Configuration de la chaîne dans votre application

Une fois vos chaînes créées, vous devez configurer votre application pour qu'elle écoute la chaîne appropriée. Dans cet exemple, nous utiliserons la Development chaîne.

Ouvrez votre capacitor.config.ts (ou capacitor.config.jsonfichier. Sous le plugins ) fichier. Sous la defaultChannel for pour (intérieur / QA). Pour les builds de production, préférez l'omission afin que les appareils utilisent la valeur par défaut de Cloud sauf si elle est explicitement surchargée.

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

Ensuite, construisez votre application web et exécutez npx cap sync pour copier le fichier de configuration mis à jour dans vos projets iOS, Android et Electron. Si vous passez cette étape de synchronisation, vos projets natives continueront d'utiliser le canal dont ils étaient précédemment configurés.

Attention

Ordre de sélection des canaux : Force > Dashboard/API définir le dispositif > Plugin setChannel() canal local > Config defaultChannel > par défaut Cloud.

Utilisez defaultChannel seulement dans les builds de test/internes ; laissez-le de côté pour la production afin que les utilisateurs suivent le par défaut Cloud (lorsqu'il est défini) au lieu de dupliquer la routage dans la configuration native.

Vous pouvez toujours forcer (fixer) un appareil ou appliquer un décalage ultérieurement — ceux-ci supplantent immédiatement la valeur de la configuration.

Les noms de canaux sont sensibles à la casse.

Options et stratégies de canal

Les canaux disposent de plusieurs options qui contrôlent qui peut recevoir des mises à jour et comment les mises à jour sont livrées. Les plus importantes sont ci-dessous. Vous pouvez configurer ces options à partir de l'application web, de l'CLI ou du Public API.

• Canal par défaut : Marquez facultativement le canal ou les canaux spécifiques au plateau-forme auxquels les nouveaux appareils se connectent.Gérer dans les paramètres de l'application Voir “Comportement de la chaîne par défaut” pour les scénarios de routage.
• Filtres de plateforme : Activer ou désactiver la livraison vers iOS, Androidou Electron appareils par canal.
• Désactiver la mise à niveau automatique sous native : Empêche l'envoi d'une mise à jour lorsque la version native de l'appareil est plus récente que la version du bundle du canal (par exemple, appareil sur 1.2.3 tandis que le canal a 1.2.2).
• Permettre les builds de développement : Autoriser les mises à jour vers les builds de développement (utiles pour les tests). CLI : --dev / --no-dev.
• Permettre les builds de production : Autoriser les mises à jour vers les builds de production (magasin). Laissez cela activé pour les canaux qui servent des utilisateurs réels. CLI : --prod / --no-prod.
• Permettre aux appareils émulateurs : Autoriser les mises à jour des émulateurs/simulateurs (utile pour les tests). CLI: --emulator / --no-emulator.
• Permettre aux appareils physiques : Autoriser les mises à jour des téléphones et tablettes réels. Laissez cela activé pour les canaux de production. CLI: --device / --no-device.
• Permettre l'auto-assignation du dispositif : permet à l'application de passer à ce canal en temps de exécution setChannelSi désactivé, setChannel échouera pour ce canal. CLI: --self-assign / --no-self-assign.
• Format de téléchargement : Choisissez si les appareils téléchargent un zip complet, uniquement les fichiers delta modifiés ou le meilleur des deux (all, zip, delta, zip_from_builtin, delta_from_builtin). See Format de téléchargement pour le menu déroulant de la console et pour savoir quand chaque mode est utile.

Déploiements progressifs

A channel can keep a stable bundle while gradually exposing a separate rollout target to a sticky device cohort. You can pause, resume, promote, roll back, and configure an automatic failure response without switching the channel for everyone. See Mise en œuvre progressive pour le modèle de livraison, flux de travail de tableau de bord, champs API et commandes CLI

Désactiver les stratégies d'actualisation automatique

Utilisez cela pour restreindre les types d'actualisations que le canal livrera automatiquement. Options :

• major : bloque une version cible dont la version majeure est supérieure à la base native du dispositif ("version_buildExemple : 1.2.3 -> 2.0.0 est bloqué ; 1.2.3 -> 1.9.0 est autorisé.
• mineur : Bloc un paquet cible dont la version majeure ou mineure diffère de version_buildExemple : 1.2.3 -> 1.3.0 est bloqué ; 1.2.3 -> 1.2.4 est autorisé.
• mode strict : aucune modification n'est autorisée pour les numéros majeur, mineur ou de patch. Seules les modifications de suffixe sont autorisées MAJOR.MINOR.PATCH se maintient inchangé. Exemples : 1.0.0-beta.1 -> 1.0.0-beta.2 est autorisé, 1.0.0+build.1 -> 1.0.0+build.2 est autorisé, 1.0.0 -> 1.0.1 est bloqué.
• metadata : Exige une version minimale d'update de métadonnées sur chaque bundle. Configurez via CLI en utilisant --min-update-version ou --auto-min-update-versionSi absent, le canal est marqué comme non configuré et les mises à jour seront rejetées jusqu'à ce qu'il soit défini.
• aucun: Autoriser tous les mises à jour selon compatibilité semver.

Ces stratégies comparant la version cible du canal à la version native de base envoyée comme version_build, pas le bundle téléchargé actuellement envoyé comme version_name.

Apprenez davantage de détails et d'exemples dans la stratégie de désactivation des mises à jour à /docs/cli/commands/#disable-updates-strategy.

Exemple (CLI). Le canal doit déjà exister (channel set ne le crée pas):

# 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

En utilisant setChannel() depuis Votre Application

La setChannel() méthode permet à votre application de passer en mode canal à l'exécution. Cela est particulièrement utile pour:

• Menus de test/QA où les testeurs peuvent passer entre les canaux
• Flux d'opt-in du programme bêta
• Implémentations de drapeaux de fonctionnalité
• Scénarios de test A/B

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
});

Comment fonctionne setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Lorsque setChannel() est appelé :

1. Validation back-end (lecture seule): Une requête est envoyée vers l'arrière-plan Capgo pour valider que le canal est autorisé (en vérifiant les permissions d'auto-assignation)
2. Mise à jour du stockage localSi la validation passe, le canal est sauvegardé dans le stockage local du dispositif sous defaultChannel
3. Effet instantanéLa prochaine vérification de mise à jour utilise le nouveau canal immédiatement (pas d'attente pour la réplication).

Pourquoi cela compte : Dans les versions plus anciennes, setChannel() enregistrait la surcharge de canal dans la base de données backend (même chose que les modifications du tableau de bord ou API). Les appareils devaient attendre la réplication backend (jusqu'à 2 minutes) avant que le changement de canal prenne effet. Maintenant, setChannel() seule lecture du backend (pour validation) et stockage local, ce qui rend les changements de canal instantanés.

Visibilité du tableau de bord : Un canal défini avec l'extension ne fait pas apparaître l'appareil comme une surcharge de dispositif dans l'interface utilisateur Capgo. Seuls les affectations de canal créées à partir du tableau de bord ou du Public API sont listés là. Utilisez le tableau de bord ou API lorsque vous avez besoin d'une surcharge visible par l'administrateur.

Note de sécurité : Même si les permissions d'un canal changent après avoir été définies localement (par exemple, la désactivation de l'auto-assignation), le backend valide toujours le canal lors des vérifications de mise à jour, ce qui garantit la sécurité.

Comparaison des méthodes de changement de canal :

Méthode	Temps d'effet	Persistance Où	Affiché dans l'interface d'override du dispositif	Expiration	Utilisation
setChannel() from le plugin	Instantané	Seulement sur l'appareil (local)	Non	No (until you change it or reinstall)	Switcher utilisateur entre canaux
Survol de la console	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de surcharge	Mises à jour administratives pour des appareils spécifiques
Affectation de canal API	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de surcharge	Intégrations back-end automatisées

For the best user experience when building channel-switching UIs, always use the plugin’s setChannel() method.

Versions minimales pour le basculement de canal local uniquement : 5.34.0, 6.34.0, 7.34.0, ou 8.0.0 (selon votre version majeure). Chaque numéro de version mineure correspond au même ensemble de fonctionnalités dans toutes les versions majeures (par exemple, X.34.0 inclut les mêmes fonctionnalités que X est 5, 6, 7 ou 8). Voir l'installation de plugin pour les étiquettes de version.

Attribution d'un Bundle à un Canal

Pour déployer un live update, vous devez télécharger un nouveau build de bundle JS et l'attribuer à un canal. Vous pouvez effectuer cela en une étape avec le Capgo CLI :

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

Cela téléchargera vos actifs web construits et définira le nouveau bundle en tant que build actif pour le Development canal. Toutes les applications configurées pour écouter ce canal recevront la mise à jour la prochaine fois qu'elles vérifieront une mise à jour.

Vous pouvez également affecter les builds aux canaux à partir de la section « Bundles » de l'Capgo tableau de bord. Cliquez sur l'icône de menu à côté d'un build et sélectionnez « Affecter au canal » pour choisir le canal pour ce build.

Numérotation des versions de Bundles et canaux

Il est important de noter que les bundles dans Capgo sont mondiaux pour votre application, et non spécifiques à des canaux individuels. Le même bundle peut être affecté à plusieurs canaux.

Lorsque vous versionnez vos bundles, nous vous recommandons d'utiliser la numérotation semantique avec le Capgo Semver Tester et les identificateurs de pré-version pour les builds spécifiques au canal. Par exemple, une version bêta pourrait être versionnée comme 1.2.3-beta.1.

Dans CI, si la version locale était déjà téléchargée, utilisez npx @capgo/cli@latest bundle upload --auto-bump (optionnellement major, minor, patch/fix, metadataou ai ) afin que CLI augmente de la version du canal lié au bundle jusqu'à trouver un nom gratuit. Avec ai , Workers AI infère le niveau à partir du delta local vs précédent manifeste (retourne à patch avec aucune version précédente Capgo). Vous ne pouvez pas le combiner avec --bundle. Voir Intégration CI/CD et le Référence de CLI.

Cette approche présente plusieurs avantages :

• Cette approche présente plusieurs avantages : 1.2.3-beta.1 Elle communique clairement la relation entre les builds. 1.2.3.
• Cela permet de réutiliser les numéros de version entre les canaux, réduisant ainsi la confusion.
• Il permet des chemins de reversion clairs. Si vous devez revenir en arrière depuis 1.2.3Vous savez 1.2.2 , vous savez que c'est la version stable précédente.

Voici un exemple de la façon dont vous pouvez aligner les versions de votre bundle avec un setup de canal typique :

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

En utilisant semver avec des identifiants de pré-version est une approche recommandée, mais pas strictement requise. La clé est de trouver un schéma de versionnement qui communique clairement les relations entre vos builds et s'aligne sur le processus de développement de votre équipe.

Annuler un Live Update

Si vous déploiez un live update qui introduit une erreur ou qui doit être annulé, vous pouvez facilement revenir à une version précédente. Dans la section « Canaux » de la console de bord :

1. Cliquez sur le nom du canal que vous souhaitez annuler
2. Trouvez la version que vous souhaitez rétablir et cliquez sur l'icône de couronne
3. Confirmez l'action

La version sélectionnée deviendra immédiatement la version active pour ce canal. Les applications recevront la version rétablie la prochaine fois qu'elles vérifieront les mises à jour.

Automatiser les déploiements

Pour des workflows plus avancés, vous pouvez automatiser vos déploiements de live update en tant que partie de votre pipeline CI/CD. En intégrant Capgo à votre processus de build, vous pouvez télécharger automatiquement de nouvelles archives et les affecter à des canaux chaque fois que vous poussez sur certaines branches ou créez de nouvelles versions.

Consultez le Intégration CI/CD Pour en savoir plus sur l'automatisation des mises à jour en direct Capgo.

Aperçu de PR avec privilèges minimal

Utilisez un App Preview API clé lorsqu'un CI en a besoin d'une canal temporaire par demande de tirage mais ne doit pas gérer les canaux existants par défaut. La clé reste liée à l'organisation propriétaire et à l'application sélectionnée ; elle n'a simplement pas de rôl’organisationnel. Chaque canal de prévisualisation non public qu'elle crée reçoit sa propre autorisation de cycle de vie automatique, scoping par canal.

1. Obtenez un administrateur d'organisation à créer une clé API sécurisée limitée à l'application de prévisualisation et sélectionnez App PreviewVoir Clés API.
2. Utilisez un canal unique, non public comme pr-123. Ne pas transmettre --default, --self-assign, options de déploiement, ou --delete-linked-bundle-on-upload.
3. Téléchargez et promouvez le paquet PR en une seule commande, puis supprimez le canal et le paquet propriétaires lorsque la PR est fermée :

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 crée un canal manquant, télécharge le paquet et le promeut en une seule opération. La suppression est atomique et vérifie l'appartenance : la clé peut supprimer uniquement un canal qu'elle a créé et son paquet lié, non partagé. Elle ne peut pas modifier, promouvoir ou supprimer un canal principal/défaut existant, un canal d'un autre clé de prévisualisation ou un paquet d'une autre clé.

If reviewers need a QR code or preview URL, an administrator must enable previews once for the app:

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

An App Preview key cannot enable previews itself because it has no app-settings permission. In GitHub Actions, run secret-bearing preview jobs on pull_request, pas pull_request_target, et les restreint aux PR de même-répertoire avec github.event.pull_request.head.repo.full_name == github.repository.

Déploiement vers un appareil

Maintenant que vous comprenez les canaux, vous êtes prêt à commencer à déployer des mises à jour en direct sur des appareils réels. Le processus de base est :

1. Installez le Capgo SDK dans votre application
2. Configurez l'application pour écouter votre canal souhaité
3. Envoyez une build et affectez-l’à ce canal
4. Lancez l'application et attendez l'actualisation !

Pour une présentation détaillée, consultez le Guide de mise à jour en direct guide. Bonne mise à jour !

Utilisation Avancée du Canal : Ségrégation des Utilisateurs

Les canaux peuvent être utilisés pour plus que les étapes de développement. Ils constituent un outil puissant pour la segmentation des utilisateurs, permettant des fonctionnalités comme :

• Feature flags for different user tiers
• Le test A/B
• Les lancements de fonctionnalités progressives
• Les programmes de test bêta

Apprenez à mettre en œuvre ces cas d'utilisation avancés dans notre guide : Comment segmenter les utilisateurs par plan et les canaux pour les drapeaux de fonctionnalités et le test A/B.

Continuez de là : les canaux

Si vous utilisez Les canaux planifier la routage du canal et la mise en production étape par étape, connectez-l’à Canaux pour les détails d'implémentation dans Canaux, Canaux pour les détails d'implémentation dans Canaux, Solution de test bêta pour le flux de travail du produit dans Solution de test bêta, Solution de ciblage de version pour le flux de travail du produit dans Solution de ciblage de version, et Capgo Pratiques d'environnement : Étapes avec un ID d'application mobile unique pour le contexte pratique dans Capgo Pratiques d'environnement : Étapes avec un ID d'application mobile unique.