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 Capgo en direct SDK dans votre application, tout binôme natif configuré sur 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 sécrétion du paquet. Même si un canal est privé ou que la désignation automatique est désactivée, tout paquet non chiffré chargé sur Capgo devrait toujours être considéré comme un actif public délivré aux clients. La cryptage protège le chemin de livraison et l'authenticité des mises à jour, mais les paquets expédiés peuvent toujours être déchiffrés à l'aide de suffisamment d'efforts car la clé publique fait partie du client. Voir La cryptage des mises à jour en direct 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. La mise en correspondance du dispositif forcé (tableau de bord) – Fixez 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.
2. Surcharge Cloud (par appareil) via le tableau de bord ou API – Créé lorsque vous changez le canal de l'appareil dans le tableau de bord 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 de l'appareil 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 cet appareil, prend effet instantanément et n'est pas affiché dans l'interface de surcharge 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 pour valider That le canal est autorisé (en vérifiant si l'auto-assignation est activée pour ce canal), puis stocke ensuite le canal localement sur le dispositif comme defaultChannel. Cela signifie que le nouveau canal prend effet instantanément pour la prochaine vérification de mise à jour—sans attendre la réplication.

Jusqu'à présent, setChannel() enregistrait le canal de substitution dans la base de données backend (comme le tableau de bord ou les modifications 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 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 substitution de dispositif dans le tableau de bord __CAPGO_KEEP_0__. L'interface utilisateur de la substitution de dispositif ne montre que les substitutions créées à partir du tableau de bord ou du Public __CAPGO_KEEP_1__. create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Note: Même 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—il valide avec le serveur backend, puis configure le canal localement pour un effet immédiat.

4. Capacitor config 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-123). Conçu 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 surcharge/API, sans canal local de plugin, sans config defaultChannel) 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 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 exceptions / couches de test ; lorsque vous définissez une valeur par défaut dans le cloud, les utilisateurs réels devraient y accéder. 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 en config ou en surcharges par appareil).
• Configurez uniquement defaultChannel 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.
• Utilisez setChannel() avec parcimonie en production—principalement pour les tests de qualité 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 saute et continue dans la liste.

Résumé : Force > Tableau de bord/API Survol > Plugin setChannel() canal local > Config defaultChannel > Canal par défaut du cloud.

Comportement par défaut du canal

La définition d'une chaîne par défaut dans le cloud est facultative, mais elle sert généralement de chemin par défaut pour les nouveaux appareils. Sans elle, seuls les appareils qui correspondent aux mappages imposés, aux surcharges ou à la defaultChannel Capacitor config recevront des mises à jour. Lorsque vous choisissez de marquer des chaînes par défaut, gardez ces modèles à l'esprit :

• Chaîne par défaut unique (la plus courante) – Si une chaîne a iOS, Android et Electron activés, elle devient la seule chaîne par défaut ; tout appareil sans surcharges s'y attache.
• Chaînes par défaut spécifiques aux plateformes – Si vous divisez les chaînes 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 une comme la chaîne par défaut de sa plateforme. Les appareils iOS se dirigent vers la chaîne par défaut iOS, les appareils Android vers la chaîne par défaut Android et les applications Electron vers la chaîne par défaut Electron.

Rappelez-vous que la chaîne par défaut dans le cloud et la defaultChannel __CAPGO_KEEP_0__ capacitor.config.* Les deux occupent le même niveau de décision. Si vous définissez un cloud par défaut, vous n'avez pas besoin de dupliquer la valeur dans votre Capacitor config—laissez 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 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 bloqué—you pouvez renommer ou supprimer n'importe quel canal à tout moment. Pour ajouter des canaux supplémentaires ultérieurement:

1. Allez 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 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 que votre équipe QA vérifie les mises à jour avant une diffusion plus large
• Staging - pour les tests finals dans un environnement de production similaire
• Production - pour la version de votre application que les utilisateurs finals reçoivent depuis les magasins d'applications

Configurer le 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. Sous la plugins section, définissez optionnellement defaultChannel pour tests de construction (intérieur / QA). Pour les constructions de production, préférez l'omettre afin que les appareils utilisent le Cloud par défaut, à moins d'avoir explicitement défini autre chose.

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 définir le canal par appareil > Plugin setChannel() canal local > Config defaultChannel > par défaut du Cloud.

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

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

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 éléments à partir de l'application web, du CLI, ou de Public API.

• Canal par défaut : Marquez facultativement 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 (utiles pour les tests).
• Permettre les appareils émulateurs : Autoriser les mises à jour vers les émulateurs/simulateurs (utiles pour les tests).
• Autoriser l'auto-assignation du dispositif : Permet à l'application de passer à ce canal en temps de exécution à l'aide de setChannel Si désactivé, setChannel ne fonctionnera pas pour ce canal.

Désactiver les stratégies d'auto-mise à jour

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

• majeur : Bloc un paquet cible dont la version majeure est supérieure à la base de ligne de version native du dispositif (version_build) Exemple : 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é.
• 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 reste 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 en utilisant --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 configuré.
• none : Autorise toutes les mises à jour conformes à la compatibilité de semver.

Ces stratégies comparant la charge utile ciblée du canal avec la base native envoyée comme version_buildet non la charge utile téléchargée actuelle envoyée comme version_name.

En savoir plus sur les détails et les exemples dans la stratégie de désactivation des mises à jour à /docs/cli/commands/#disable-updates-strategy.

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

En utilisant setChannel() de Votre Application

Le setChannel() méthode permet à votre application de passer manuellement entre les canaux en temps de 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 tests 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 backend Capgo pour valider que le canal est autorisé (en vérifiant les permissions d'autorisation auto)
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 mise à jour du canal dans la base de données backend (même chose que les modifications du API ou du tableau de bord). Les appareils devaient attendre la réplication backend (jusqu'à 2 minutes) avant que la mise à jour du canal prenne effet. Maintenant, setChannel() se contente de lire dans le backend (pour la validation) et stocke localement, ce qui fait que les changements de canal sont instantanés.

Affichage du tableau de bord : Un canal défini avec le plugin n'oblige pas l'appareil à apparaître comme un appareil avec une mise à jour personnalisée dans l'interface utilisateur du 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'une mise à jour visible par l'administrateur.

Avertissement de sécurité : Même si les permissions d'un canal changent après avoir été définies localement (par exemple, la mise à jour de l'auto-assignation est désactivée), le backend validera 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	Enregistré où	Affiché dans l'interface utilisateur de la mise à niveau du dispositif	Utilisation
setChannel() à partir du plugin	Instantané	Seulement le dispositif (local)	Non	Changement de canal initié par l'utilisateur en application
Survol du dispositif dans l'interface utilisateur de la console	Jusqu'à 2 min	Base de données backend	Oui	Modifications initiées par l'administrateur pour des appareils spécifiques
API affectation de canal	Jusqu'à 2 min	Base de données backend	Oui	Intégrations backend automatiques

Pour obtenir la meilleure expérience utilisateur 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 de canal local uniquement:

, ou 5.34.0, 6.34.0, 7.34.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 8.0.0 installation du plugin Intégrations backend automatiques pour les canaux pour les étiquettes de version.

Attribuer 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. 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 attribuer des builds à des canaux à partir de la section “Bundles” de la Capgo console. Cliquez sur l'icône de menu à côté d'un build et sélectionnez “Attribuer à 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 attribué à plusieurs canaux.

When vous versionnez vos bundles, nous vous recommandons d'utiliser la versionnement semantique avec __CAPGO_KEEP_0__’s Tester Semver et des identifiants de version préalable pour les builds spécifiques au canal. Par exemple, une version bêta pourrait être versionnée comme semantic versioning with Capgo’s Semver Tester Elle communique clairement la relation entre les builds. 1.2.3-beta.1.

est clairement une version préalable de

• Cela permet de réutiliser les numéros de version dans les canaux, réduisant la confusion. 1.2.3-beta.1 Cela permet des chemins de rebond clairs. Si vous devez revenir à 1.2.3.
• , vous savez que
• est la version stable précédente. 1.2.3Voici un exemple de la façon dont vous pourriez aligner les versions de vos bundles avec un setup de canal typique : 1.2.2 canal :

channel:

• Development channel: 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.

Utilisation Utiliser semver avec des identifiants de version préalables 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

If vous déploiez une mise à jour en direct qui introduit une erreur ou doit être rétablie, vous pouvez facilement revenir à une version précédente. À partir de la section « Canaux » de la console :

1. Clicker 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 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 Capgo en direct.

Déploiement 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, consultez le Déploiement de Mises à Jour en Ligne guide. Bonne actualisation !

Utilisation avancée des canaux : segmentation des utilisateurs

Les canaux peuvent être utilisés pour plus que les étapes de développement. Ils sont 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 par plan et canaux pour les drapeaux de fonctionnalité et les tests A/B.

Continuez de la section « Continuez de la section canaux »

les canaux pour planifier la routage des canaux et le lancement étape par étape, connectez-le avec __CAPGO_KEEP_0__ 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 de meilleures performances pour l'environnement : mise en scène avec un seul ID d'application mobile pour le contexte pratique dans Capgo Pratiques de meilleures performances pour l'environnement : mise en scène avec un seul ID d'application mobile.