Passer à la navigation
Capgo - Mises à jour en temps réel pour les applications Capacitor Capgo

Canaux

Un canal d'actualisation 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 le canal d'actualisation en direct Capgo 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.

Comment un appareil choisit un canal (préférence)

Section intitulée “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) – Fixer manuellement un ID d'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.
  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.
  3. Plugin setChannel() canal local – Créé lorsque l'application appelle setChannel() et le serveur backend 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 Utilisateur de substitution de dispositif.
  1. Capacitor config defaultChannel (test build par défaut) – Si présent dans capacitor.config.* et qu'aucun canal de force/override/local 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)
  2. – Si vous marquez un canal par défaut dans le tableau de bord, tous les utilisateurs normaux (sans force, sans surcharge de tableau de bord/__CAPGO_KEEP_0__, sans canal local de plugin, sans config defaultChannel) s'y attachent. Modifiez-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 se connecte au 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. – If you mark a default channel in the dashboard, all normal end‑users (no force, no Dashboard/API override, no plugin local channel, no config defaultChannel) attach here. Change it to roll out or roll back instantly—no new binary. If you have platform-specific defaults (for example, one iOS-only, one Android-only, one Electron-only), each device lands on the default matching its platform. Leaving the cloud default unset is allowed; in that case the device must match on steps 1–4 to receive updates.

Traitez 1-4 comme des couches d'exception / de test ; lorsque vous définissez un canal par défaut cloud, 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 binaires que vous envoyez explicitement aux testeurs. Laisser cela non défini garde la logique de production centralisée dans le tableau de bord.
  • – Si présent dans defaultChannel et qu'aucun canal de force/override/local 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.
  • Utilisez setChannel() Utilisez 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 de lister les autres.

Résumé : Force > Tableau de bord/API Survol > Plugin setChannel() canal local > Config defaultChannel > Par défaut Cloud.

Comportement par défaut du canal

Section intitulée “Comportement par défaut du canal”

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

  • 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 survol attachera ici.
  • Paramètres par plateforme par défaut – Si vous divisez les canaux par plateforme (par exemple, ios-production seulement iOS activé, android-production seulement Android activé, et electron-production seulement 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.

N'oubliez pas que le canal par défaut cloud et defaultChannel s'occupent du même niveau de décision. Si vous définissez un canal par défaut cloud, vous n'avez pas besoin de dupliquer la valeur dans votre __CAPGO_KEEP_0__ config—laisses 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 canal par défaut cloud est différent. defaultChannel Vous pouvez modifier les canaux par défaut à tout moment dans le tableau de bord. Lorsque vous changez un canal par défaut, de 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.

Configurer un canal par défaut par plateforme est une bonne pratique pour les applications hybrides.

Platform-specific defaults

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 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 des appareils locaux ou des émulateurs
  • QA - pour votre équipe QA pour vérifier les mises à jour avant une large diffusion
  • Staging - pour les tests finals 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

Section intitulée “Configuration du Canal dans Votre Application”

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

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 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 pour lequel ils étaient précédemment configurés.

Options et stratégies de la chaîne

Section intitulée “Options et stratégies de la chaîne”

Les chaînes 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 options à partir de l'application web, du CLI, ou du Public API.

  • Canal par défaut : Marquez optionnellement le canal ou les canaux spécifiques à la plateforme auxquels les nouveaux appareils se connectent. Consultez « 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).
  • Autoriser les builds de développement : Autoriser les mises à jour des builds de développement (utiles pour les tests).
  • Autoriser les appareils émulateurs : Autoriser les mises à jour des émulateurs/simulateurs (utiles pour les tests).
  • Autoriser l'auto-assignation des appareils : Permet aux applications de passer à ce canal en temps de exécution à l'aide de setChannel. Si désactivé, setChannel échouera pour ce canal.

Stratégies de mise à jour automatique désactivées

Section intitulée « Stratégies de mise à jour automatique désactivées »

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

  • majeur : Bloc un bundle cible dont la version majeure est supérieure à la version native de base du dispositif (version_build). Exemple : 1.2.3 -> 2.0.0 est bloqué ; 1.2.3 -> 1.9.0 est autorisé.
  • mineur : Bloc un bundle cible dont la version majeure ou mineure diffère de version_build. Exemple : 1.2.3 -> 1.3.0 est bloqué ; 1.2.3 -> 1.2.4 est autorisé.
  • patch : Mode le plus strict. Bloc tout changement de version majeure, mineure ou de patch. Seuls les changements de suffixe sont autorisés tandis que 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 is autorisé, 1.0.0 -> 1.0.1 is bloqué.
  • metadata : Exigez une version d'actualisation minimale dans chaque paquet. Configurez via CLI à l'aide de --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 configuré.
  • aucune : Autorise toutes les mises à jour selon la compatibilité de semver Ces stratégies comparant le paquet cible du canal avec la base native envoyée sous la forme .

et non le paquet téléchargé actuel envoyé sous la forme version_buildEn savoir plus sur les détails et les exemples dans la stratégie d'actualisation Disable à /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy. version_name.

Exemple (cli):

Example (CLI):

Terminal window
# 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() à partir de votre application

Section intitulée « Utilisation de setChannel() à partir de votre application »

Le setChannel() 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'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
});

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 faire cela en une étape avec le __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ :

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

Assigning a Bundle to a Channel
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 chaîne. Tous les applications configurées pour écouter cette chaîne recevront la mise à jour la prochaine fois qu'elles rechercheront une.

Vous pouvez également affecter des builds à des chaînes à partir de la section « Bundles » de la console de bord Capgo. Cliquez sur l'icône de menu à côté d'un build et sélectionnez « Affecter à la chaîne » pour choisir la chaîne pour ce build.

Versionnement des Bundles et des Chaînes

Section intitulée « Versionnement des Bundles et des Chaînes »

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 chaînes.

Lorsque vous versionnez vos bundles, nous vous recommandons d'utiliser la versionnement semantique avec le Testeur Semver de Capgo et les identificateurs de pré-version pour les builds spécifiques à la chaîne. 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 is clairement une préversion de 1.2.3.
  • Cela permet de réutiliser les numéros de version dans plusieurs canaux, réduisant la confusion.
  • Cela 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 pouvez 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.4etc.

Utiliser La mise en œuvre 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

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 :

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

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

Automatisation des déploiements

Section intitulée “Automatisation des 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 nouveaux bundles 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 en direct Capgo.

Déploiement sur un appareil

Section intitulée “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. Charger une build et l'affecter à ce canal
  4. Lancez l'application et attendez l'actualisation !

Pour une présentation détaillée, consultez le Déploiement d'actualisations en direct guide. Bonne actualisation !

Utilisation avancée des canaux : segmentation des utilisateurs

Sous-section intitulée “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
  • Rollouts 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 plan et par canaux pour les drapeaux de fonctionnalité et les tests A/B.

Continuez de là des canaux

Section intitulée “Continuez de là des canaux”

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