Canaux

Un canal d'actualisation en direct pointe vers une version spécifique du build de votre application JS qui sera partagée avec tous les appareils configurés pour écouter ce canal pour les mises à jour. Lorsque vous installez les mises à jour en direct Capgo SDK In votre application, tout fichier binaire natif configuré pour ce canal vérifiera les mises à jour disponibles chaque fois que l'application est lancée. Vous pouvez modifier à tout moment le canal vers lequel pointe la construction et pouvez également revenir à des versions précédentes si nécessaire.

Les canaux ne fournissent pas de confidentialité.

Les canaux contrôlent l'éligibilité aux mises à jour, pas la secret des ensembles. Même si un canal est privé ou que la désignation automatique est désactivée, tout ensemble non chiffré chargé sur Capgo devrait toujours être considéré comme un actif public livré aux clients. La protection par chiffrement protège le chemin de livraison et l'authenticité des mises à jour, mais les ensembles expédiés peuvent toujours être déchiffrés à l'aide de suffisamment d'efforts car la clé publique fait partie du client. Voir Mise à jour en direct : 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. Cartographie de l'appareil forcé (Dashboard) – Fixez manuellement un ID d'appareil 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.
2. Surcharge de nuage (par appareil) via Dashboard ou API – Créé lorsque vous changez le canal du dispositif dans l'interface de dashboard ou via API. Utilisez-le pour les utilisateurs QA qui passent entre les canaux de fonctionnalité / PR ou pour reproduire un problème d'utilisateur. La suppression du fichier binaire ne le supprime pas ; la suppression de l'entrée du dispositif le supprime.
3. Plugin setChannel() canal local – Créé lorsque l'application appelle setChannel() et que le serveur valide que le canal cible autorise l'auto-assignation. Le canal sélectionné est stocké localement sur ce dispositif, prend effet instantanément et n'est pas affiché dans l'interface de surclassement du dispositif.

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 pour valider que le canal est autorisé (en vérifiant si l'auto-assignation est activée pour ce canal), puis stocke le canal sur le dispositif localement 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'à présent, setChannel() enregistrait la surcharge de canal dans la base de données backend (comme le tableau de bord ou API modifications), 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 depuis 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 surcharge de dispositif dans le Capgo tableau de bord. L'interface utilisateur de la surcharge de dispositif ne montre que les surcharges créées à partir du tableau de bord ou du Public API.

Remarque : Even si un canal devient interdit après avoir été configuré localement, le serveur backend valide toujours le canal lors des vérifications de mise à jour, afin de maintenir la sécurité.

Important : Lorsque 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—elle valide avec le serveur backend, puis configure 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é/override/local n'existe, l'application démarre sur ce canal (par exemple, beta, qa, pr-123). Conçu pour les builds TestFlight / internes afin que les testeurs atterrissent automatiquement sur un canal de pré-version.
5. Canal par défaut de 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 surcouche du tableau de bord/API, 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. Si vous avez des valeurs par défaut spécifiques aux plateformes (par exemple, un seul pour iOS, un seul pour Android, un seul pour Electron), chaque appareil se connecte au canal par défaut correspondant à sa plateforme. Laisser le canal par défaut de 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 tests ; lorsque vous définissez une valeur par défaut dans le cloud, les utilisateurs réels devraient y être dirigés. Si vous choisissez de ne pas la définir, soyez délibéré sur la façon dont les utilisateurs s'y attachent (généralement via defaultChannel Seul configurez
• dans les binaires que vous envoyez explicitement aux testeurs. Laisser cela non défini garde la logique de production centralisée dans le tableau de bord. defaultChannel Utilisez
• avec parcimonie en production—principalement pour les tests de qualité ou les diagnostics ciblés. setChannel() 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 loin dans la liste.

Résumé : Force > Tableau de bord/__CAPGO_KEEP_0__ Survol > Plugin

Summary: Force > Dashboard/API Override > Plugin setChannel() > Valeur par défaut dans le cloud. defaultChannel Comportement par défaut de la chaîne

Section intitulée « Comportement par défaut de la chaîne »

La mise en place d'un paramètre par défaut dans le cloud est facultative, mais elle 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 surcharges ou à defaultChannel le paramètre Capacitor config recevront des mises à jour. Lorsque vous choisissez de marquer les paramètres par défaut, gardez ces modèles à l'esprit :

• Paramètre par défaut unique (le plus courant) – Si un canal a iOS, Android et Electron activés, il devient le paramètre par défaut unique ; tout appareil sans surcharges s'y attache.
• Paramètres par défaut spécifiques à un appareil – 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 paramètre par défaut pour sa plateforme. Les appareils iOS se dirigent vers le paramètre par défaut iOS, les appareils Android vers le paramètre par défaut Android et les applications Electron vers le paramètre par défaut Electron.

Rappelez-vous que le paramètre par défaut dans le cloud et defaultChannel le paramètre __CAPGO_KEEP_0__ occupent le même niveau de décision. Si vous définissez un paramètre par défaut dans le cloud, vous n'avez pas besoin de dupliquer la valeur dans votre paramètre __CAPGO_KEEP_0__ config—laissez-le 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 vide pour les builds de production. Réservez 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 la valeur par défaut du cloud est différente.

Vous pouvez modifier les valeurs par défaut à tout moment dans le tableau de bord. Lorsque vous changez une valeur par défaut, les nouveaux appareils suivent immédiatement la nouvelle configuration de routage 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. Aller dans la section « Canaux » du 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 canaux peuvent être n'importe quoi que vous voulez. Une stratégie courante est de 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 votre équipe QA pour vérifier les mises à jour avant une large diffusion
• Staging - pour les tests finals dans un environnement similaire à la production
• Production - pour la version de votre application que les utilisateurs finals 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 __CAPGO_KEEP_0__.

Ouvrez votre capacitor.config.ts (ou capacitor.config.json) fichier. Dans la section plugins optionnellement définissez defaultChannel pour les versions de test (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 natifs continueront à utiliser le canal dont ils étaient précédemment configurés.

Attention

Ordre de sélection du canal : Force > Dashboard/API surcharge de l'appareil > 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 une surcharge ultérieurement — celles-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 ont 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, du CLI, ou du Public API.

• Canal par défaut : Marquez optionnellement le canal ou les canaux spécifiques au plateau qui les nouveaux appareils s'attachent. 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 vers les builds de développement (utile pour les tests).
• Permettre les appareils émulateurs : Autoriser les mises à jour vers les émulateurs/simulateurs (utile pour les tests).
• Permettre l'auto-assignation des appareils : Permet à l'application de passer à ce canal en temps de exécution à l'aide de setChannel. Si désactivé, setChannel se produira une erreur pour ce canal.

Déroulement progressif

Un canal peut conserver un bundle stable tout en exposant progressivement une cible de déroulement distincte à un groupe de dispositifs collés. Vous pouvez mettre en pause, reprendre, promouvoir, revenir en arrière et configurer une réponse automatique à une erreur sans passer par le canal pour tout le monde. Voir Déroulement progressif 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'actualisation automatique

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

• majeur : Bloc un bundle cible dont la version majeure est supérieure à la base de ligne de code native du dispositif (version_buildExemple : 1.2.3 -> 2.0.0 is bloqué ; 1.2.3 -> 1.9.0 is autorisé.
• mineur : Bloque un ensemble cible dont la version majeure ou mineure diffère de version_build. Exemple : 1.2.3 -> 1.3.0 is bloqué ; 1.2.3 -> 1.2.4 is autorisé.
• patch : Mode le plus strict. Bloque toute modification de numéro de version majeure, mineure ou de patch. Seules les modifications de suffixe sont autorisées tandis que MAJOR.MINOR.PATCH reste identique. Exemples : 1.0.0-beta.1 -> 1.0.0-beta.2 is autorisé, 1.0.0+build.1 -> 1.0.0+build.2 is autorisé, 1.0.0 -> 1.0.1 is bloqué.
• méta-données : Exige une version d'actualisation minimale de méta-données sur chaque ensemble. Configurez via CLI à l'aide de --min-update-version ou --auto-min-update-version. Si elle manque, le canal est marqué comme non configuré et les mises à jour seront rejetées jusqu'à ce qu'elle soit définie.
• aucune: Autoriser toutes les mises à jour selon la compatibilité de semver Ces stratégies comparant le bundle cible du canal avec le plan de base natif envoyé sous la forme.

, et non le bundle téléchargé actuel envoyé sous la forme version_buildEn savoir plus sur les détails et les exemples dans la stratégie de désactivation des mises à jour à /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy. version_name.

Exemple (cli):

Example (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

Section intitulée “En utilisant setChannel() de Votre Application”

The method allows your app to switch channels programmatically at runtime. This is particularly useful for: setChannel() Les menus de test/QA où les testeurs peuvent switcher entre les canaux

• Les flux d'inscription au programme bêta
• Les implémentations des drapeaux de fonctionnalité
• Les scénarios de test A/B
• Copier dans le presse-papier

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

Lorsque est appelé:

La validation back-end (lecture seule) setChannel() __CAPGO_KEEP_0__

1. __CAPGO_KEEP_0__: 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'autorisation de l'instance)
2. La mise à jour de la zone de stockage locale: Si la validation passe, le canal est enregistré dans la zone 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 l'override du canal dans la base de données de l'arrière-plan (même chose que les modifications du tableau de bord ou API). Les appareils devaient attendre la réplication de l'arrière-plan (jusqu'à 2 minutes) avant que le changement de canal prenne effet. Maintenant, setChannel() n'effectue que des lectures de l'arrière-plan (pour la validation) et stocke localement, ce qui fait que les changements de canal sont instantanés.

Visibilité du tableau de bord : Un canal défini avec le plugin ne fait pas apparaître le dispositif comme un Override de dispositif dans l'interface utilisateur de Capgo. Seuls les affectations de canal créées à partir du tableau de bord ou de l'instance publique API sont listées là. Utilisez le tableau de bord ou API lorsque vous avez besoin d'un override visible par l'administrateur.

Note de sécurité : Even si les permissions d'un canal changent après avoir été définies localement (par exemple, la mise en place de l'auto-assignation est désactivée), le serveur backend validera toujours le canal lors des vérifications d'actualisation, garantissant ainsi la sécurité.

Comparaison des méthodes de changement de canal :

Méthode	Durée de l'effet	Persistance	Affiché dans l'interface utilisateur de la prise en charge de la mise à jour du périphérique	Utilisation
setChannel() à partir du plugin	Instantané	Seulement sur le périphérique (local)	Non	Changement de canal initié par l'utilisateur en application
Tableau de bord de la mise à jour du périphérique	Jusqu'à 2 min	Base de données backend	Oui	Mises à jour spécifiques pour les appareils initiées par l'administrateur
Affectation du canal API	Jusqu'à 2 min	Base de données backend	Oui	Intégrations backend automatiques

Pour une expérience utilisateur optimale lors de la création d'interfaces utilisateur de basculement de canal, utilisez toujours la méthode du plugin. setChannel() ]}

Versions minimales pour le basculement du 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 installation de 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 faire 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.

You 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.

Versionnement des Bundles et des 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 versionnement semantique avec le Capgo Semver Tester et les identificateurs de pré-version pour les builds spécifiques aux canaux. Par exemple, une version bêta pourrait être versionnée comme 1.2.3-beta.1.

Cette approche présente plusieurs avantages :

• Elle communique clairement la relation entre les builds. 1.2.3-beta.1 est évidemment une pré-version de 1.2.3.
• Cela permet de réutiliser les numéros de version dans plusieurs canaux, réduisant la confusion.
• Cela permet des chemins de reversion clairs. Si vous avez besoin de revenir à 1.2.3, vous savez 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.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.

Utilisez __CAPGO_KEEP_0__ avec des identifiants de version préalables C'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.

Rembobiner une mise à jour en direct

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

1. Cliquez sur le nom du canal que vous souhaitez rembobiner
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 rembobinée 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 d'actualisation en direct en tant que partie de votre pipeline CI/CD. En intégrant Capgo à votre processus de construction, 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 pour en savoir plus sur l'automatisation des mises à jour en direct de Capgo.

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. Téléchargez une build et affectez-la à ce canal
4. Lancez l'application et attendez l'actualisation !

Pour une présentation détaillée, voir les Mise à jour en temps réel 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 :

• Drapeaux de fonctionnalité pour les différents niveaux d'utilisateurs
• Tests A/B
• Rollout de fonctionnalités progressives
• Programmes de test bêta

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

Continuez à partir des canaux

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