Canaux

Un canal Live Update pointe vers un build de bundle JS spécifique de votre application, qui sera partagé avec tous les appareils configurés pour écouter ce canal lors des mises à jour. Quand vous installez le Capgo Live Updates SDK dans votre app, tout binaire natif configuré pour ce canal vérifiera les mises à jour disponibles à chaque lancement. Vous pouvez changer le build vers lequel pointe un canal à tout moment et effectuer un rollback vers des builds précédents si nécessaire.

Les canaux en action

Considérez un canal comme un pointeur nommé vers une mise à jour : production peut servir votre app publiée pendant que beta sert aux testeurs. Ces trois courtes vidéos montrent comment un appareil rejoint un canal. Chacune propose une musique de fond optionnelle, sans narration ; les explications ci-dessous reprennent les mêmes étapes.

1. Utilisez le canal par défaut

Un appareil exécutant v1.1.0 demande une mise à jour à Capgo. Sans affectation d'appareil ni de canal configuré dans l'app, Capgo vérifie le canal par défaut du cloud, production, et renvoie son v1.2.0 bundle. Le dev et staging canaux conservent leurs propres bundles sans affecter cet appareil.

Télécharger la vidéo du canal par défaut (MP4).

Définissez votre production par défaut dans Informations sur l'application. Les builds de production normaux peuvent laisser defaultChannel non défini afin de gérer ce routage depuis Capgo.

2. Laisser un appareil choisir un canal

Ce guide utilise setChannel() et unsetChannel() depuis @capgo/capacitor-updater sur Android et iOS ; ces méthodes ne sont pas supportées dans le navigateur. Il utilise le comportement local-channel disponible dans updater 5.34.0+, 6.34.0+, 7.34.0+, ou 8.0.0+ pour la version majeure de votre plugin. Les versions plus anciennes écrivaient un override backend ; ces assignations suivent les la console et API outrepassent les règles de rétention.

Un testeur active les mises à jour bêta dans votre application. Votre application appelle CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true }). Capgo vérifie que beta permet l'auto-assignation de l'appareil, puis le plugin enregistre le choix localement pour les futurs contrôles de mise à jour. Les autres appareils conservent leur routage actuel.

Télécharger la vidéo sur l'auto-assignation des appareils (MP4).

Activer Autoriser les appareils à se dissocier/associer eux-mêmes sur le canal cible avant utilisation setChannel(). Ce choix local ne crée pas d'override dans la console. Sur Android et iOS avec l'updater 8.51.0 et versions ultérieures, persistDefaultChannelOnReinstall par défaut sur true, ce choix ne survit à une réinstallation que si le système d'exploitation restaure les données de l'application et persistDefaultChannelOnReinstall reste true. Appelez unsetChannel() pour effacer le choix local ; la console et API continuent de suivre l'ordre de priorité ci-dessous.

3. Assigner un appareil depuis la console

Dans la console Capgo, ouvrez Applications, sélectionnez votre app, ouvrez Appareils, et sélectionnez un appareil. Modifiez son Override du canal vers dev. Capgo redirige désormais cet appareil vers dev, tandis que le défaut cloud de l'application reste production.

Télécharger la vidéo de l'override d'appareil dans la console (MP4).

Utilisez un override pour des tests ciblés ou du support. Il est prioritaire sur le canal local de l'appareil et sur la valeur par défaut du cloud, sauf si un mapping forcé existe. Overrides de la console et de API expirent 90 jours après la dernière écriture de l'override.

Prêt à l'essayer ? Créez un canal dans la console, puis envoyez un bundle pour qu'il soit servi.

Les canaux ne garantissent pas la confidentialité

Les canaux contrôlent l'éligibilité aux mises à jour, pas la confidentialité du bundle. Même si un canal est privé ou si l'auto-assignation est désactivée, tout bundle non chiffré envoyé sur Capgo doit être considéré comme une ressource publique livrée aux clients. Le chiffrement protège le chemin de livraison et l'authenticité des mises à jour, mais les bundles livrés peuvent toujours faire l'objet de rétro-ingénierie à partir de l'application distribuée, avec suffisamment d'efforts, car la clé publique fait partie du client. Voir Chiffrement Live Update pour plus de détails.

Comment un appareil choisit un canal (priorité)

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

1. Mapping forcé d'appareil (dashboard) – Épinglez manuellement un ID d'appareil donné sur un canal. À utiliser pour du débogage urgent ou des tests contrôlés avec un seul utilisateur réel. Cela l'emporte toujours. Capgo supprime le mapping 90 jours après la dernière écriture de l'override. Voir les overrides Console et API expirent après 90 jours.
2. Override cloud (par appareil) via le dashboard ou API – Créé lorsque vous changez le canal de l'appareil dans le dashboard ou via API. À utiliser pour les utilisateurs QA qui passent d'un canal de feature/PR à un autre, ou pour reproduire un problème utilisateur. Réinstaller le binaire ne l'efface pas ; supprimer l'override de l'appareil, oui. La même rétention de 90 jours s'applique.
3. Plugin setChannel() canal local – Créé lorsque l'application appelle setChannel() et que le backend vérifie que le canal cible autorise l'auto-assignation. Le canal sélectionné est stocké localement sur cet appareil, prend effet instantanément et n'apparaît pas dans l'interface Device Override.

Changement de canal instantané avec setChannel()

À partir des versions 5.34.0, 6.34.0, 7.34.0 ou 8.0.0 du plugin (selon votre version majeure), setChannel() le fonctionnement diffère : il contacte le backend 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 comme defaultChannel. Cela signifie que le nouveau canal prend effet instantanément pour la prochaine vérification de mise à jour — sans attendre la réplication.

Auparavant, setChannel() l'override de canal était enregistré dans la base de données backend (comme pour les changements sur le Dashboard ou 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 le backend (pour validation) et stocke localement, rendant le changement de canal instantané.

Parce que setChannel() est uniquement local, cela pas crée une entrée Device Override dans le dashboard Capgo. L'interface Device Override n'affiche que les overrides créés depuis le dashboard ou l’API public.

Note : 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, garantissant ainsi la sécurité.

Important : Lorsque les changements de canal sont effectués via le Dashboard ou API, il subsiste un délai de réplication allant jusqu'à 2 minutes avant que tous les serveurs edge ne reflètent le changement. Pour un changement de canal instantané, utilisez setChannel() depuis votre application code — cela valide auprès du backend, puis définit le canal localement pour un effet immédiat.

4. Configuration Capacitor defaultChannel (build de test par défaut) – Si présent dans capacitor.config.* et qu'aucun canal force/override/local n'existe, l'app démarre sur ce canal (ex. beta, qa, pr-123). Destiné aux builds TestFlight / internes pour que les testeurs arrivent automatiquement sur un canal de pré-release. Les builds de production laissent généralement ce champ vide.
5. Canal par défaut Cloud (chemin principal ~99 % des utilisateurs) – Si vous définissez un canal par défaut dans le dashboard, tous les utilisateurs finaux (sans force, sans override Dashboard/API, sans canal local via plugin, sans config defaultChannel) s'y rattachent. Modifiez-le pour effectuer un déploiement progressif ou un rollback instantané — sans nouveau binaire. Si vous avez des canaux par défaut spécifiques à une plateforme (par exemple, un pour iOS, un pour Android, un pour Electron), chaque appareil arrive sur le canal par défaut correspondant à sa plateforme. Il est possible de ne pas définir de canal par défaut dans le cloud ; dans ce cas, l'appareil doit correspondre aux étapes 1 à 4 pour recevoir des mises à jour.

Bonne pratique :

• Treat 1–4 as exception / testing layers; when you set a cloud default, real users should flow into it. If you choose not to set one, be deliberate about how users attach (typically via defaultChannel dans la config ou via des overrides par appareil).
• Configurez uniquement defaultChannel dans les binaires que vous envoyez explicitement aux testeurs. Ne pas le définir permet de centraliser la logique de production dans le dashboard.
• Utiliser setChannel() avec parcimonie en production — principalement pour la QA ou des diagnostics ciblés.

Si un canal est désactivé pour la plateforme (toggles iOS/Android/Electron) alors qu'il aurait été choisi, le processus de sélection l'ignore et passe au suivant dans la liste.

Résumé : Force > Dashboard/API Override > Plugin setChannel() canal local > Config defaultChannel > Cloud par défaut.

les overrides Console et API expirent après 90 jours

Les mappages forcés et les overrides de canaux API (Dashboard ou Public) sont stockés comme des affectations par appareil dans Capgo. Un job de nettoyage supprime ces affectations. 90 jours après la dernière écriture d'override. Vérifier la présence d'une mise à jour ne réinitialise pas ce délai. Seul le fait de réécrire l'override (ou de le supprimer vous-même) modifie l'horodatage.

Ce n'est pas la même chose que conservation de l'inventaire des appareilsL'inventaire supprime les appareils qui ne se sont pas connectés à Capgo depuis 90 jours. Le nettoyage forcé supprime le mapping même si l'appareil est toujours actif.

Pour une affectation qui n'est pas supprimée par ce nettoyage :

• Définissez defaultChannel dans capacitor.config.* (survit à la réinstallation ; nécessite un nouveau binaire natif pour être modifié ultérieurement).
• Appelez setChannel() de l'application. Avec les plugins 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 et versions ultérieures, cette affectation est locale et n'est pas supprimée par ce nettoyage. Sur Android et iOS avec l'updater 8.51.0 et versions ultérieures, persistDefaultChannelOnReinstall par défaut sur true, afin que l'assignation survive à la réinstallation uniquement lorsque le système d'exploitation restaure les données de l'application et persistDefaultChannelOnReinstall reste true. Utilisez unsetChannel() pour l'effacer explicitement.

Le canal Appareils L'onglet du canal et l'interface Override de l'appareil listent uniquement les affectations console et Public API. Ils ne listent pas tous les appareils du canal, ni les affectations setChannel() affectations.

Avis sur la rétention des overrides dans l'onglet Appareils du canal.

Comportement du canal par défaut

Définir un défaut cloud est optionnel, mais il sert généralement de chemin de repli pour les nouveaux appareils. Sans cela, seuls les appareils correspondant à des mappings forcés, à des overrides ou à un canal défini defaultChannel dans la config Capacitor recevront des mises à jour. Si vous choisissez de définir des défauts, gardez ces schémas en tête :

• Défaut unique (le plus courant) – Si un canal a iOS, Android et Electron d'activés, il devient l'unique canal par défaut ; tout appareil sans override y sera rattaché.
• Valeurs par défaut par plateforme – Si vous séparez les canaux par plateforme (par exemple, ios-production avec seulement iOS activé, android-production avec seulement Android activé, et electron-production avec seulement Electron activé), marquez chacun comme défaut pour sa plateforme. Les appareils iOS utilisent le défaut iOS, les appareils Android le défaut Android, et les apps Electron le défaut Electron.

N'oubliez pas que le défaut cloud et defaultChannel dans capacitor.config.* occupent la même couche de décision. Si vous définissez un défaut cloud, pas besoin de dupliquer la valeur dans votre config Capacitor — laissez defaultChannel vide pour les builds de production. Réservez defaultChannel pour les binaires que vous livrez volontairement aux testeurs ou à la QA lorsque vous voulez qu’ils démarrent sur un canal hors production, même si le défaut cloud est différent.

Vous pouvez modifier les défauts à tout moment dans le dashboard. Ouvrez le canal, puis Gérer dans les paramètres de l'application, ce qui vous redirige vers Informations sur l'application. Le réglage par défaut n'est plus un bouton bascule sur la page du canal. Lorsque vous changez un canal par défaut, les nouveaux appareils respectent immédiatement le nouveau routage et les appareils existants suivent les règles de priorité habituelles lors de leur prochaine vérification.

Configuration d'un canal

Lors de l'onboarding, vous créez le premier canal (la plupart des équipes l'appellent « Production »), mais rien n'est figé : vous pouvez renommer ou supprimer n'importe quel canal à tout moment. Pour ajouter d'autres canaux plus tard :

1. Allez dans la section « Channels » du dashboard Capgo
2. Cliquez sur le bouton « New Channel »
3. Saisissez un nom pour le canal et cliquez sur « Create »

Les noms de canaux peuvent être ce que vous voulez. Une stratégie courante consiste à faire correspondre les canaux à vos étapes de développement, comme :

• Development - pour tester les live updates sur des appareils locaux ou des émulateurs
• QA - pour que votre équipe QA vérifie les mises à jour avant une release plus large
• Staging - pour les tests finaux dans un environnement proche de la production
• Production - pour la version de votre application que les utilisateurs finaux reçoivent depuis les stores

Configurer le canal dans votre application

Une fois vos canaux créés, vous devez configurer votre application pour qu'elle écoute le canal approprié. Dans cet exemple, nous utiliserons le Development canal.

Ouvrez votre capacitor.config.ts (ou capacitor.config.json) fichier. Sous la plugins section, définissez éventuellement defaultChannel pour les builds de test (interne / QA). Pour les builds de production, préférez l'omettre afin que les appareils utilisent le Cloud Default, sauf en cas de remplacement explicite.

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, compilez votre application web et lancez npx cap sync pour copier le fichier de config mis à jour dans vos projets iOS, Android et Electron. Si vous sautez cette étape de sync, vos projets natifs continueront d'utiliser le canal configuré précédemment.

Attention

Ordre de sélection du canal : Force > Remplacement via Dashboard/API device > Plugin setChannel() canal local > Config defaultChannel > Cloud par défaut.

Utiliser defaultChannel uniquement pour les builds de test/internes ; ne l'incluez pas en production pour que les utilisateurs suivent le Cloud Default (lorsqu'il est défini) plutôt que de dupliquer le routage dans la config native.

Vous pouvez toujours forcer (épingler) un appareil ou appliquer un remplacement plus tard — ceux-ci remplacent immédiatement la valeur de la config.

Les noms de canaux sont sensibles à la casse.

Options et stratégies de canal

Les canaux disposent de plusieurs options qui déterminent qui peut recevoir les mises à jour et comment elles sont livrées. Voici les plus importantes. Vous pouvez les configurer depuis l'application web, le CLI, ou l'API publique.

• Canal par défaut : marquez éventuellement le canal ou les canaux par plateforme auxquels les nouveaux appareils se rattachent. Dans la console, cette option se trouve dans App Information (Gérer dans les paramètres de l'application depuis la page du canal). Voir « Comportement du canal par défaut » pour les scénarios de routage.
• Filtres de plateforme : activez ou désactivez la livraison vers les iOS, Android, ou Electron appareils par canal.
• Désactiver l'auto-downgrade en natif : empêche l'envoi d'une mise à jour lorsque la version native de l'app sur l'appareil est plus récente que le bundle du canal (par exemple, un appareil en 1.2.3 alors que le canal est en 1.2.2).
• Autoriser les builds de développement : autorise les mises à jour vers les builds de développement (utile pour les tests). CLI : --dev / --no-dev.
• Autoriser les builds de production : Permet les mises à jour sur les builds de production (stores). Laissez cette option activée pour les canaux destinés aux utilisateurs réels. CLI : --prod / --no-prod.
• Autoriser les émulateurs : Permet les mises à jour sur les émulateurs/simulateurs (utile pour les tests). CLI : --emulator / --no-emulator.
• Autoriser les appareils physiques : Permet les mises à jour sur les téléphones et tablettes réels. Laissez cette option activée pour les canaux de production. CLI : --device / --no-device.
• Autoriser l'auto-assignation par l'appareil : Permet à l'application de basculer vers ce canal au runtime en utilisant setChannel. Si désactivé, setChannel échouera pour ce canal. CLI : --self-assign / --no-self-assign.
• Format de téléchargement : Choisissez si les appareils téléchargent un zip complet, uniquement les fichiers delta modifiés, ou le meilleur des deux (all, zip, delta, zip_from_builtin, delta_from_builtin). Consultez Format de téléchargement pour le menu déroulant de la console et quand chaque mode est utile.

Déploiements progressifs

Un canal peut conserver un bundle stable tout en exposant progressivement une cible de déploiement distincte à une cohorte d'appareils fixe. Vous pouvez mettre en pause, reprendre, promouvoir, effectuer un rollback et configurer une réponse automatique en cas d'échec, sans basculer le canal pour tout le monde. Voir Déploiements progressifs pour le modèle de livraison, le workflow du dashboard, les champs API et les commandes CLI.

Désactiver les stratégies d'Auto Update

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

• major : Bloque un bundle cible dont la version majeure est supérieure à la version native de référence de l'appareil (version_build). Exemple : 1.2.3 -> 2.0.0 est bloqué ; 1.2.3 -> 1.9.0 est autorisé.
• minor : Bloque 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. Bloque tout changement de numéro majeur, mineur ou patch. Seuls les suffixes peuvent changer tant 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 est autorisé, 1.0.0 -> 1.0.1 est bloqué.
• metadata : exige des métadonnées de version minimale de mise à jour 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'à sa configuration.
• none : autorise toutes les mises à jour selon la compatibilité semver.

Ces stratégies comparent le bundle cible du canal au build natif de référence envoyé en version_build, et non au bundle actuellement téléchargé envoyé en version_name.

Pour plus de détails et d'exemples, consultez la stratégie Disable updates dans /docs/cli/commands/#disable-updates-strategy.

Exemple (CLI). Le canal doit déjà exister (channel set la commande ne le crée pas) :

# 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

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

Utiliser setChannel() depuis votre application

Le @capgo/capacitor-updater méthode setChannel() permet à votre application Android ou iOS de changer de canal par programmation au runtime. C'est particulièrement utile pour :

• Menus QA/debug pour permettre aux testeurs de basculer entre les canaux
• Flux d'adhésion aux programmes bêta
• Implémentations de feature flags
• Scénarios d'A/B testing

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
});

Fonctionnement de setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Quand setChannel() est appelée :

1. Validation backend (lecture seule): Une requête est envoyée au 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 réussit, le canal est sauvegardé dans le stockage local de l'appareil en tant que defaultChannel
3. Effet instantané: La prochaine vérification de mise à jour utilise immédiatement le nouveau canal (pas d'attente de réplication)

Pourquoi c'est important : Dans les versions précédentes, setChannel() sauvegardait l'override du canal dans la base de données backend (comme les changements via le Dashboard ou API). Les appareils devaient attendre la réplication du backend (jusqu'à 2 minutes) avant que le changement de canal ne soit effectif. Désormais, setChannel() lit uniquement le backend (pour la validation) et stocke localement, rendant le changement de canal instantané.

Visibilité sur le Dashboard : Un canal défini via le plugin ne fait pas apparaître l'appareil comme un Device Override dans l'interface Capgo. Seules les assignations de canaux créées depuis le dashboard ou l’API public y sont listées. Utilisez le dashboard ou API si vous avez besoin d'un override visible par un admin.

Note de sécurité : Même si les permissions d'un canal changent après avoir été définies localement (par exemple, si l'auto-assignation est désactivée), 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	Délai d'effet	Lieu de persistance	Affiché dans l'UI Device Override	Expire	Cas d’usage
setChannel() depuis le plugin	Instantané	Appareil uniquement (local)	Non	Pas d'expiration automatique ; effacer avec unsetChannel() (la réinstallation peut le conserver)	Changement de canal initié par l'utilisateur dans l'app
Override d'appareil via le dashboard	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture d'override	Modifications initiées par l'admin pour des appareils spécifiques
Assignation de canal API	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture d'override	Intégrations backend automatisées

Pour une expérience utilisateur optimale lors de la création d'interfaces de changement de canal, utilisez toujours la setChannel() method.

Versions minimales pour le changement de canal en 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 (ex: X.34.0 inclut les mêmes fonctionnalités que X soit 5, 6, 7 ou 8). Voir installation du plugin pour les tags de version.

Assigner un bundle à un canal

Pour déployer un live update, vous devez envoyer un nouveau build de bundle JS et l'assigner à un canal. Vous pouvez le faire en une seule étape avec le Capgo CLI :

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

Cela va envoyer vos assets web compilés et définir le nouveau bundle comme build actif pour le Development canal. Toutes les applications configurées pour écouter ce canal recevront la mise à jour lors de leur prochaine vérification.

Vous pouvez aussi assigner des builds à des canaux depuis la section « Bundles » du dashboard Capgo. Cliquez sur l'icône de menu à côté d'un build et sélectionnez « Assign to Channel » pour choisir le canal de ce build.

Versioning des bundles et canaux

Il est important de noter que les bundles dans Capgo sont globaux à votre application, et non spécifiques à un canal. Un même bundle peut être assigné à plusieurs canaux.

Lors du versioning de vos bundles, nous vous recommandons d'utiliser le versioning sémantique avec le Semver Tester de Capgo et des identifiants de pré-release pour les builds spécifiques à un canal. Par exemple, une release beta pourrait être versionnée comme 1.2.3-beta.1.

En CI, si la version locale a déjà été envoyée, utilisez npx @capgo/cli@latest bundle upload --auto-bump (en option major, minor, patch/fix, metadata, ou ai) pour que le CLI remonte depuis le bundle lié au canal jusqu'à trouver un nom libre. Avec ai, Workers AI déduit le niveau à partir du delta entre le manifeste local et le précédent (utilise par défaut patch sans version Capgo précédente). Vous ne pouvez pas le combiner avec --bundle. Voir Intégration CI/CD et le référence CLI.

Cette approche présente plusieurs avantages :

• Elle communique clairement la relation entre les builds. 1.2.3-beta.1 est manifestement une pré-release de 1.2.3.
• Elle permet de réutiliser les numéros de version entre les canaux, réduisant ainsi la confusion.
• Cela permet des chemins de rollback clairs. Si vous devez effectuer un rollback depuis 1.2.3, vous savez que 1.2.2 est la version stable précédente.

Voici un exemple de la manière dont vous pouvez aligner vos versions de bundle avec une configuration de canaux classique :

• 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.4, etc.

Utiliser semver avec identifiants de pré-version est une approche recommandée, mais pas strictement obligatoire. L'essentiel est de trouver un schéma de versionnage qui communique clairement les relations entre vos builds et s'aligne sur le processus de développement de votre équipe.

Rollback d'un Live Update

Si vous déployez un live update qui introduit un bug ou qui doit être annulé, vous pouvez facilement faire un rollback vers un build précédent. Depuis la section « Canaux » du dashboard :

1. Cliquez sur le nom du canal sur lequel faire un rollback
2. Trouvez le build vers lequel vous souhaitez revenir et cliquez sur l'icône couronne
3. Confirmez l'action

Le build sélectionné redevient immédiatement le build actif de ce canal. Les apps recevront la version restaurée lors de leur prochaine vérification de mise à jour.

Automatiser les déploiements

Pour des workflows plus avancés, vous pouvez automatiser vos déploiements live update dans le cadre de votre pipeline CI/CD. En intégrant Capgo à votre processus de build, vous pouvez envoyer automatiquement de nouveaux bundles et les assigner à des canaux dès que vous poussez sur certaines branches ou créez de nouvelles releases.

Consultez la Intégration CI/CD documentation pour en savoir plus sur l'automatisation des live updates Capgo.

Previews de PR au moindre privilège

Utilisez une Aperçu de l'app clé API lorsqu'une CI a besoin d'un canal temporaire par pull request mais ne doit pas gérer les canaux principaux/par défaut existants. La clé reste liée à l'organisation propriétaire et à l'application sélectionnée ; elle n'a simplement aucun rôl’au niveau de l'organisation. Chaque canal de preview non public qu'elle crée reçoit sa propre permission de cycle de vie automatique, limitée au canal.

1. Demandez à un administrateur de l'organisation de créer une clé API sécurisée, limitée à l'application de preview, et sélectionnez Aperçu de l'app. Voir Clés API.
2. Utilisez un canal unique et non public tel que pr-123. Ne passez pas --default, --self-assign, les options de déploiement progressif, ou --delete-linked-bundle-on-upload.
3. Envoyez et propagez le bundle de la PR en une seule commande, puis supprimez le canal et le bundle associés lorsque la PR est fermée :

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel crée un canal s'il manque, envoie le bundle et le promeut en une seule opération. Le nettoyage est atomique et soumis à un contrôle de propriété : la clé ne peut supprimer qu'un canal qu'elle a créé et son bundle associé non partagé. Elle ne peut pas modifier, promouvoir ou supprimer un canal principal/par défaut existant, le canal d'une autre clé de preview, ni le bundle d'une autre clé.

Si les relecteurs ont besoin d'un QR code ou d'une URL de preview, un administrateur doit activer les previews une fois pour l'application :

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Une clé App Preview ne peut pas activer les previews elle-même car elle n'a pas la permission app-settings. Dans les GitHub Actions, exécutez les jobs de preview contenant des secrets sur pull_request, et non pull_request_target, et restreignez-les aux PR du même dépôt avec github.event.pull_request.head.repo.full_name == github.repository.

Déployer sur un appareil

Maintenant que vous comprenez les canaux, vous êtes prêt à déployer des live updates sur de vrais appareils. Le processus de base est :

1. Installez le Capgo SDK dans votre app
2. Configurez l'app pour écouter le canal souhaité
3. Envoyez un build et assignez-l’à ce canal
4. Lancez l'app et attendez la mise à jour !

Pour un guide plus détaillé, consultez le Déploiement de Live Updates guide. Bonnes mises à jour !

Usage avancé des canaux : segmentation des utilisateurs

Les canaux peuvent servir à bien plus que les simples étapes de développement. Ils constituent un outil puissant pour la segmentation des utilisateurs, permettant des fonctionnalités telles que :

• Des feature flags pour différents niveaux d'utilisateurs
• Tests A/B
• Des déploiements progressifs de fonctionnalités
• Des programmes de tests bêta

Découvrez comment implémenter ces cas d'usage avancés dans notre guide : Comment segmenter les utilisateurs par plan et par canaux pour les feature flags et l'A/B testing.

Continuer depuis les canaux

Si vous utilisez Canaux pour planifier le routage des canaux et le déploiement progressif, connectez-l’avec Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Solution de bêta-test pour le workflow produit de la solution Beta Testing, Solution de ciblage de version pour le workflow produit de la solution Version Targeting, et Bonnes pratiques pour l'environnement Capgo : staging avec un seul ID d'app mobile pour le contexte pratique dans Capgo Environment Best Practices : Staging avec un seul ID d'application mobile.