Canaux

Un canal Live Update pointe vers une version spécifique du paquetage 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 Capgo Live Updates SDK dans votre application, tout le code 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 un canal à tout moment et pouvez également revenir à des versions précédentes si nécessaire.

Les canaux ne fournissent pas de confidentialité

Les canaux contrôlent l'éligibilité aux mises à jour, pas la secret des paquets. Même si un canal est privé ou que la désignation automatique est désactivée, tout paquet non chiffré téléchargé sur Capgo devrait toujours être considéré comme un actif public délivré aux clients. La protection par chiffrement protège le chemin de livraison et l'authenticité des mises à jour, mais les paquets expédiés peuvent toujours être déchiffrés à partir de l'application distribuée avec suffisamment d'effort car la clé publique fait partie du client. Voir le chiffrement Live Update pour plus de détails.

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. Mappage 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 gagne toujours. Capgo supprime la cartographie 90 jours après la dernière écriture de prise en charge. Console et API expirent après 90 jours.
2. Surcharge 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 de configuration ne supprime pas la surcharge ; la suppression de la surcharge de l'appareil le fait. La même retenue de 90 jours s'applique.
3. Plugin setChannel() canal local – Créé lorsque l'application appelle setChannel() et que le serveur 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 de surcharge de l'appareil.

Switcher de canal instantané avec setChannel()

À partir de la version de plugin 5.34.0, 6.34.0, 7.34.0 ou 8.0.0 selon votre version majeure, setChannel() fonctionne différemment : elle 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 le dispositif 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.

Jusqu'à présent, setChannel() en a sauvegardé la mise à jour de canal vers la base de données de backend (comme Dashboard 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 vers le backend (pour la validation) et stocke localement, ce qui rend les changements de canal instantanés.

Parce que setChannel() est local-only, il ne not créez une entrée de dérogation pour appareil dans le tableau de bord Capgo. L'interface de dérogation pour appareil ne montre que les dérogations créées à partir du tableau de bord ou de l'espace Public API.

Note: Même si un canal devient interdit après avoir été configuré localement, le serveur valide toujours le canal lors des vérifications de mise à jour, ce qui maintient la sécurité.

Important: When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() À partir de votre application code—elle se synchronise avec le serveur, puis configure le canal localement pour un effet immédiat.

4. Capacitor configuration defaultChannel __CAPGO_KEEP_0__ est remplacé par Dashboard – Si présent dans capacitor.config.* et qu'aucun canal forcé/override/local n'existe, l'application démarre sur ce canal (par exemple, beta, qa, pr-123). Conçu 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.
5. Canal 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 surcharge du tableau de bord/API, sans canal local de plugin, sans configuration par défautChannel) 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 seul pour iOS, un seul pour Android, un seul pour Electron), 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-4 pour recevoir des mises à jour.

Pratique recommandée :

• Traitez 1-4 comme des couches d'exception / de test ; lorsque vous définissez un canal par défaut, les utilisateurs réels devraient y fluer. Si vous ne le définissez pas, soyez délibéré sur la façon dont les utilisateurs s'y attachent (généralement via defaultChannel in config or per-device overrides).
• Configurez defaultChannel Laisser cela non défini garde la logique de production centralisée dans le tableau de bord.
• Utilisez setChannel() Seulement en production—principalement pour les tests ou les diagnostics ciblés.

Si un canal est désactivé pour la plateforme (iOS/Android/Electron), le processus de sélection le passe et continue vers le bas de la liste.

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

La console et les API survol expirent après 90 jours

Les mappages forcés et les survol de Tableau de bord ou Public API 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 de survolVérifier une mise à jour ne réinitialise pas ce chronomètre. Seule l'écriture du survol à nouveau (ou la suppression par vous-même) change la date.

Cela n'est pas le même que la conservation de l'inventaire des appareilsL'inventaire supprime les appareils qui n'ont pas connecté à Capgo pendant 90 jours. Le nettoyage des survol supprime la mise en correspondance même si l'appareil est toujours actif.

Pour une affectation qui n'est pas supprimée par cette mise à jour :

• Définir defaultChannel dans capacitor.config.* survient à la réinstallation ; nécessite un nouveau code natif pour changer plus tard.
• Appeler setChannel() à partir de l'application. Sur la version du plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 et ultérieure, cette affectation est locale et n'est pas supprimée par cette mise à jour. La réinstallation de l'application la supprime, il faut donc appeler setChannel() à nouveau si vous souhaitez toujours ce canal.

Le canal Appareils dans l'onglet Appareils et la liste de console et de Public API des paramètres de prise en charge ne listent pas tous les appareils du canal, et ils ne listent pas les affectations locales. setChannel() assignments.

Supprimez la notice de conservation sur l'onglet appareils du canal.

Comportement de la chaîne par défaut

La définition d'un par défaut cloud est facultative, mais elle sert généralement de chemin par défaut pour les nouveaux appareils. Sans cela, seuls les appareils qui correspondent aux mappages imposés, aux remplacements ou à un defaultChannel config dans le Capacitor config recevront des mises à jour. Lorsque vous choisissez de marquer les valeurs par défaut, gardez ces modèles à l'esprit :

• Un par défaut unique (le plus courant) – Si une chaîne a iOS, Android et Electron activés, elle devient le seul par défaut ; tout appareil sans remplacements s'y attache.
• Par défaut par plateforme – Si vous divisez les chaînes par plateforme (par exemple, ios-production avec uniquement iOS activé, android-production avec uniquement Android activé, et electron-production avec uniquement Electron activé), marquez chaque une comme par défaut pour sa plateforme. Les appareils iOS se dirigent vers le par défaut iOS, les appareils Android vers le par défaut Android et les applications Electron vers le par défaut Electron.

Souvenez-vous que les canaux par défaut du cloud et defaultChannel ceux capacitor.config.* Les deux occupent le même niveau de décision. Si vous définissez un paramètre par défaut dans Cloudflare, vous n'avez pas besoin de dupliquer la valeur dans votre fichier de configuration Capacitor. defaultChannel empty pour les builds de production. Réservez defaultChannel Vous pouvez modifier les paramètres par défaut à tout moment dans le tableau de bord. Ouvrez le canal, puis

Vous pouvez modifier les paramètres par défaut à tout moment dans le tableau de bord. Ouvrez le canal, puis , ce qui vous emmène àInformation sur l'application Informations de l'application. The default is no longer a toggle on the channel page. When you swap a default, new devices obey the new routing immediately and existing devices follow the normal precedence rules the next time they check in.

Section intitulée « Configuration d'un Canal »

Créez le premier canal lors de l'inscription (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. Appuyez sur le bouton « Nouveau Canal »
3. Entrez un nom pour le canal et appuyez sur « Créer »

Les noms de canaux peuvent être n'importe quoi. Une stratégie courante est de faire correspondre les canaux à vos étapes de développement, comme :

• 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 large diffusion
• Staging - pour les tests finals dans un environnement simulant la production
• Production - for the version of your app that end users receive from the app stores

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 Development canal.

Ouvrez votre capacitor.config.ts (ou capacitor.config.jsonfichier. Sous le plugins ) fichier. Sous la defaultChannel for pour (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.
    },
  },
};

Copier dans le presse-papier npx cap sync to copy the updated config file to your iOS, Android, and Electron projects. If you skip this sync step, your native projects will continue to use whichever channel they were previously configured for.

Attention

Ordre de sélection des canaux : Force > Survol du API du dispositif > Plugin setChannel() canal local > Config defaultChannel > par défaut Cloud.

Utiliser defaultChannel seulement dans les builds de test/intérieur ; laissez-le de côté pour la production afin que les utilisateurs suivent le par défaut Cloud (lorsqu'il est défini) au lieu de dupliquer la routage dans la configuration native.

Vous pouvez toujours forcer (fixer) un appareil ou appliquer un surcroît ultérieurement — ceux-ci supplantent immédiatement la valeur de la configuration.

Les noms de canaux sont sensibles à la casse.

Options et stratégies des canaux

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 : Optionnellement marquez les canaux ou les canaux spécifiques au plateau qui attachent de nouveaux appareils. Dans la console, cela se trouve sur l'information de l'application («Gérer les paramètres de l'application dans l'application Voir “Comportement de la chaîne par défaut” pour les scénarios de routage.
• Filtres de plateforme : Activer ou désactiver la livraison vers 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 bundle 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). CLI: --dev / --no-dev.
• Permettre les builds de production : Autoriser les mises à jour des builds de production (magasin). Laisser cela activé pour les canaux qui servent des utilisateurs réels. CLI: --prod / --no-prod.
• Permettre les appareils émulés : Autoriser les mises à jour des émulateurs/simulateurs (utile pour les tests). CLI: --emulator / --no-emulator.
• Permettre les appareils physiques : Autoriser les mises à jour des téléphones et tablettes réels. Laisser cela activé pour les canaux de production. CLI: --device / --no-device.
• Permettre l'auto-assignation du dispositif : permet à l'application de passer à ce canal en temps de exécution 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) Voir Format de téléchargement pour le menu déroulant de la console et lorsque chaque mode est utile.

Déploiements progressifs

Page/area: Page de marketing des solutions Capgo. Role: Étiquette de navigation ou élément UI court. Vu dans: page solutions/cordova-to-capacitor.astro. Message clé `solutions_cordova_to_capacitor_link_rollouts` (Lien Solutions Cordova To Capacitor Rollouts). Déploiements progressifs pour le modèle de livraison, flux de travail de tableau de bord, champs API et commandes CLI.

Désactiver les stratégies d'actualisation automatique

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

• majeur : Bloc un paquet cible dont la version majeure est supérieure à la base de ligne native du dispositif (version_buildExemple : 1.2.3 -> 2.0.0 est bloqué ; 1.2.3 -> 1.9.0 est autorisé.
• mineur : Bloc un paquet cible dont la version majeure ou mineure diffère de version_buildExemple : 1.2.3 -> 1.3.0 est bloqué ; 1.2.3 -> 1.2.4 est autorisé.
• mode strict : Toute modification est interdite, sauf les changements de suffixe. 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 : Exigez une version minimale d'actualisation de métadonnées sur chaque paquet. Configurez via CLI à l'aide de --min-update-version ou --auto-min-update-versionSi absent, le canal est marqué comme non configuré et les mises à jour seront rejetées jusqu'à ce qu'il soit défini.
• aucune : Autorise toutes les mises à jour selon compatibilité de semver.

Ces stratégies comparant le canal cible du paquet avec la base native envoyée sous forme de version_buildet non le paquet téléchargé actuel envoyé sous forme de version_name.

En savoir plus sur les détails et les exemples dans la stratégie d'actualisation Disable à /docs/cli/commands/#disable-updates-strategy.

Exemple (CLI). Le canal doit déjà exister (channel set 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

Utilisation de setChannel() à partir de votre application

Le setChannel() méthode permet à votre application de passer en mode canaux à l'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
});

How fonctionne setChannel() (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Quand setChannel() est appelé :

1. Validation backend (lecture seule): Une requête est envoyée vers le backend Capgo pour valider que le canal est autorisé (vérification des permissions d'auto-assignation)
2. Mise à jour du stockage localSi la validation passe, le canal est sauvegardé dans le stockage local du dispositif. defaultChannel
3. 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 le canal de substitution dans la base de données backend (même chose que le tableau de bord ou les modifications API). Les appareils devaient attendre la réplication backend (jusqu'à 2 minutes) avant que le changement de canal prenne effet. Maintenant, setChannel() seule lecture du backend (pour validation) et stockage local, ce qui rend les changements de canal instantanés.

Visibilité du tableau de bord : Un canal défini avec le plugin ne fait pas apparaître le dispositif comme un Décalage de Dispositif dans l'interface utilisateur de Capgo. Seuls les affectations de canal créées à partir de la table de bord ou de l'espace public API y sont listées. Utilisez la table de bord ou API lorsque vous avez besoin d'un décalage 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, la self-assignment est désactivée), l'arrière-plan validera toujours le canal lors des vérifications d'actualisation, garantissant la sécurité.

Comparaison des méthodes de changement de canal :

Méthode	Durée de l'effet	Persistance dans	Affiché dans l'interface utilisateur de Décalage de Dispositif	Expiration	Utilisation
setChannel() from le plugin	Instantané	Seulement sur appareil (local)	Non	Non (jusqu'à ce que vous le modifiiez ou réinstalliez)	Switcher utilisateur en application
Survol du dashboard pour appareil	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de survol	Modifications administratives pour appareils spécifiques
API affectation de canal	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de surcharge.	Intégrations back-end automatisées

For the best user experience when building channel-switching UIs, always use the plugin’s setChannel() method.

Versions minimales pour le basculement de canal local : 5.34.0, 6.34.0, 7.34.0ou 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 étiquettes de version.

Attribuer un Bundle à un Canal

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

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

Cela téléchargera vos actifs web construits et définira la nouvelle build en tant que build actif pour le Development canal. Tous les applications configurées pour écouter ce canal recevront la mise à jour la prochaine fois qu'elles rechercheront une.

Vous pouvez également attribuer des builds à des canaux à partir de la section « Bundles » du tableau de bord Capgo. Cliquez sur l'icône de menu à côté d'une build et sélectionnez « Attribuer à Canal » pour choisir le canal pour cette build.

Numérotation des Versions de Bundle et 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 attribué à plusieurs canaux.

Lorsque vous versionnez vos bundles, nous vous recommandons d'utiliser la versionnement semantique avec le Semver Tester de Capgo et les identifiants de préversion pour les builds spécifiques au canal. Par exemple, une version bêta pourrait être versionnée comme 1.2.3-beta.1.

En CI, si la version locale était déjà téléchargée, utilisez npx @capgo/cli@latest bundle upload --auto-bump (optionnellement) major, minor, patch/fix, metadata, ou ai) afin que le CLI ne soit plus associé au canal jusqu'à ce qu'un nom gratuit soit trouvé. ai, Workers AI infère le niveau à partir du delta local par rapport au précédent manifest (retourne à patch avec aucune version précédente de Capgo). Vous ne pouvez pas le combiner avec --bundle. Consultez Intégration CI/CD et le CLI référence.

Cet 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.
• 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 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 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.2etc.
• Staging canal : 1.2.3-rc.1, 1.2.3-rc.2etc.
• Production canal : 1.2.3, 1.2.4etc.

En utilisant semver avec identifiants de version préliminaire 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 un Live Update

Si vous déployez un live update qui introduit une erreur ou nécessite d'être réversé, vous pouvez facilement revenir à une version précédente. À partir de la section « Canaux » de la console de bord :

1. Cliquez sur le nom du canal que vous souhaitez annuler
2. Trouvez la build que vous souhaitez rétablir et cliquez sur l'icône de couronne
3. Confirmer l'action

La version de construction sélectionnée deviendra immédiatement la version active pour ce canal. Les applications recevront la version roulée-back la prochaine fois qu'elles vérifient les mises à jour.

Automatiser les déploiements

Pour des workflows plus avancés, vous pouvez automatiser vos déploiements live update en tant que 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 les Intégration CI/CD docs to learn more about automating Capgo live updates.

Aperçu de PR avec privilèges minimal

Utilisez une App Preview API clé lorsqu'un CI nécessite une canal temporaire par demande de tirage mais ne doit pas gérer les canaux principaux/existants. La clé reste liée à l'organisation propriétaire et à l'application sélectionnée ; elle n'a simplement aucune fonction organisationnelle.

1. Disposez d'un administrateur d'organisation pour créer une clé sécurisée API limitée à l'application de prévisualisation et sélectionnez App Preview. Consultez API Clés.
2. Disposez d'un canal unique, non public tel que pr-123. N'envoyez pas --default, --self-assign, options de déploiement ou --delete-linked-bundle-on-upload.
3. Téléchargez et promouvez le bundle PR en une seule commande, puis supprimez le canal et le bundle propriétaires 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 manquant, télécharge le bundle et le promeut en une seule étape. La suppression est atomique et vérifie l'appartenance : la clé peut supprimer uniquement un canal qu'elle a créé et son bundle lié non partagé. Elle ne peut pas modifier, promouvoir ou supprimer un canal principal par défaut existant, un canal d'un autre clé de visionnage ou un bundle d'une autre clé.

Si les réviseurs ont besoin d'un QR code ou d'une URL de visionnage, un administrateur doit activer les aperçus 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é Preview d'application ne peut pas activer les aperçus elle-même car elle n'a pas la permission d'applications-settings. Dans GitHub Actions, exécutez les tâches d'aperçus portant des secrets. pull_request, pas pull_request_target, et restreignez-les aux PR de même-répertoire avec github.event.pull_request.head.repo.full_name == github.repository.

Déploiement sur un appareil

Maintenant que vous comprenez les canaux, vous êtes prêt à commencer à déployer des mises à jour live 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. Téléchargez une build et affectez-l’à ce canal
4. Lancez l'application et attendez l'update !

Pour un guide détaillé, consultez le Mise en ligne de mises à jour en temps réel guide. Bonne mise à jour !

Utilisation Avancée du Canal : Ségrégation 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 :

• Feature flags for different user tiers
• 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 canaux pour les drapeaux de fonctionnalité et les tests A/B.

Continuez depuis les canaux

Si vous utilisez Canaux to plan channel routing and staged rollout, connect it with Canaux pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans les canaux, Solution de test bêta pour le flux de workflow du produit dans Solution de test bêta Solution de ciblage de version pour le flux de travail du produit dans la Solution de ciblage de version. Pratiques de l'environnement Capgo : Mise en scène avec un seul ID d'application mobile pour le contexte pratique dans Capgo Pratiques de l'environnement : mise en scène avec un seul ID d'application mobile.