Canal

Un canal d'actualisation en temps réel 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 canal d'actualisation en temps réel Capgo de SDK dans votre application, tout binaire natif configuré pour ce canal vérifie les mises à jour disponibles chaque fois que l'application est lancée. Vous pouvez modifier la version du build que pointe le canal à tout moment et pouvez également revenir à des versions précédentes si nécessaire. Les canaux ne fournissent pas de confidentialité.

Les canaux ne fournissent pas de confidentialité.

Les canaux contrôlent l'éligibilité aux mises à jour, pas la sécrétion des lots. Même si un canal est privé ou que la mise à jour automatique est désactivée, tout lot non chiffré uploadé à Capgo devrait toujours être considéré comme un actif public livré aux clients. La protection de la voie de livraison et de l'authenticité des mises à jour protège la confidentialité, mais les lots expédiés peuvent toujours être déchiffrés à partir de l'application distribuée avec suffisamment d'effort car la clé publique fait partie du client. Voir La chiffrage des mises à jour en direct pour plus de détails.

Comment un appareil choisit un canal (prépondérance)

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. La mise à jour forcée du dispositif (tableau de bord) – Fixez manuellement un ID de dispositif spécifique à un canal. Utilisez pour le débogage urgent ou le test contrôlé avec un seul utilisateur réel. Cela gagne toujours. Capgo supprime la mise à jour 90 jours après la dernière écriture de mise à jour. Voir Les mises à jour de la console et API expirent après 90 jours.
2. La mise à jour de Cloud (par appareil) via le 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 réinstallation du binaire ne le supprime pas ; la suppression de la mise à jour de l'appareil 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 de 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 immédiatement pour la prochaine vérification de mise à jour—pas d'attente pour la réplication.

Jusqu'alors, setChannel() enregistrait le canal de substitution 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 rend les changements de canal instantanés.

Parce que setChannel() est local-only, il ne crée pas d'entrée de substitution de appareil dans le tableau de bord de Capgo. L'interface utilisateur de la substitution de appareil ne montre que les substitutions créées à partir du tableau de bord ou du Public API.

Remarque : Même si un canal devient interdit après avoir été défini localement, le backend valide toujours le canal pendant les vérifications de mise à jour, de sorte que la sécurité est maintenue.

Importants : Quand des modifications de canal sont effectuées via le tableau de bord ou API, il peut y avoir 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() à partir de votre application code—il valide avec le serveur de backend, 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'aucun canal forcé/forcé/local n'existe, 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 (aucune force, aucun tableau de bord/API de surcharge, aucun plugin local canal, aucune configuration defaultChannel) 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 iOS uniquement, un Android uniquement, un Electron uniquement), 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.

Pratique recommandée :

• Traitez 1-4 comme des couches d'exception / de test ; quand vous définissez un canal par défaut cloud, les utilisateurs réels devraient s'y connecter. Si vous choisissez de ne pas le définir, soyez délibéré sur la façon dont les utilisateurs s'y attachent (généralement via defaultChannel en config ou en surcharges par appareil).
• 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() avec parcimonie en production—principalement pour les tests ou les diagnostics ciblés.

S'il 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 Cloud.

Console et API survol expirent après 90 jours

Les mappages imposés et les survol de Tableau de bord ou 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 la mise à jourLa vérification de mise à jour n'arrête pas ce chronomètre. Seule l'écriture de la mise à jour à nouveau (ou la suppression par vous-même) change la date.

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

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

• Définir defaultChannel dans capacitor.config.* (survient à la réinstallation; nécessite un nouveau code natif pour changer plus tard).
• Appeler setChannel() à partir de l'application. Sur le plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 et ultérieur, cette affectation est locale et n'est pas supprimée par cette suppression. La réinstallation de l'application la supprime, il faut donc appeler setChannel() à nouveau si vous voulez toujours ce canal.

L'actualité en direct Appareils tab and the device Override UI only list console and Public API assignments. They do not list every device on the channel, and they do not list local setChannel() Les affectations.

Remarque de rétention d'override sur la page des appareils du canal.

Comportement par défaut du canal

Fixer un canal par défaut est facultatif, mais il sert généralement de chemin par défaut pour les nouveaux appareils. Sans cela, seuls les appareils qui correspondent aux mappages forcés, aux overrides ou à un defaultChannel config dans le Capacitor config recevront des mises à jour. Lorsque vous choisissez de marquer les canaux par défaut, gardez ces modèles à l'esprit :

• Un canal par défaut unique (la plupart des cas) – Si un canal a iOS, Android et Electron activés, il devient le canal par défaut unique ; tout appareil sans overrides s'y attache.
• Paramètres par plateforme par défaut – 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 par défaut pour sa plateforme. Les appareils iOS se dirigent vers le canal par défaut iOS, les appareils Android se dirigent vers le canal par défaut Android, et les applications Electron se dirigent vers le canal par défaut Electron.

Rappelez-vous que le canal par défaut cloud et defaultChannel les deux occupent le même niveau de décision. Si vous définissez un canal par défaut cloud, vous n'avez pas besoin de dupliquer la valeur dans votre __CAPGO_KEEP_0__ config—laissez 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 pour les binaires que vous envoyez intentionnellement aux testeurs ou à la QA lorsque vous voulez qu'ils commencent sur un canal non de production même si le canal par défaut cloud est différent. defaultChannel Vous pouvez modifier les canaux par défaut à tout moment dans le tableau de bord. Ouvrez le canal, puis

Gérer dans les paramètres de l'application Paramètres par plateforme par défautqui vous mène à Informations sur l'application. La 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

Durant 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 l'Capgo tableau de bord
2. Cliquez sur le bouton « Nouveau Canal »
3. Entrez un nom pour le canal et cliquez sur « Créer »

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

• Development - pour tester les mises à jour en direct sur les appareils locaux ou les émulateurs
• QA - pour que votre équipe QA vérifie les mises à jour avant une diffusion plus large
• Staging - pour les tests finals dans un environnement simulant la production
• Production - pour la version de votre application que les utilisateurs finaux reçoivent depuis les magasins d'applications

Configuration du canal dans votre application

Une fois vos canaux créés, vous devez configurer votre application pour écouter le bon canal. Dans cet exemple, nous utiliserons le Development canal.

Ouvrez votre capacitor.config.ts (ou capacitor.config.json) fichier. Dans la section plugins optionnellement définissez defaultChannel pour les builds de test context (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 vers vos projets iOS, Android et Electron. Si vous passez cette étape de synchronisation, vos projets natifs continueront d'utiliser le canal auquel ils étaient précédemment configurés.

Attention

Ordre de sélection du canal : Force > API du panneau de bord du dispositif > Plugin setChannel() canal local > Config defaultChannel > Valeur par défaut de Cloud.

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

Vous pouvez toujours forcer (fixer) un appareil ou appliquer un surcroît ultérieurement — ceux-ci supplantent immédiatement la valeur de la config.

Les noms de canal 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 optionnellement le canal ou les canaux spécifiques au plateau qui sont attachés aux nouveaux appareils. Dans la console, cela se trouve dans l'information de l'application (Gérer dans les paramètres de l'application à partir de la page du canal). Voir « Comportement du canal par défaut » pour les scénarios de routage.
• Filtres de plateforme : Activer ou désactiver la livraison vers les appareils iOS, Android, ou 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 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 des builds de développement (utiles pour les tests). CLI : --dev / --no-dev.
• Permettre les builds de production : Autoriser les mises à jour des builds de production (magasin). Laissez cela activé pour les canaux qui servent des utilisateurs réels. CLI: --prod / --no-prod.
• Permettre les appareils émulateurs : Autoriser les mises à jour des émulateurs/simulateurs (utiles pour les tests). CLI: --emulator / --no-emulator.
• Permettre les 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 des appareils : Permet à l'application de passer à ce canal en temps de exécution à l'aide de setChannelSi désactivé, setChannel échouera pour ce canal. CLI: --self-assign / --no-self-assign.
• Package de mise à jour : Choisissez si les appareils téléchargent un zip complet, un delta de fichiers modifiés ou les deux (all, zip, delta, zip_from_builtin, delta_from_builtinVoir Package de mise à jour pour le menu déroulant de la console et pour savoir quand chaque mode est utile.

Rollouts progressifs

A un canal peut conserver un bundle stable tout en exposant progressivement une cible de mise à jour séparée à un groupe de dispositifs collants. Vous pouvez mettre en pause, reprendre, promouvoir, annuler et configurer une réponse automatique à une erreur sans passer le canal pour tout le monde. Voir Les mises à jour progressives pour le modèle de livraison, le flux de travail de tableau de bord, les champs API et les commandes CLI.

Désactiver les stratégies d'Auto Mise à jour

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

• majeur : Bloc un bundle cible dont la version majeure est supérieure à la base de ligne de version native du dispositif (version_buildExemple : 1.2.3 -> 2.0.0 est bloqué ; 1.2.3 -> 1.9.0 est autorisé.
• mineur : Bloc un bundle 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é.
• patch : mode le plus strict. Bloque toute modification du numéro majeur, mineur ou de patch. Seules les modifications de suffixe sont autorisées pendant MAJOR.MINOR.PATCH se maintient identique. 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 : Exigez une version minimale d'actualisation de métadonnées sur chaque bundle. Configurez via CLI à l'aide de --min-update-version ou --auto-min-update-versionSi manquant, le canal est marqué comme non configuré et les mises à jour seront rejetées jusqu'à ce qu'il soit défini.
• aucune : Autorise toutes les mises à jour selon la compatibilité de semver.

Ces stratégies comparant la cible du canal avec la base native envoyée comme version_build, et non la version téléchargée actuelle envoyée comme version_name.

Découvrez plus 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() de Votre Application

Cette setChannel() méthode permet à votre application de passer programmationnellement entre les canaux en temps de exécution. Cela est particulièrement utile pour :

• Menus QA/débogage où les testeurs peuvent passer entre les canaux
• Flux d'adhésion au programme bêta
• Mise en œuvre des 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 le back-end Capgo pour valider que le canal est autorisé (en vérifiant les permissions d'autorisation auto-assignation)
2. Mise à jour de la mémoire de stockage locale : Si la validation passe, le canal est enregistré dans la mémoire de stockage locale du dispositif comme 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 anciennes versions, 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() se contente de lire dans le backend (pour la validation) et stocke localement, 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 un surclasseur de dispositif dans l'interface utilisateur Capgo. Seuls les affectations de canal créées à partir du tableau de bord ou de l'espace public API sont listés là. Utilisez le tableau de bord ou API lorsque vous avez besoin d'une surclasseur 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 self-assignment est désactivée), le backend validera toujours le canal lors des vérifications de mise à jour, garantissant ainsi la sécurité.

Comparaison des méthodes de changement de canal :

Méthode	Durée d'effet	Sauvegardé où	Affiché dans l'interface utilisateur de défaillance de l'appareil	Expire	Utilisation
setChannel() context : Page/zone : Page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page solutions/cordova-to-capacitor-ai.astro. Clé de message `solutions_cordova_to_capacitor_ai_table_use_case` (Solutions Cordova To Capacitor Ai Table Use Case).	à partir du plugin	Instantané	Seulement sur l'appareil (local)	Non	Non (jusqu'à ce que vous le modifiiez ou le réinstallez)
Switching de canal initié par l'utilisateur en application	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de mise à jour	Mises à jour administratives pour des appareils spécifiques
API affectation de canal	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de mise à jour	Intégrations backend automatiques

Pour offrir la meilleure expérience utilisateur lors de la création d'interfaces utilisateur de basculement de canal, utilisez toujours le plugin setChannel() méthode.

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). Consultez l'installation d'un plugin pour les étiquettes de version.

Attribution d'un Bundle à un Canal

Pour déployer une mise à jour en direct, 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 Le canal. Tous 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 des builds à des canaux à partir de la section « Bundles » de l'Capgo tableau de bord. Cliquez sur l'icône de menu à côté d'une build et sélectionnez « Affecter à un canal » pour choisir le canal pour cette build.

La versionnement des Bundles et des canaux

Il est important de noter que les bundles dans Capgo sont globaux à 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 versionnement semantique avec le Capgo Semver Tester et les identificateurs de pré-version pour les builds spécifiques à un canal. Par exemple, une version bêta pourrait être versionnée comme 1.2.3-beta.1.

Lorsque vous utilisez la CI, si la version locale a déjà été téléchargée, utilisez npx @capgo/cli@latest bundle upload --auto-bump (optionnellement) major, minor, patch/fix, metadata, ou) aiafin que CLI augmente de la version du canal liée au bundle jusqu'à trouver un nom disponible. ai, Workers AI déduit le niveau à partir du manifeste local par rapport à la précédente delta (retourne à patch avec aucune version précédente Capgo). Vous ne pouvez pas le combiner avec --bundle. Voir Intégration CI/CD context : Page/zone : Page de produit de construction native / native cloud build product page. Rôle : Étiquette de navigation ou élément UI court. Clé de message `native_build_feature_ci_cd` (Native Build Feature Ci Cd). CLI reference.

__CAPGO_KEEP_0__ référence

• Cette approche présente plusieurs avantages : 1.2.3-beta.1 Elle communique clairement la relation entre les builds. 1.2.3.
• est manifestement une pré-version de
• Elle permet de réutiliser les numéros de version dans plusieurs canaux, réduisant la confusion. 1.2.3Elle permet des chemins de rebond clairs. Si vous devez revenir à une version précédente de 1.2.2 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.2etc.
• QA canal : 1.2.3-qa.1, 1.2.3-qa.2etc.
• Staging canal : 1.2.3-rc.1, 1.2.3-rc.2etc.
• Production canal : 1.2.3, 1.2.4etc.

En utilisant semver avec des identifiants de version préliminaire 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 une mise à jour en direct

Si vous dépuez une mise à jour en direct qui introduit une erreur ou qui doit être réversée, vous pouvez facilement annuler la mise à jour en direct vers une version précédente. À partir de la section « Canaux » de la console :

1. Cliquer 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. Confirmer 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érifient les mises à jour.

Automatiser les déploiements

Pour des workflows plus avancés, vous pouvez automatiser vos déploiements de mise à jour en direct 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 vers certaines branches ou créez de nouvelles versions.

Consultez les Intégration CI/CD docs to learn more about automating Capgo live updates.

Prévisualisations de demande de tirage avec les moins de privilèges

Utilisez un Prévisualisation d'application une clé API lorsqu'un CI en a besoin pour un 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 tout simplement pas de rôl’organisationnel.

1. Disposez-vous d'un administrateur d'organisation qui crée une clé API sécurisée limitée à l'application de prévisualisation et sélectionnez Prévisualisation d'application. Consultez les Clés API.
2. Utilisez un canal unique, non public tel que pr-123Ne passez pas --default, --self-assign, les options de déploiement, ou --delete-linked-bundle-on-upload.
3. Téléchargez et promouvez le bundle PR en une seule commande, puis supprimez ensuite le canal et le bundle propriétés 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 bundle et le promeut en une seule opération. La suppression est atomique et vérifie la propriété : la clé ne peut supprimer qu'un canal qu'elle a créé et son bundle lié, non partagé. Elle ne peut pas modifier, promouvoir ou supprimer un canal principal par défaut existant, un canal de visionnage d'un autre clé, ou un bundle d'une autre clé.

Si les réviseurs ont besoin d'un QR code ou d'une URL de visionnage, un administrateur doit activer les aperçus une fois pour l'application :

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

Une clé de visionnage d'application ne peut pas activer les aperçus elle-même car elle n'a pas la permission d'application-settings. Dans GitHub Actions, exécutez les tâches de visionnage secrètes sur pull_request, pas pull_request_target, et limitez-les aux PRs du même dépôt avec github.event.pull_request.head.repo.full_name == github.repository.

Déployer sur 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'update !

Pour une procédure détaillée, consultez le Mise à jour en direct guide. Bonne mise à jour !

Utilisation avancée des canaux : segmentation 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 :

• Des drapeaux de fonctionnalité pour différents niveaux d'utilisateurs
• Des tests A/B
• Des lancements de fonctionnalités progressives
• Des programmes de test bêta

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

Continuez de la section Canaux

Si vous utilisez Les canaux pour planifier la mise en route 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 : Staging avec un ID d'application mobile unique pour le contexte pratique dans Capgo Pratiques d'environnement : Staging avec un ID d'application mobile unique.