Passer au contenu
Capgo - Live Updates for Capacitor Apps Capgo

Channels

Comment Capgo choisit un canal (priorité)

Section titled “Comment Capgo choisit un canal (priorité)”

Lorsqu’un appareil demande une mise à jour à Capgo, le canal qu’il utilisera est décidé dans l’ordre suivant (la priorité la plus élevée en premier) :

  1. Mappage forcé des appareils : Si l’ID de l’appareil est explicitement forcé à un canal (voir la liste Appareils forcés dans les paramètres du canal), ce canal gagne toujours.
  2. Remplacement du cloud (créé par setChannel() ou une action Webapp) : l’appel de setChannel (ou la modification du canal d’un appareil dans le tableau de bord) écrit un remplacement persistant dans le cloud lié à cet ID d’appareil. Ce remplacement est consulté après le mappage forcé mais avant toute valeur par défaut. La réinstallation de l’application ne l’efface pas ; la suppression de l’entrée de l’appareil le fait.
  3. Capacitor config defaultChannel (version de test par défaut) : pour les versions internes/bêta/de test, vous pouvez définir defaultChannel (clé héritée channel) dans capacitor.config.* afin que les appareils de test démarrent sur un canal de pré-version (par exemple beta, pr-123). En cas d’absence, l’appareil passera au cloud par défaut. Les versions de production laissent généralement cela inchangé.
  4. Canal Cloud par défaut (stratégie principale pour environ 99 % des utilisateurs) : le canal de production principal sur lequel atterrissent pratiquement tous les utilisateurs réels. Tout nouvel appareil sans force, sans remplacement et sans configuration defaultChannel l’utilise. Le modifier est déployé (ou annulé) pour tout le monde en quelques secondes – pas de nouveau binaire.

Pourquoi le cloud par défaut est le chemin principal :

  • Déploiement ou restauration instantanée sans reconstruire ni republier les binaires natifs.
  • Un seul endroit pour gérer le comportement de iOS, Android et Electron.
  • Plus sûr : vous pouvez confirmer que les bundles existent et que les paramètres sont corrects avant de changer par défaut.
  • Modifications vérifiables (les membres de l’équipe peuvent voir qui a modifié quoi dans l’interface utilisateur/les journaux). Principe de conception : les couches ci-dessus (force / override / config) sont des exceptions (débogage d’un seul utilisateur, commutation d’assurance qualité, tests par défaut de la construction). Les utilisateurs normaux accèdent au cloud par défaut.

La modification du canal cloud par défaut affecte les nouveaux appareils normaux qui :

  • Ne sont pas forcés
  • Vous n’avez pas déjà de remplacement de cloud - Ne pas avoir de defaultChannel au niveau de l’application défini

Si une version de test est livrée avec defaultChannel: 'beta' et que vous modifiez ultérieurement la valeur par défaut du cloud en production, les appareils qui ont démarré sur beta via la configuration y restent jusqu’à ce que vous : (a) les remplaciez avec setChannel(), (b) les forcez ou (c) supprimez l’entrée de l’appareil.

Les appareils restent sur leur canal actuel, sauf si :

  • Forcez-les à passer à une autre chaîne.
  • Appelez setChannel() (création/remplacement du cloud override) ou modifiez-le manuellement dans le tableau de bord.
  • Supprimer/archiver la chaîne sur laquelle ils se trouvent (ils reviendront ensuite dans la priorité lors de la prochaine vérification).

Si un canal est désactivé pour une plate-forme (voir iOS / Android / Electron bascule) et aurait autrement été sélectionné, la sélection l’ignore et revient à la règle suivante.

Remarque : définir defaultChannel signifie que sa modification nécessite un nouveau binaire ; utilisez-le intentionnellement pour les tests/assurance qualité, pas pour le contrôle général de la production.

Capacitor exemple de configuration

Section titled “Capacitor exemple de configuration”
capacitor.config.ts
// Example: a TestFlight or internal QA build defaults to the beta channel.
const config = {
  plugins: {
    Capgo: {
      defaultChannel: 'beta', // Test build default. Omit in production so users attach to cloud default.
      // legacy key: channel
    },
  },
};
export default config;
```Si vous modifiez ultérieurement la valeur par défaut du tableau de bord en `production`, les appareils déjà sur un autre canal (via la configuration, le remplacement ou la force) ne se déplaceront PAS automatiquement ; seuls les nouveaux appareils (ou ceux dont vous supprimez la substitution/la force) le récupèrent.


---


## Gestion des chaînes


Tout d’abord, jetons un coup d’œil à la page des chaînes. Vous pouvez y accéder en [cliquant sur votre application](/docs/webapp/main-page) puis [en cliquant sur l'onglet chaînes](/docs/webapp/main-app-page).




<figure><img src="/channels.webp" alt="liste des chaînes" /><figcaption></figcaption></figure>


## Création d'une chaîne


Comme vous pouvez le voir, il existe un bouton plus dans le coin inférieur droit. (`1` dans l'image) En cliquant dessus, vous ouvrirez un modal où vous pourrez créer une nouvelle chaîne.
<figure><img style="margin-left: auto; margin-right: auto" src="/new_channel_modal.webp" alt="nouvelle chaîne" /><figcaption></figcaption></figure>


Ensuite, après avoir cliqué sur `Add`, une nouvelle chaîne devrait apparaître dans la liste.
<figure><img src="/post-channel-create.webp" alt="après la création du canal" /><figcaption></figcaption></figure>


## Que signifie mal configuré ?
Parfois, la configuration d'un canal n'est pas valide. Dans ce cas, vous recevrez un gros avertissement et la colonne `Misconfigured` indiquera `Yes` pour une ou plusieurs chaînes.
Vous pouvez en savoir plus [ici](/docs/cli/commands/#disable-updates-strategy)


## Supprimer une chaîne


Supprimer une chaîne est simple. Cliquez simplement sur l'icône de la corbeille et confirmez la suppression. (`2` dans l'image)


## Gérer une chaîne


En cliquant sur le nom de la chaîne, vous ouvrirez une fenêtre modale dans laquelle vous pourrez gérer les paramètres de la chaîne. (`3` dans l'image)


<figure><img src="/channel_settings.webp" alt="Paramètres des chaînes" /><figcaption></figcaption></figure>


La page des paramètres de chaîne contient toutes les options de configuration de votre chaîne. Passons en revue chaque paramètre.


---
Tout d'abord, la bascule « Canal par défaut ». Lorsqu'il est activé, ce canal devient le canal par défaut pour les nouveaux appareils. Pour une explication complète du fonctionnement des canaux par défaut, y compris comment configurer les valeurs par défaut spécifiques à la plate-forme (une pour iOS, une pour Android et une pour Electron), consultez la section [Configuration des canaux par défaut] (/docs/webapp/main-app-page/#default-channel-configuration).


---
Deuxièmement, le paramètre `IOS`. C'est relativement simple. Si cela est faux, les appareils IOS ne seront pas autorisés à télécharger les mises à jour depuis ce canal.


Le troisième est le paramètre `Android`. Ceci est similaire à `IOS`. Si cela est faux, les appareils Android ne seront pas autorisés à télécharger les mises à jour à partir de ce canal.


Le quatrième est le paramètre `Electron`. Ceci est similaire à `IOS` et `Android`. Si cela est faux, les applications Electron ne seront pas autorisées à télécharger des mises à jour à partir de cette chaîne.


Le cinquième est le paramètre « Désactiver la rétrogradation automatique en mode natif ». Si cela est vrai, il sera alors impossible de rétrograder à partir d’une version native. Cela signifie que si vous avez téléchargé une version `1.2.0` sur l'App Store ou le Play Store et que vous essayez de définir la version de la chaîne sur `1.1.0`, la mise à jour (rétrogradation) échouera.


Le sixième est « Désactiver la mise à jour automatique ». Ce paramètre est assez complexe et vous pouvez en savoir plus [ici](/docs/cli/commands/#disable-updates-strategy)Quant à « Autoriser la construction de développement ». Si cela est vrai, les versions de développement seront autorisées à télécharger les mises à jour à partir de ce canal. Dans le cas contraire, toute demande de mise à jour dont le `prod` est défini sur false sera rejetée. Ceci est principalement utile à des fins de tests.


Le septième est « Autoriser les émulateurs ». Si cela est faux, alors Capgo refusera toute demande de mise à jour provenant d'un émulateur. Ceci est principalement utile à des fins de tests.


Huit est « Autoriser les appareils à s'auto-associer ». Si cela est vrai, la méthode [setChannel](/docs/plugin/api/#setchannel) sera disponible. Si la valeur est false et que vous essayez d'appeler la méthode [setChannel](/docs/plugin/api/#setchannel) avec ce canal, l'appel échouera.