Canal

Un canal de mise à jour en direct 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 les mises à jour en direct Capgo SDK In votre application, tout fichier binaire natif configuré pour ce canal vérifie 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é télé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 à rebours à partir de l'application distribuée avec suffisamment d'effort car la clé publique fait partie du client. Voir Mise à jour en direct chiffrée 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é (Tableau de bord) – 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 Tableau de bord 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.

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 l'arrière-plan pour valider que le canal est autorisé (en vérifiant si l'autorisation de mise à jour est activée pour ce canal), puis stocke le canal localement sur le dispositif comme defaultChannelCela signifie que le nouveau canal prend effet instantanément pour la prochaine mise à jour, pas d'attente pour la réplication.

Jusqu'à présent, setChannel() enregistrait la mise à jour de la chaîne 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 la nouvelle chaîne soit reconnue. Le nouveau comportement ne lit que depuis le backend (pour la validation) et stocke localement, ce qui rend les changements de chaîne instantanés.

Remarque : Même si une chaîne devient interdite après avoir été définie localement, le backend validera toujours la chaîne lors des vérifications de mise à jour, ce qui maintient la sécurité.

Important : Lorsque les modifications de chaîne sont effectuées via le tableau de bord ou API, il y a toujours un retard de réplication de jusqu'à 2 minutes avant que tous les serveurs de bord réfléchissent le changement. Pour un changement de chaîne instantané, utilisez setChannel() à partir de votre application code—il valide avec le backend, puis définit la chaîne localement pour un effet immédiat.

3. configurateur de Capacitor defaultChannel (défaut de build de test) – Si présent dans capacitor.config.* et qu'aucune force/override n'existe, l'application démarre sur cette chaîne (par exemple. beta, qa, pr-123Intégré pour les versions de test TestFlight / internes afin que les testeurs atterrissent automatiquement sur un canal de pré-lancement.
4. 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, sans config defaultChannel) s'y attachent. Changez-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-3 pour recevoir des mises à jour.

Meilleure pratique :

• Traitez 1-3 comme des couches d'exception / de test ; lorsque vous définissez un canal par défaut, les utilisateurs réels devraient y fluer. 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 par des surcharges par appareil).
• Configurez-le defaultChannel seulement dans les versions 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-le setChannel() rarement 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 bascule) lorsqu'il serait autrement choisi, le processus de sélection le passe et continue sur la liste.

Résumé : Force > Surcharge > Config defaultChannel > Par défaut Cloud.

Comportement par défaut du canal

La définition d'un par défaut 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 imposés, aux surcharges ou à un defaultChannel config Capacitor recevront des mises à jour. Lorsque vous choisissez de marquer les valeurs par défaut, gardez ces modèles à l'esprit :

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

N'oubliez pas que les paramètres par défaut du cloud et defaultChannel et capacitor.config.* s'occupent du même niveau de décision. Si vous définissez un paramètre par défaut du cloud, vous n'avez pas besoin de dupliquer la valeur dans votre Capacitor configuration—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 le paramètre par défaut du cloud est différent.

Vous pouvez modifier les paramètres par défaut à tout moment dans le tableau de bord. Lorsque vous changez un paramètre 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 canal peuvent être n'importe quoi que vous souhaitiez. 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 votre équipe QA pour vérifier les mises à jour avant une large diffusion
• 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

Configuration du Canal dans Votre Application

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

Ouvrez votre capacitor.config.ts (ou capacitor.config.json) fichier. Sous la plugins Si vous le souhaitez, configurez cette section defaultChannel pour les builds de test (intérieur / QA). Pour les builds de production, préférez l'omettre 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 dont ils étaient précédemment configurés.

Attention

Ordre de sélection des canaux : Force > Surcharger (setChannel / tableau de bord) > Config defaultChannel > Valeur par défaut de Cloud.

Utilisez uniquement 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 routage dans la configuration native. defaultChannel Vous 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

Sous-titre : Options et stratégies de canal

Channels have several options that control who can receive updates and how updates are delivered. The most important ones are below. You can configure these from the web app, the CLI, or the Public API.

• Filtres de plateforme : Activer ou désactiver la livraison vers les appareils
• ou iOS, Androidappareils par canal. Electron 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).
• Filtres de plateforme : Activer ou désactiver la livraison vers les appareils
• Permettre les builds de développement : Autorisez les mises à jour des builds de développement (utiles pour les tests).
• Permettre aux appareils d'émulateur : Autorisez les mises à jour des émulateurs/simulateurs (utiles pour les tests).
• Permettre à l'appareil de se réassigner : Permet à l'application de passer à ce canal en temps de exécution à l'aide de setChannel. Si désactivé, setChannel échouera pour ce canal.

Désactiver les stratégies d'actualisation automatique

Utilisez cela pour restreindre lesquels types de mises à jour le canal livrera automatiquement. Options :

• majeur : Bloquer les mises à jour transversales majeures (0.0.0 → 1.0.0). Les mises à jour mineures et de correctif sont toujours autorisées.
• mineur : Bloquer les mises à jour transversales mineures (par exemple, 1.1.0 → 1.2.0) et majeures. Les mises à jour de correctif sont toujours autorisées. Remarque : ne bloque pas 0.1.0 → 1.1.0.
• correctif : Très strict. N'autorise que les versions de correctif augmentées dans le même majeur et mineur. Exemples : 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• méta-données : Exigez une version minimale de mise à jour de méta-données sur chaque bundle. Configurez via CLI --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é semver.

En savoir plus sur les détails et les exemples dans 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() Cette méthode permet à votre application de passer manuellement entre les canaux en temps de exécution. Cela est particulièrement utile pour :

• Menus QA/Debug où les testeurs peuvent passer entre les canaux
• Flux d'adhésion au programme bêta
• Implémentations 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+)

Quand 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 de mise à jour)
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 defaultChannel
3. Effet instantané: La prochaine vérification de mise à jour utilise immédiatement le nouveau canal (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 de API ou du tableau de bord). Les appareils devaient attendre la réplication backend (jusqu'à 2 minutes) avant que le changement de canal prenne effet. Maintenant, setChannel() n'importe quel appareil ne lit que dans le backend (pour la validation) et stocke localement, ce qui rend les changements de canal instantanés.

Note de sécurité : Même si les permissions d'un canal changent après avoir été définies localement (par exemple, l'autorisation d'auto-assignation 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	Persistance dans	Utilisation de cas
setChannel() __CAPGO_KEEP_0__ provenant de plugin	Instantané	Seulement appareil (local)	Switch de canal initié par l'utilisateur en application
Survol de l'appareil dans le tableau de bord	Jusqu'à 2 min	Base de données backend	Changements initiés par l'administrateur pour des appareils spécifiques
API affectation de canal	Jusqu'à 2 min	Base de données backend	Intégrations backend automatisées

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() méthode.

Versions minimales pour le basculement de canal local uniquement : 5.34.0, 6.34.0, 7.34.0, ou 8.0.0 (en fonction de 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 installation du plugin pour les étiquettes de version.

Affecter un Bundle à un Canal

Pour déployer une mise à jour en direct, vous devez télécharger une nouvelle build de bundle JS et l'affecter à 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 paquet comme la build active 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'interface de gestion Capgo. 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.

Numérotation des Paquets et des Canaux

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

Lorsque vous numérotez vos paquets, nous vous recommandons d'utiliser la numérotation semantique semver avec des identificateurs de pré-version pour les builds spécifiques à un canal. Par exemple, une version bêta pourrait être numérotée comme 1.2.3-beta.1.

Cette approche présente plusieurs avantages :

• Il communique clairement la relation entre les builds. 1.2.3-beta.1 est clairement une préversion de 1.2.3.
• Il permet de réutiliser les numéros de version dans plusieurs canaux, réduisant la confusion.
• Il 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 pourriez aligner vos versions de bundle avec une configuration 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.

L'utilisation de 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

Si vous déploiez une mise à jour en direct qui introduit une erreur ou doit être réversée, vous pouvez facilement annuler la mise à jour. À partir de la section « Canaux » du tableau de bord :

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

La build sélectionnée deviendra immédiatement la build active pour ce canal. Les applications recevront la version rétablie la prochaine fois qu'elles vérifient une mise à 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 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 les docs pour en savoir plus sur l'automatisation des mises à jour en direct __CAPGO_KEEP_0__. docs to learn more about automating Capgo live updates.

Section intitulée « Déployer sur un appareil »

Installez le __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ dans votre application

1. Install the Capgo SDK in your app
2. Téléchargez une build et affectez-la à ce canal
3. Lancez l'application et attendez l'actualisation !
4. Section intitulée « Déployer sur un appareil »

Pour une présentation plus détaillée, consultez le Déploiement de mises à 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 :

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

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

Continuez à partir des canaux

Si vous utilisez Canaux pour planifier la routage des canaux et la mise en production étape par étape, connectez-le à 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 produit dans la Solution de ciblage de version Capgo Pratiques de l'environnement : mise en scène avec un seul ID d'application mobile pour le contexte pratique dans Capgo Pratiques de l'environnement : mise en scène avec un seul ID d'application mobile