Canaux

Un canal Live Update pointe vers un build spécifique du bundle JS de votre application, qui sera partagé avec tous les appareils configurés pour écouter les mises à jour de ce canal. Lorsque 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.

Réponse courte : pour le staging et la production dans une app Capacitor, créez un staging et une production canal dans Capgo, envoyez chaque bundle vers staging d'abord, testez-le, puis promouvez le même bundle vers production.

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 Les canaux conservent leurs propres bundles sans affecter cet appareil.

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

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

2. Laisser un appareil choisir un canal

Ce tutoriel utilise setChannel() et unsetChannel() depuis @capgo/capacitor-updater sur Android et iOS ; ces méthodes ne sont pas prises en charge 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 anciennes versions écrivaient plutôt un override backend ; ces affectations suivent les règles de conservation des overrides de console et API.

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 ce choix localement pour les futures vérifications 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 application, ouvrez Appareils, et sélectionnez un appareil. Modifiez son Override du canal vers dev. Capgo route désormais cet appareil vers dev, while the app’s cloud default remains 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() enregistrait l'override de canal dans la base de données backend (comme les changements depuis 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 ne lit que le backend (pour validation) et stocke en local, ce qui rend les changements de canal instantanés.

Parce que setChannel() est uniquement local, il ne pas créez 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 publique.

Note : Même si un canal devient non autorisé après avoir été configuré localement, le backend validera toujours le canal lors des vérifications de mise à jour, garantissant ainsi la sécurité.

Important : Lorsque vous modifiez un canal via le dashboard ou API, il peut y avoir jusqu'à 2 minutes de délai de réplication avant que tous les serveurs edge ne prennent en compte le changement. Pour changer de canal instantanément, 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 forcé, override ou local n'existe, l'application démarre sur ce canal (ex. beta, qa, pr-123). Destiné aux builds TestFlight ou 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 classiques (sans force, sans override via le dashboard/API, sans canal local du plugin, sans defaultChannel dans la config) y sont rattachés. Modifiez-le pour faire 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. Vous pouvez aussi ne définir aucun canal par défaut 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 les overrides par appareil).
• Configurez uniquement defaultChannel dans les binaires que vous envoyez explicitement aux testeurs. Laisser ce champ vide centralise 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 appareils. L'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. À partir du plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0, cette affectation est locale et n'est pas supprimée par ce nettoyage. Sur Android et iOS avec l'updater 8.51.0 et les versions ultérieures, persistDefaultChannelOnReinstall par défaut sur true, donc l'affectation ne survit à une réinstallation que si l'OS restaure les données de l'app 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() les 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 mène vers Informations sur l'application. Le réglage par défaut n'est plus un bouton bascule sur la page du canal. Lorsque vous remplacez un canal par défaut, les nouveaux appareils suivent immédiatement le nouveau routage et les appareils existants appliquent 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. Rendez-vous dans la section « Channels » du dashboard Capgo
2. Cliquez sur le bouton « Nouveau canal »
3. Saisissez un nom pour le canal et cliquez sur « Créer »

Les noms de canaux peuvent être ce que vous voulez. Une stratégie courante consiste à les aligner sur vos étapes de développement, par exemple :

• Development - pour tester les live updates sur des appareils locaux ou des émulateurs
• QA - pour que votre équipe QA valide 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, mieux vaut l'omettre afin que les appareils utilisent le Cloud Default, sauf override 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 synchronisation, vos projets natifs continueront d'utiliser le canal pour lequel ils étaient configurés auparavant.

Attention

Ordre de sélection du canal : Force > Dashboard/Surcharge de l'appareil API > 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 override 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 : autoriser les mises à jour des builds de production (store). Laissez cette option activée pour les canaux destinés aux utilisateurs réels. CLI --prod / --no-prod.
• Autoriser les émulateurs : autoriser les mises à jour sur les émulateurs/simulateurs (utile pour les tests). CLI --emulator / --no-emulator.
• Allow physical devices: Permit updates to real phones and tablets. Leave this on for production channels. CLI: --device / --no-device.
• Autoriser l’auto-assignation de l’appareil : permet à l’app de basculer vers ce canal à l’exécution en utilisant setChannel. Si désactivée, 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 où les testeurs basculent entre les canaux
• Flux d'adhésion aux programmes bêta
• Implémentations de feature flags
• 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
});

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 enregistré dans le stockage local de l’appareil en defaultChannel
3. Effet immédiat: La prochaine vérification de mise à jour utilise le nouveau canal immédiatement (sans attendre la réplication)

Pourquoi c’est important : Dans les anciennes versions, setChannel() a enregistré l’override de canal dans la base de données backend (comme pour les changements via le dashboard ou API). Les appareils devaient attendre la réplication backend (jusqu’à 2 minutes) avant que le changement de canal ne prenne effet. Désormais, setChannel() ne lit que depuis le backend (pour validation) et stocke localement, rendant les changements de canal instantanés.

Visibilité dans le dashboard : Un canal défini avec le plugin ne fait pas apparaître l’appareil comme Device Override dans l’interface Capgo. Seules les affectations de canal créées depuis le dashboard ou l’API publique y sont listées. Utilisez le dashboard ou API lorsque vous avez besoin d’un override visible par l’administrateur.

Note de sécurité : Même si les permissions d’un canal changent après avoir été définies localement (par exemple, l’auto-affectation est désactivée), le backend valide 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 canal :

Méthode	Délai d'effet	Emplacement de persistance	Affiché dans l’interface Device Override	Expire	Cas d’usage
setChannel() depuis le plugin	Instantané	Appareil uniquement (local)	Non	Aucune expiration automatique ; effacer avec unsetChannel() (une réinstallation peut le conserver)	Changement de canal par l'utilisateur dans l'app
Surcharge 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
Affectation 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() méthode.

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 dans toutes les versions majeures (par 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 la commande 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 CLI s'incrémente à partir du bundle lié au canal jusqu'à ce qu'un nom libre soit trouvé. Avec ai, Workers AI déduit le niveau en comparant le delta manifest local au précédent (repli sur 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 exprime clairement la relation entre les builds. 1.2.3-beta.1 est clairement une pré-release de 1.2.3.
• Elle permet de réutiliser les numéros de version entre les canaux, ce qui limite la confusion.
• Elle permet des chemins de rollback clairs. Si vous devez revenir en arrière depuis 1.2.3, vous savez que 1.2.2 est la release stable précédente.

Voici un exemple pour aligner les versions de vos bundles avec une configuration de canaux 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.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 GitHub Actions, exécutez les jobs de preview avec 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 le suivant :

1. Installer le Capgo SDK dans votre application
2. Configurer l’application pour écouter le canal souhaité
3. Envoyer un build et l’associer à ce canal
4. Lancer l’application et attendre la mise à jour !

Pour un guide plus détaillé, consultez le Déployer des live updates guide. Bonne mise à jour !

Usage avancé des canaux : segmentation des utilisateurs

Les canaux ne servent pas qu’aux étapes de développement. Ils constituent un outil puissant de segmentation des utilisateurs, qui permet des fonctionnalités comme :

• Feature flags pour différents niveaux d'utilisateurs
• Tests A/B
• Déploiements progressifs de fonctionnalités
• Programmes de bêta-test

Découvrez comment implémenter ces cas d'usage avancés dans notre guide : Comment segmenter les utilisateurs par plan et par canal 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 dans la solution de test bêta, Solution de ciblage de version pour le workflow produit dans la solution de ciblage de version, et Bonnes pratiques pour l'environnement Capgo : staging avec un seul ID d'app mobile pour le contexte pratique dans Capgo : bonnes pratiques d’environnement : staging avec un seul ID d’app mobile.