Canaux

Copiez une invite de configuration avec les étapes d'installation et la guide markdown complète pour ce plugin.

Au moyen d'un canal d'actualisation en temps réel, un bundle de build JS spécifique de votre application est partagé avec tous les appareils configurés pour écouter ce canal pour les mises à jour. Lorsque vous installez le Capgo canal d'actualisation en temps réel SDK dans votre application, tout binôme natif configuré pour ce canal vérifie les mises à jour disponibles chaque fois que l'application est lancée. Vous pouvez modifier le build vers lequel pointe un canal à tout moment et pouvez également revenir à des builds précédents si nécessaire.

Comment un appareil choisit un canal (prééminence)

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) :

Affectation de l'appareil forcée (tableau de bord) – Fixer un ID de appareil spécifique à un canal. Utilisez pour le débogage urgent ou le test contrôlé avec un seul utilisateur réel. Cela l'emporte toujours.
Surcharge Cloud (par appareil) via Dashboard 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 bin n'efface pas cela ; la suppression de l'entrée de l'appareil le fait.

À 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 l'appareil as defaultChannel. Cela 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 substitution 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 dans le backend (pour la validation) et stocke localement, ce qui permet les changements de canal instantanés.

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

Important : Lorsque les changements de canal sont effectués 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 canal instantané, utilisez setChannel() à partir de votre application code—il valide avec le backend, puis définit le canal localement pour un effet immédiat.

Configuration de Capacitor defaultChannel (défaut de construction de test) – Si présent dans capacitor.config.* et qu'aucune force/ouverture n'existe, l'application démarre sur ce canal (par exemple, ). Intégré 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. beta, qa, pr-123Canal 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 ouverture, 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 s'y connecter. 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

seulement configurez defaultChannel 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 defaultChannel avec parcimonie en production—principalement pour les tests de qualité ou les diagnostics ciblés.
__CAPGO_KEEP_0__ setChannel() __CAPGO_KEEP_1__

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 > Surcharger > Config defaultChannel > Par défaut de Cloud.

Comportement par défaut du canal

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

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.
Défauts spécifiques à la plateforme – Si vous divisez les canaux par plateforme (par exemple, ios-production avec uniquement iOS activé, android-production With uniquement Android activé, et electron-production Avec uniquement Electron activé), marquez chacune comme la valeur par défaut pour sa plateforme. Les appareils iOS se dirigent vers la valeur par défaut iOS, les appareils Android se dirigent vers la valeur par défaut Android, et les applications Electron se dirigent vers la valeur par défaut Electron.

Rappelez-vous que la valeur par défaut du cloud et defaultChannel s'occupent du même niveau de décision. Si vous définissez une valeur par défaut du cloud, vous n'avez pas besoin de dupliquer la valeur dans votre __CAPGO_KEEP_0__ config—la laissez vide pour les builds de production. Réservez 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 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 préférence normales la prochaine fois qu'ils se connectent. defaultChannel Configuration d'un Canal

Section intitulée « 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 :

Setting up a Channel

Go to the “Channels” section of the Capgo dashboard
Cliquez sur le bouton « Nouveau Canal »
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, telles que :

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 mise en production 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

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 canal « __CAPGO_KEEP_0__ ». Development Ouvrez votre

file path capacitor.config.ts ou capacitor.config.jsonfichier. Sous la section, configurez plugins pour defaultChannel les builds de test fichier. 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 modifiée. Copier dans le presse-papier

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.
    },
  },
};

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 la chaîne qu'ils étaient configurés pour. npx cap sync Attention

Options et stratégies de canal

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 éléments à 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 iOS, Android, ou Electron par appareil et 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 des builds de développement (utile pour les tests).
Permettre les appareils émulateurs : Autoriser les mises à jour des émulateurs/simulateurs (utile pour les tests).
Permettre l'auto-assignation de l'appareil : Permet à l'application de passer à ce canal en temps de exécution à l'aide de setChannel. Si désactivé, setChannel échouera pour ce canal.

Stratégies de désactivation de mise à jour automatique

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

majeur : Bloquer les mises à jour transversales majeures (0.0.0 → 1.0.0). Les mises à jour mineures et de patch 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 patch 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 patch au sein du même numéro majeur et mineur. Exemples : 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
metadata: Exigez une version minimale d'update 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: Autorisez toutes les mises à jour selon la compatibilité semver.

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() Cette méthode permet à votre application de passer en mode canaux de manière programmée 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'adhésion au 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
});

Lorsque setChannel() est appelé :

Validation back-end (lecture seule) : Une requête est envoyée vers le backend Capgo pour valider que le canal est autorisé (vérification des permissions d'autorisation de mise à jour)
Mise à jour de stockage local: Si la validation passe, le canal est sauvegardé dans le stockage local de l'appareil comme defaultChannel
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 de 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 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 de mise à jour, garantissant ainsi la sécurité.

Comparaison des méthodes de changement de canal :

Méthode	Durée d'effet	Sauvegardé où	Utilisation
`setChannel()` à partir du plugin	Instantané	Seulement appareil (local)	Changement de canal initié par l'utilisateur en application
Survol de l'appareil sur le tableau de bord	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 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 (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 l'installation du plugin pour les balises de version.

Affecter 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'affecter à 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 rechercheront une.

Vous pouvez également affecter 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 « Affecter à un 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 à 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 une versionnement semantique semver avec des identificateurs de pré-version pour les builds spécifiques à un 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 manifestement une préversion de 1.2.3.
Elle permet de réutiliser les numéros de version dans plusieurs canaux, réduisant la confusion.
Elle permet des chemins de rebond clairs. Si vous devez 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 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 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. 1.2.3, 1.2.4Annuler une mise à jour en direct

Section intitulée “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 revenir à une version précédente. À partir de la section « Canaux » de la console :

Trouvez la version que vous souhaitez annuler et cliquez sur l'icône de couronne

Annuler la version
Confirmer l'action
Confirmer l'action

The build sélectionné deviendra immédiatement la build active pour ce canal à nouveau. Les applications recevront la version annulée la prochaine fois qu'elles vérifient une mise à jour.

Automatisation des déploiements

Pour des workflows plus avancés, vous pouvez automatiser vos déploiements d'actualisation en direct comme 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.

Découvrez plus sur l'automatisation des mises à jour en direct __CAPGO_KEEP_0__ dans les Intégration CI/CD docs to learn more about automating Capgo live updates.

Déploiement vers un appareil

Maintenant que vous comprenez les canaux, vous êtes prêt à commencer à déployer des mises à jour en direct vers des appareils réels. Le processus de base est :

Installez le Capgo SDK dans votre application
Configurez l'application pour écouter votre canal souhaité
Téléchargez une mise en production et affectez-la à ce canal
Lancez l'application et attendez l'actualisation !

Pour une présentation plus détaillée, consultez le Déploiement d'actualisations en direct 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 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 progressifs 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 plan et par canaux pour les drapeaux de fonctionnalités et les tests A/B.