Channels

Un canal Live Update pointe vers une version de bundle JS spécifique 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 Capgo Live Updates SDK dans votre application, tout binaire natif configuré sur ce canal recherchera les mises à jour disponibles à chaque lancement de l’application. Vous pouvez modifier la version vers laquelle pointe un canal à tout moment et pouvez également revenir aux versions précédentes si nécessaire.

Comment un appareil sélectionne une chaîne (priorité)

Lorsqu’un appareil recherche une mise à jour, Capgo décide quel canal utiliser dans cet ordre strict (la priorité la plus élevée en premier) :

1. Mappage forcé des appareils (tableau de bord) – Épinglez manuellement un ID d’appareil spécifique à un canal. À utiliser pour le débogage urgent ou les tests contrôlés avec un seul utilisateur réel. Cela gagne toujours.
2. Remplacement du cloud (par appareil) via le tableau de bord ou API – Créé lorsque vous modifiez le canal de l’appareil dans le tableau de bord ou via API. À utiliser pour les utilisateurs d’assurance qualité qui passent d’un canal de fonctionnalité à un canal de relations publiques ou pour reproduire un problème utilisateur. La réinstallation du binaire ne l’efface pas ; la suppression de l’entrée de l’appareil le fait.

Changement de canal instantané avec setChannel()

À partir de la version 5.34.0, 6.34.0, 7.34.0 ou 8.0.0 du plugin (selon votre version majeure), setChannel() fonctionne différemment : il contacte le backend pour valider que le canal est autorisé (en vérifiant si l’auto-attribution est activée pour ce canal), puis stocke le canal localement sur l’appareil sous le nom defaultChannel. Cela signifie que le nouveau canal prend effet instantanément lors de la prochaine vérification de mise à jour, sans attendre la réplication.

Auparavant, setChannel() enregistrait le remplacement du canal dans la base de données principale (comme les modifications du tableau de bord ou de API), et les appareils devaient attendre la réplication des données (jusqu’à 2 minutes) avant que le nouveau canal ne soit reconnu. Le nouveau comportement lit uniquement à partir du backend (pour validation) et stocke localement, ce qui rend les changements de canal instantanés.

Remarque : Même si un canal devient interdit après avoir été défini localement, le backend validera toujours le canal lors des vérifications de mise à jour, afin que la sécurité soit maintenue.Important : Lorsque des modifications de canal sont apportées via le tableau de bord ou API, il y a encore un délai de réplication pouvant aller jusqu’à 2 minutes avant que tous les serveurs Edge ne reflètent la modification. Pour un changement de chaîne instantané, utilisez setChannel() à partir du code de votre application : il est validé avec le backend, puis définit le canal localement pour un effet immédiat.

3. Capacitor config defaultChannel (test build par défaut) – Si présent dans capacitor.config.* et qu’aucune force/remplacement n’existe, l’application démarre sur ce canal (par exemple beta, qa, pr-123). Destiné à TestFlight/versions internes afin que les testeurs atterrissent automatiquement sur un canal de pré-version. Les builds de production laissent généralement cela inchangé.
4. Canal Cloud par défaut (chemin principal ~ 99 % des utilisateurs) – Si vous marquez un canal par défaut dans le tableau de bord, tous les utilisateurs finaux normaux (pas de force, pas de remplacement, pas de configuration defaultChannel) s’attachent ici. Modifiez-le pour le déployer ou le restaurer instantanément : pas de nouveau binaire. Si vous avez des valeurs par défaut spécifiques à la plate-forme (par exemple, un iOS uniquement, un Android uniquement, un Electron uniquement), chaque appareil atterrit sur la valeur par défaut correspondant à sa plate-forme. Il est permis de laisser la valeur par défaut du cloud non définie ; dans ce cas, l’appareil doit correspondre aux étapes 1 à 3 pour recevoir les mises à jour.

Bonne pratique :

• Traiter 1 à 3 comme couches d’exception/test ; lorsque vous définissez un cloud par défaut, les vrais utilisateurs doivent y accéder. Si vous choisissez de ne pas en définir, réfléchissez à la manière dont les utilisateurs se connectent (généralement via defaultChannel dans la configuration ou par remplacement de périphérique).
• Configurez uniquement defaultChannel dans les binaires que vous envoyez explicitement aux testeurs. Si cette option n’est pas configurée, la logique de production est centralisée dans le tableau de bord.
• Utilisez setChannel() avec parcimonie en production, principalement pour l’assurance qualité ou les diagnostics ciblés.

Si un canal est désactivé pour la plate-forme (bascule iOS/Android/Electron) alors qu’il aurait autrement été choisi, le processus de sélection l’ignore et continue dans la liste.

Résumé : Forcer > Remplacer > Config defaultChannel > Cloud par défaut.

Comportement du canal par défaut

La définition d’un cloud par défaut est facultative, mais elle sert généralement de chemin fourre-tout pour les nouveaux appareils. Sans cela, seuls les appareils correspondant à des mappages forcés, à des remplacements ou à un defaultChannel dans la configuration Capacitor recevront des mises à jour. Lorsque vous choisissez de marquer les valeurs par défaut, 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 remplacement sera attaché ici.
• Paramètres par défaut spécifiques à la plate-forme – Si vous divisez les canaux par plate-forme (par exemple, ios-production avec seulement iOS activé, android-production avec seulement Android activé et electron-production avec uniquement Electron activé), marquez chacun d’entre eux comme valeur par défaut pour sa plate-forme. Les appareils iOS accèdent à la valeur par défaut iOS, les appareils Android accèdent à la valeur par défaut Android et les applications Electron accèdent à la valeur par défaut Electron.N’oubliez pas que la valeur par défaut du cloud et defaultChannel dans capacitor.config.* occupent tous deux la même couche de décision. Si vous définissez une valeur cloud par défaut, vous n’avez pas besoin de dupliquer la valeur dans votre configuration Capacitor : laissez defaultChannel vide pour les versions de production. Réservez defaultChannel pour les binaires que vous envoyez intentionnellement aux testeurs ou au contrôle qualité lorsque vous souhaitez qu’ils démarrent sur un canal hors 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 obéissent immédiatement au nouveau routage et les appareils existants suivent les règles de priorité normales lors de leur prochain enregistrement.

Créer une chaîne

Lors de l’intégration, vous créez la première chaîne (la plupart des équipes l’appellent « Production »), mais rien n’est verrouillé : vous pouvez renommer ou supprimer n’importe quelle chaîne à tout moment. Pour ajouter des chaînes supplémentaires ultérieurement :

1. Accédez à la section “Chaînes” du tableau de bord Capgo
2. Cliquez sur le bouton “Nouvelle chaîne”
3. Entrez un nom pour la chaîne et cliquez sur “Créer”

Les noms de chaînes peuvent être tout ce que vous souhaitez. Une stratégie courante consiste à adapter les canaux à vos étapes de développement, par exemple :

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

Configurer la chaîne dans votre application

Une fois vos chaînes créées, vous devez configurer votre application pour écouter la chaîne appropriée. Dans cet exemple, nous utiliserons le canal Development.

Ouvrez votre fichier capacitor.config.ts (ou capacitor.config.json). Dans la section plugins, définissez éventuellement defaultChannel pour les versions de test (internes/QA). Pour les versions de production, préférez l’omettre afin que les appareils utilisent la valeur Cloud par défaut, à moins qu’elle ne soit explicitement remplacé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, créez 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 ignorez cette étape de synchronisation, vos projets natifs continueront à utiliser le canal pour lequel ils ont été précédemment configurés.

Attention

Ordre de sélection des canaux : Forcer > Remplacer (setChannel / tableau de bord) > Config defaultChannel > Cloud Default.

Utilisez defaultChannel uniquement dans les versions de test/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 le routage dans la configuration native.

Vous pouvez toujours forcer (épingler) un périphérique ou appliquer un remplacement ultérieurement : ceux-ci remplacent immédiatement la valeur de configuration.

Les noms de chaînes sont sensibles à la casse.

## Options et stratégies de canal

Les chaînes disposent de plusieurs options qui contrôlent qui peut recevoir les mises à jour et comment les mises à jour sont fournies. Les plus importants sont ci-dessous. Vous pouvez les configurer à partir de l’application Web, du CLI ou du API public.- Canal par défaut : marquez éventuellement le canal ou les canaux spécifiques à la plate-forme auxquels les nouveaux appareils se connectent. Voir « Comportement du canal par défaut » pour les scénarios de routage.

• Filtres de plate-forme : activez ou désactivez la diffusion sur les appareils iOS, Android ou Electron par canal.
• Désactiver la rétrogradation automatique en mode natif : empêche l’envoi d’une mise à jour lorsque la version native de l’application de l’appareil est plus récente que l’offre groupée de la chaîne (par exemple, un appareil sur 1.2.3 alors que la chaîne a 1.2.2).
• Autoriser les builds de développement : autoriser les mises à jour des builds de développement (utile pour les tests).
• Autoriser les appareils émulateurs : Autoriser les mises à jour des émulateurs/simulateurs (utile pour les tests).
• Autoriser l’auto-attribution de l’appareil : permet à l’application de basculer vers ce canal lors de l’exécution à l’aide de setChannel. S’il est désactivé, setChannel échouera pour ce canal.

### Désactiver les stratégies de mise à jour automatique

Utilisez-le pour restreindre les types de mises à jour que la chaîne fournira automatiquement. Possibilités :

• majeur : bloque les mises à jour majeures (0.0.0 → 1.0.0). Les mises à jour mineures et correctives sont toujours autorisées.
• mineur : bloque les mises à jour croisées mineures (par exemple, 1.1.0 → 1.2.0) et majeures. Les mises à jour de correctifs sont toujours autorisées. Remarque : ne bloque pas 0.1.0 → 1.1.0.
• patch : Très strict. Permet uniquement d’augmenter les versions de correctifs au sein des mêmes majeur et mineur. Exemples : 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• métadonnées : exigent une mise à jour minimale des métadonnées de la version sur chaque bundle. Configurez via CLI en utilisant --min-update-version ou --auto-min-update-version. S’il est manquant, le canal est marqué comme mal configuré et les mises à jour seront rejetées jusqu’à ce qu’elles soient définies.
• aucun : autorise toutes les mises à jour en fonction de la compatibilité du serveur.

Découvrez plus de détails et d’exemples dans la stratégie Désactiver les mises à jour à l’adresse /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

Utilisation de setChannel() depuis votre application

La méthode setChannel() permet à votre application de changer de canal par programmation au moment de l’exécution. Ceci est particulièrement utile pour :

• Menus QA/debug où les testeurs peuvent basculer entre les canaux
• Flux d’inscription au programme bêta
• Implémentations d’indicateurs de fonctionnalités
• 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 du backend (lecture seule) : une requête est envoyée au backend Capgo pour valider que le canal est autorisé (vérification des autorisations d’auto-attribution)
2. Mise à jour du stockage local : si la validation réussit, la chaîne est enregistrée dans le stockage local de l’appareil sous le nom defaultChannel.
3. Effet instantané : la prochaine vérification de mise à jour utilise immédiatement le nouveau canal (pas d’attente de réplication)

Pourquoi est-ce important : Dans les anciennes versions, setChannel() enregistrait le remplacement du canal dans la base de données principale (identique aux modifications du tableau de bord ou de API). Les appareils devaient attendre la réplication backend (jusqu’à 2 minutes) avant que le changement de canal ne prenne effet. Désormais, setChannel() lit uniquement à partir du backend (pour validation) et stocke localement, ce qui rend les changements de canal instantanés.

Remarque de sécurité : Même si les autorisations d’un canal changent après avoir été définies localement (par exemple, l’auto-attribution est désactivée), le backend validera toujours le canal lors des vérifications de mise à jour, garantissant ainsi le maintien de la sécurité.

Comparaison des méthodes de changement de chaîne :

Méthode	Délai d’effet	Persistance	Cas d’usage
setChannel() depuis le plugin	Instantané	Appareil uniquement (local)	Changement de canal initié par l’utilisateur dans l’app
Remplacement d’appareil via le tableau de bord	Jusqu’à 2 min	Base de données backend	Changements initiés par un administrateur pour des appareils spécifiques
Attribution de canal via l’API	Jusqu’à 2 min	Base de données backend	Intégrations backend automatisées

Pour la meilleure expérience utilisateur lors de la création d’interfaces de changement de canal, utilisez toujours la méthode setChannel() du plugin.

Versions minimales pour le changement 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 sur toutes les versions majeures (par exemple, X.34.0 inclut les mêmes fonctionnalités que X soit 5, 6, 7 ou 8). Consultez l’installation du plugin pour les tags de version.

Automatisation des déploiements

Pour des flux de travail plus avancés, vous pouvez automatiser vos déploiements de mises à jour en direct dans le cadre de votre pipeline CI/CD. En intégrant Capgo dans votre processus de build, vous pouvez automatiquement télécharger de nouveaux bundles et les attribuer à des canaux chaque fois que vous poussez vers certaines branches ou créez de nouvelles versions.

Consultez la documentation Intégration CI/CD 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 de vrais appareils. Le processus de base est le suivant :

1. Installez le Capgo SDK dans votre application
2. Configurez l’application pour écouter la chaîne souhaitée
3. Téléchargez une version et attribuez-la à ce canal
4. Lancez l’application et attendez la mise à jour !

Pour une procédure pas à pas plus détaillée, consultez le guide Déploiement des mises à jour en direct. Bonne mise à jour !

Utilisation avancée des canaux : segmentation des utilisateurs

Les canaux peuvent être utilisés au-delà des simples étapes de développement. Il s’agit d’un outil puissant pour la segmentation des utilisateurs, permettant des fonctionnalités telles que :

• Indicateurs de fonctionnalités pour différents niveaux d’utilisateurs
• Tests A/B
• Déploiements progressifs de fonctionnalités
• Programmes de tests bêta

Découvrez comment mettre en œuvre ces cas d’utilisation avancés dans notre guide : [Comment segmenter les utilisateurs par plan et canaux pour les indicateurs de fonctionnalités et les tests A/B] (/blog/how-to-segment-users-by-plan-and-channels/).