Canaux

Un canal d'actualisation en direct pointe vers une version spécifique du paquet de build JS de votre application qui sera partagée avec tous les appareils configurés pour écouter ce canal pour les mises à jour. Lorsque vous installez le Capgo canal d'actualisation en direct SDK dans votre application, tout binôme natif configuré pour ce canal vérifiera les mises à jour disponibles chaque fois que l'application est lancée. Vous pouvez modifier la version 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 contrôlent l'éligibilité aux mises à jour, pas la secret des paquets. Même si un canal est privé ou que la désignation automatique est désactivée, tout paquet non chiffré téléchargé sur Capgo devrait toujours être considéré comme un actif public 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émontés à partir de l'application distribuée avec suffisamment d'effort car la clé publique fait partie du client. Voir Chiffrage 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. Mise en correspondance de l'appareil (Tableau de bord) – Fixer manuellement un ID d'appareil spécifique à un canal. Utilisez pour un débogage urgent ou un test contrôlé avec un seul utilisateur réel. Cela l'emporte toujours.
2. Surcharge de Cloud (par appareil) via Tableau de bord ou API – Créé lorsque vous changez le canal de l'appareil dans le tableau de bord ou via API. Utilisez pour les utilisateurs QA qui passent entre les canaux de fonctionnalité / PR ou pour reproduire un problème d'utilisateur. La suppression du fichier binaire ne le supprime pas ; la suppression de l'entrée de l'appareil 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'auto-assignation 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 vérification de mise à jour—pas d'attente pour la réplication.

Jusqu'à présent, setChannel() enregistrait le canal de surbrassage dans la base de données de l'arrière-plan (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 l'arrière-plan (pour la validation) et stocke localement, ce qui fait que les changements de canal sont instantanés.

Remarque : Même si un canal devient interdit après avoir été défini localement, l'arrière-plan validera toujours le canal lors des vérifications de mise à jour, de sorte que la sécurité est maintenue.

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 de backend, puis définit le canal localement pour un effet immédiat.

3. Capacitor config defaultChannel (défaut de build de test) – Si présent dans capacitor.config.* et qu'il n'y a pas de force/override, 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.
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 override, 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 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 cloud, 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 en surcharges par appareil).
• Configurez uniquement defaultChannel en binaires que vous envoyez explicitement aux testeurs. Laisser cette option non définie 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 passe et continue dans la liste.

Résumé : Force > Remplacement > Config defaultChannel > Défaut de Cloud.

Comportement par défaut du canal

Définir un défaut de cloud est optionnel, 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 remplacements ou à un defaultChannel en la Capacitor config recevront des mises à jour. Lorsque vous choisissez de marquer des défauts, gardez ces modèles à l'esprit :

• Par défaut unique (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 spécifique à la 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 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 par défaut cloud et defaultChannel s'occupent du même niveau de décision. Si vous définissez un 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 par défaut cloud est différent. defaultChannel – Si un canal a iOS, Android et Electron activés, il devient le seul par défaut ; tout appareil sans surcharges s'y attache.

You pouvez modifier les paramètres à 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

Pendant 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 » 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. 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 large diffusion
• Staging - pour le test final dans un environnement simulant 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 canal.

Ouvrez votre capacitor.config.ts (ou capacitor.config.json) fichier. Sous la plugins section, définissez optionnellement 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-la npx cap sync pour copier le fichier de configuration mis à jour dans vos projets iOS, Android et Electron. Si vous passez à l'étape de synchronisation, vos projets natifs continueront à utiliser le canal dont ils étaient précédemment configurés.

Attention

Ordre de sélection des canaux : Force > Remplacement (setChannel / tableau de bord) > Config defaultChannel > Défaut de Cloud.

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

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

Les noms des canaux sont sensibles à la casse.

Options et stratégies des canaux

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, du CLI, ou du Public API.

• Canal par défaut : Marquez facultativement le canal ou les canaux spécifiques au plateau qui sont attachés aux nouveaux appareils. 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 échouera pour ce canal.

Disable Mise à Jour automatique stratégies

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. Note : ne bloque pas 0.1.0 → 1.1.0.
• patch : Très strict. N'autorise que les mises à jour de correctif augmentant les versions dans la même majeure et mineure. Exemples : 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata : Exigez une version de mise à jour minimale de métadonnées sur chaque bundle. Configurez via CLI en utilisant --min-update-version ou --auto-min-update-version. Si manquant, le canal est marqué comme non configuré et les mises à jour seront rejetées jusqu'à ce qu'il soit défini.
• aucun : Autorise toutes les mises à jour selon la compatibilité de semver. En savoir plus sur les détails et les exemples dans la stratégie de mise à jour Disable à /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy..

Learn more details and examples in Disable updates strategy at /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() à partir de votre application

Le setChannel() méthode permet à votre application de passer en mode canaux à l'aide de l'interpréteur à l'exécution. Cela est particulièrement utile pour :

• Menus de test/QA où les testeurs peuvent passer entre les canaux
• Flux d'opt-in de 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+)

Quand setChannel() est appelé :

1. Validation backend (lecture seule): Une requête est envoyée vers le backend Capgo pour valider que le canal est autorisé (vérification des permissions d'auto-assignation)
2. Mise à jour du stockage local: Si la validation passe, le canal est enregistré dans le stockage local 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() en a sauvegardé la modification de canal vers la base de données backend (même chose que Dashboard ou API modifications). Les appareils devaient attendre la réplication backend (jusqu'à 2 minutes) avant que la modification 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.

Note de sécurité : Même si les permissions d'un canal changent après avoir été définies localement (par exemple, la désactivation de l'auto-assignation), le backend 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	Temps d'effet	Persistance dans	Utilisation
setChannel() à partir du plugin	Instantané	Appareil uniquement (local)	Switching de canal initié par l'utilisateur en application
Survol de l'interface utilisateur de la console	Jusqu'à 2 min	Base de données backend	Modifications initiées par l'administrateur pour des appareils spécifiques
API affectation de canal	Jusqu'à 2 min	Base de données backend	Intégrations backend automatiques

Pour obtenir la meilleure expérience utilisateur lors de la création d'interfaces utilisateur de changement de canal, utilisez toujours la méthode du plugin. setChannel() Versions minimales pour le changement de canal uniquement local :

Versions minimales pour le changement de canal uniquement local : 5.34.0, 6.34.0, 7.34.0ou 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 le même ensemble de fonctionnalités que X est 5, 6, 7 ou 8). Consultez l'installation d'un plugin 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 effectuer cela en une étape avec le Capgo CLI:

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

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

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

Gestion de la version des Bundles et des canaux

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

Lors de la versionnement de vos bundles, nous recommandons l'utilisation de la versionnement semantique avec Capgo’s Tester Semver et les identificateurs de pré-version pour les builds spécifiques au canal. Par exemple, une version bêta pourrait être versionnée comme 1.2.3-beta.1.

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.
• Elle permet de réutiliser les numéros de version à travers les canaux, réduisant la confusion.
• Elle permet des chemins de rebond clairs. Si vous avez besoin de rebondir à partir de 1.2.3vous 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 éventail de configuration 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éalable 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éployez une mise à jour en direct qui introduit une erreur ou qui doit être annulée, vous pouvez facilement annuler la mise à jour. À partir de la section « Canaux » de la console :

1. Cliquez sur le nom du canal que vous souhaitez annuler
2. Trouvez la build que vous souhaitez annuler 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 roulée-back 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 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 sur certaines branches ou créez de nouvelles versions.

Découvrez les Intégration CI/CD docs pour en savoir plus sur l'automatisation des mises à jour en direct Capgo.

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 la mise à jour !

Pour une présentation détaillée, voir la 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 différents niveaux d'utilisateurs
• Tests A/B
• Déploiements de fonctionnalités progressives
• 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 canaux pour les drapeaux de fonctionnalité et les tests A/B.

Continuez à partir des canaux

Si vous utilisez Canaux pour planifier la mise en route 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 travail du produit dans Solution de ciblage de version, et 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 de production : Étape de mise en scène avec un seul ID d'application mobile.