Canal

Un canal d'actualisation en temps réel pointe vers une version spécifique du build JS de votre application qui sera partagée avec tous les appareils configurés pour écouter ce canal pour les mises à jour. Lorsque vous installez le canal d'actualisation en temps réel Capgo de SDK dans votre application, tout binôme natif configuré pour ce canal vérifie les mises à jour disponibles chaque fois que l'application est lancée. Vous pouvez modifier la version du build vers laquelle 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 ne fournissent pas de confidentialité.

Les canaux contrôlent l'éligibilité aux mises à jour, pas la sécrétion des bundles. Même si un canal est privé ou que la désignation automatique est désactivée, tout bundle non chiffré uploadé à Capgo devrait toujours être considéré comme un actif public livré aux clients. La protection de la voie de livraison et de l'authenticité des mises à jour protège, mais les bundles 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 La chiffrage des mises à jour en direct pour plus de détails.

Comment un appareil choisit un canal (prééminence)

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. La mise en correspondance du dispositif forcé (Tableau de bord) – Fixez manuellement un ID de dispositif spécifique à un canal. Utilisez pour des débogages urgents ou des tests contrôlés avec un seul utilisateur réel. Cela l'emporte toujours. Capgo supprime la correspondance 90 jours après la dernière écriture de mise à jour. Voir Les suppressions de console et de API expirent après 90 jours.
2. La mise en correspondance par nuage (par appareil) via Tableau de bord ou API – Créée lorsque vous changez le canal du dispositif 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 utilisateur. La réinstallation du binôme ne le supprime pas ; la suppression de la mise en correspondance du dispositif supprime. La même durée de conservation de 90 jours s'applique.
3. Plugin setChannel() canal local – Créé lorsque l'application appelle setChannel() et le serveur de backend valide que le canal cible autorise l'auto-assignation. Le canal sélectionné est stocké localement sur cet appareil, prend effet instantanément et n'est pas affiché dans l'interface Utilisateur de Surcharge de Dispositif.

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 : il contacte le serveur de 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 en raison de defaultChannel. Cela signifie que le nouveau canal prend effet instantanément pour la prochaine vérification de mise à jour—pas d'attente pour la réplication.

Jusqu'à présent, setChannel() enregistrait le canal de substitution dans la base de données backend (comme le tableau de bord ou les modifications de API), 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 dans le backend (pour la validation) et stocke localement, ce qui permet des changements de canal instantanés.

Parce que setChannel() est local-only, il ne crée pas d'entrée de substitution de appareil dans le tableau de bord de Capgo. L'interface de substitution de appareil ne montre que les substitutions créées à partir du tableau de bord ou du Public API.

Remarque : Même si un canal devient interdit après avoir été défini localement, le backend valide toujours le canal pendant les vérifications de mise à jour, de sorte que la sécurité est maintenue.

Importants : Lorsque des modifications de canal sont effectuées via le tableau de bord ou API, il existe encore un retard de réplication pouvant aller jusqu'à 2 minutes avant que tous les serveurs de bord réfléchissent la modification. Pour un changement de canal instantané, utilisez setChannel() à partir de votre application code—elle valide avec l'arrière-plan, puis définit le canal localement pour un effet immédiat.

4. Capacitor de configuration defaultChannel (défaut de build de test) – Si présent dans capacitor.config.* et qu'aucun canal forcé/forcé/local n'existe, l'application démarre sur ce canal (par exemple, beta, qa, pr-123Intégré pour les builds TestFlight / internes afin que les testeurs atterrissent automatiquement sur un canal de pré-version. Les builds de production laissent généralement cela non défini.
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 tableau de bord/API de surcharge, sans plugin local canal, sans config defaultChannel) s'y attachent. Modifiez-le pour lancer ou annuler instantanément—sans nouvelle version binaire. Si vous avez des valeurs par défaut spécifiques aux plateformes (par exemple, un iOS uniquement, un Android uniquement, un Electron uniquement), chaque appareil 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 cloud, les utilisateurs réels devraient s'y connecter. Si vous choisissez de ne pas le définir, soyez délibéré sur la façon dont les utilisateurs s'y attachent (généralement via defaultChannel en config ou sur les paramètres spécifiques à chaque appareil).
• Seul configurez defaultChannel en binaires que vous envoyez explicitement aux testeurs. Laisser cette option non définie garde la logique de production centralisée dans le tableau de bord.
• Utilisez setChannel() avec parcimonie en production—principalement pour les tests de qualité ou les diagnostics ciblés.

S'il est désactivé pour la plateforme (iOS/Android/Electron) lorsqu'il serait autrement choisi, le processus de sélection le passe et continue sur la liste.

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

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

Les mappages imposés et les canaux de tableau de bord ou publics API sont stockés comme affectations par appareil dans Capgo. Un job de nettoyage supprime ces affectations 90 jours après la dernière écriture de la mise à jourLa vérification de mise à jour n'arrête pas ce compteur. Seule l'écriture de la mise à jour à nouveau (ou la suppression par vous-même) change la date.

Ceci n'est pas la même chose que la conservation de l'inventaire des appareils. L'inventaire supprime les appareils qui n'ont pas été connectés à Capgo pendant 90 jours. La suppression de la mise à jour supprime même la correspondance si l'appareil est toujours actif.

Pour une affectation qui n'est pas supprimée par cette suppression :

• Fixer defaultChannel en capacitor.config.* (survient à la réinstallation ; nécessite un nouveau code natif pour le modifier ultérieurement).
• Appeler setChannel() context : fragment de texte HTML d'une chaîne de Capgo UI plus longue (clé parente `appflow_migration_step2`). Page/zone : Comparaison et migration de l'Appflow / marketing de copie. Rôle : Phrase de copie du site Web. Voir dans : page ionic-appflow.astro. Conservez les termes de produit et de marque de Capgo ainsi que les termes de développeur exactement. Clé de message `appflow_migration_step2` (Étape 2 de la migration de l'Appflow). setChannel() à partir de l'application. Sur le plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 et ultérieur, cette affectation est locale et n'est pas supprimée par cette suppression. La réinstallation de l'application la supprime, il faut donc appeler à nouveau si vous voulez toujours ce canal.

La chaîne Appareils tab and the device Override UI only list console and Public API assignments. They do not list every device on the channel, and they do not list local setChannel() Affectations.

Remarque de rétention de la configuration de l'appareil sur la page des appareils de la chaîne.

Comportement par défaut de la chaîne

Fixer un paramètre par défaut est facultatif, mais il sert généralement de chemin par défaut pour les nouveaux appareils. Sans cela, seuls les appareils qui correspondent aux mappages imposés, aux réglages de la configuration ou à un defaultChannel paramètre dans la Capacitor config recevront des mises à jour. Lorsque vous choisissez de marquer les paramètres par défaut, gardez ces modèles à l'esprit :

• Paramètre par défaut unique (le plus courant) – Si une chaîne a iOS, Android et Electron activés, elle devient le paramètre par défaut unique ; tout appareil sans réglages de la configuration attachera ici.
• Paramètres par plateforme par défaut – Si vous divisez les canaux 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 canal comme le paramètre par défaut de sa plateforme. Les appareils iOS se connectent au canal par défaut iOS, les appareils Android se connectent au canal par défaut Android, et les applications Electron se connectent au canal par défaut Electron.

Rappelez-vous que le canal par défaut cloud et defaultChannel les deux occupent le même niveau de décision. Si vous définissez un canal par défaut cloud, vous n'avez pas besoin de dupliquer la valeur dans votre __CAPGO_KEEP_0__ config—laissez capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel pour les binaires que vous envoyez intentionnellement aux testeurs ou à la QA lorsque vous voulez qu'ils commencent sur un canal non de production même si le canal par défaut cloud est différent. defaultChannel Vous pouvez modifier les paramètres par défaut à tout moment dans le tableau de bord. Ouvrez le canal, puis

Gérer dans les paramètres de l'application Paramètres par plateforme par défautqui vous amène à Informations sur l'application. La valeur par défaut n'est plus un commutateur sur la page du canal. Lorsque vous changez une valeur par défaut, les nouveaux appareils suivent immédiatement la nouvelle configuration de routage et les appareils existants suivent les règles de priorité normales la prochaine fois qu'ils se connectent.

Configuration d'un Canal

Durant l'inscription, vous créez le premier canal (la plupart des équipes le nomment « Production »), mais rien n'est verrouillé — vous pouvez renommer ou supprimer n'importe quel canal à tout moment. Pour ajouter des canaux supplémentaires ultérieurement :

1. Allez dans la section « Canaux » du tableau de bord Capgo
2. Cliquez sur le bouton « Nouveau Canal »
3. Entrez un nom pour le canal et cliquez sur « Créer »

Les noms de canaux peuvent être n'importe quoi. Une stratégie courante est de 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 que votre équipe QA vérifie les mises à jour avant une diffusion plus large
• Staging - pour les tests finals dans un environnement similaire à la production
• Production - pour la version de votre application que les utilisateurs finals reçoivent depuis les magasins d'applications

Configuration du canal dans votre application

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

Ouvrez votre capacitor.config.ts (ou capacitor.config.json) fichier. Dans la section plugins optionnellement définissez defaultChannel pour les builds de test protectedTokens (intérieur / QA). Pour les builds de production, préférez l'omettre afin que les appareils utilisent la valeur par défaut de Cloud, sauf si elle est explicitement surchargée.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Ensuite, construisez votre application web et exécutez npx cap sync pour copier le fichier de configuration mis à jour vers vos projets iOS, Android et Electron. Si vous passez cette étape de synchronisation, vos projets natifs continueront à utiliser la chaîne qu'ils étaient configurés pour.

Attention

Ordre de sélection de la chaîne : Force > API de l'interface utilisateur > Plugin setChannel() chaîne locale > Config defaultChannel > Valeur par défaut de Cloud.

Utilisez defaultChannel seulement dans les builds de test/intérieur ; laissez-le de côté pour la production afin que les utilisateurs suivent la valeur par défaut de Cloud (lorsqu'elle est définie) plutôt que de dupliquer la configuration de routage dans la config native.

Vous pouvez toujours forcer (fixer) un appareil ou appliquer une surcharge ultérieurement — celles-ci supplantent immédiatement la valeur de la config.

Les noms de canal sont sensibles à la casse.

Options et stratégies de canal

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

• Canal par défaut : Marquez facultativement le canal ou les canaux spécifiques au plateau qui les nouveaux appareils s'attachent. Dans la console, cela se trouve dans l'information de l'application (Gérer dans les paramètres de l'application à partir de la page du canal). Voir « Comportement du canal par défaut » pour les scénarios de routage.
• Filtres de plateforme : Activer ou désactiver la livraison vers les iOS, Androidou les appareils par canal. Electron Désactiver la mise à niveau automatique sous native : Empêche de l'envoyer une mise à jour lorsque la version native de l'appareil est plus récente que le paquet 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 (utiles pour les tests). __CAPGO_KEEP_0__ :
• Permettre les builds de développement : Autoriser les mises à jour des builds de développement (utiles pour les tests). CLI : --dev / --no-dev.
• Permettre les builds de production : Autoriser les mises à jour des builds de production (magasin). Laissez cela activé pour les canaux qui servent des utilisateurs réels. CLI: --prod / --no-prod.
• Permettre les appareils émulateurs : Autoriser les mises à jour des émulateurs/simulateurs (utiles pour les tests). CLI: --emulator / --no-emulator.
• Permettre les appareils physiques : Autoriser les mises à jour de vrais téléphones et tablettes. Laissez cela activé pour les canaux de production. CLI: --device / --no-device.
• Permettre l'auto-assignation des appareils : Permet à l'application de passer à ce canal en temps de exécution à l'aide de setChannelSi désactivé, setChannel échouera pour ce canal. CLI: --self-assign / --no-self-assign.
• Package de mise à jour : Choisissez si les appareils téléchargent un zip complet, un delta de fichiers modifiés ou les deux (all, zip, delta, zip_from_builtin, delta_from_builtinVoir Package de mise à jour pour le menu déroulant de la console et pour savoir quand chaque mode est utile.

Rollouts progressifs

A un canal peut conserver un bundle stable tout en exposant progressivement une cible de mise à jour séparée à un groupe de dispositifs collants. Vous pouvez mettre en pause, reprendre, promouvoir, annuler et configurer une réponse automatique à une erreur sans passer le canal pour tout le monde. Voir Les mises à jour progressives pour le modèle de livraison, le flux de travail de tableau de bord, les champs API et les commandes CLI.

Désactiver les stratégies d'actualisation automatique

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

• majeur : Bloc un bundle 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 bundle cible dont la version majeure ou mineure diffère de version_buildExemple : 1.2.3 -> 1.3.0 is blocked; 1.2.3 -> 1.2.4 is autorisé.
• is autorisé. MAJOR.MINOR.PATCH patch : Mode le plus strict. Bloque toute modification du numéro majeur, mineur ou de patch. Seules les modifications de suffixe sont autorisées pendant 1.0.0-beta.1 -> 1.0.0-beta.2 stays identical. Exemples : 1.0.0+build.1 -> 1.0.0+build.2 is autorisé, 1.0.0 -> 1.0.1 is autorisé,
• metadata: Require a minimum update version metadata on each bundle. Configure via CLI using --min-update-version metadata : Exige une version minimale d'update dans chaque bundle. Configurez via __CAPGO_KEEP_0__ à l'aide de --auto-min-update-versionou
• Si manquant, 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 la compatibilité de semver.

Ces stratégies comparant la cible du canal avec la base native envoyée comme version_build, et non la version téléchargée actuelle envoyée comme version_name.

En savoir plus sur les détails et les exemples dans la stratégie de désactivation des mises à jour à /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

En utilisant setChannel() depuis Votre Application

Cette setChannel() méthode permet à votre application de passer manuellement entre les canaux en temps de exécution. Cela est particulièrement utile pour :

• Menus QA/débogage où les testeurs peuvent passer entre les canaux
• Flux d'adhésion au programme bêta
• Mise en œuvre des 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
});

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

Lorsque setChannel() est appelé :

1. Validation back-end (lecture seule) : Une requête est envoyée vers le back-end Capgo pour valider que le canal est autorisé (en vérifiant les permissions d'autorisation auto-assignation)
2. Mise à jour de la mémoire de stockage locale : Si la validation passe, le canal est enregistré dans la mémoire de stockage locale du dispositif comme 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 la surcharge de canal dans la base de données backend (même chose que les modifications de API ou du tableau de bord). Les appareils devaient attendre la réplication backend (jusqu'à 2 minutes) avant que le changement de canal prenne effet. Maintenant, setChannel() se contente de lire dans le backend (pour la validation) et stocke localement, ce qui rend les changements de canal instantanés.

Visibilité du tableau de bord : Un canal défini avec l'extension ne fait pas apparaître l'appareil comme un surcroît de dispositif dans l'interface utilisateur de Capgo. Seuls les affectations de canal créées à partir du tableau de bord ou de l’API publique sont listés là. Utilisez le tableau de bord ou l’API lorsque vous avez besoin d'un surcroît 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), le backend validera toujours le canal lors des vérifications de mise à jour, ce qui garantit la sécurité.

Comparaison des méthodes de changement de canal :

Méthode	Durée d'effet	Où est persisté	Affiché dans l'interface utilisateur de défaillance de l'appareil	Expiré	Utilisation
setChannel() context : Page/zone : Page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page solutions/cordova-to-capacitor-ai.astro. Clé de message `solutions_cordova_to_capacitor_ai_table_use_case` (Solutions Cordova To Capacitor Ai Table Use Case).	À partir du plugin	Instantané	Seulement sur appareil (local)	Non	Non (jusqu'à ce que vous le modifiiez ou le réinstallez)
Switching de canal utilisateur initié en application en cours d'exécution : page de tableau de bord de défaillance de l'appareil	Jusqu'à 2 min	Base de données backend	Oui	90 jours après la dernière écriture de mise à jour	Changements initiaux par l'administrateur pour des 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 mise à jour	Intégrations backend automatiques

Pour offrir la meilleure expérience utilisateur lors de la création d'interfaces utilisateur de basculement de canal, utilisez toujours le plugin setChannel() méthode.

Versions minimales pour le basculement du 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 exemple, X.34.0 inclut les mêmes fonctionnalités que X est 5, 6, 7 ou 8). Voir l'installation d'un plugin pour les étiquettes de version.

Attribution d'un Bundle à un Canal

Pour déployer une mise à jour en direct, vous devez télécharger une nouvelle build de bundle JS et l'attribuer à un canal. Vous pouvez effectuer 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 Le canal. Tous les applications configurées pour écouter ce canal recevront la mise à jour la prochaine fois qu'elles vérifieront une.

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

Numérotation des Bundles et des Canaux

Il est important de noter que les bundles dans l'Capgo sont mondiaux à votre application, et non spécifiques à des canaux individuels. Le même bundle peut être affecté à plusieurs canaux.

Lorsque vous numérotez vos bundles, nous vous recommandons d'utiliser la numérotation semantique avec l'Capgo Semver Tester et les identificateurs de pré-version pour les builds spécifiques à des canaux. Par exemple, une version bêta pourrait être numérotée comme 1.2.3-beta.1.

Dans 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, metadataou ai ) afin que l'CLI augmente de la version du canal liée jusqu'à trouver un nom gratuit. aiWorkers AI déduit le niveau à partir du delta local par rapport au manifeste précédent (retourne à patch avec aucune version précédente Capgo. Vous ne pouvez pas le combiner avec --bundle. Voir Intégration CI/CD et la CLI référence.

Cette 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.
• Elle permet de réutiliser les numéros de version dans plusieurs canaux, réduisant la confusion.
• Elle permet des chemins de roulage clairs. Si vous devez revenir à 1.2.3, vous savez 1.2.2 est la version de la dernière mise à jour stable.

Voici un exemple de la façon dont vous pouvez aligner les versions de votre bundle avec un schéma de canal typique :

• Development canal : 1.2.3-dev.1, 1.2.3-dev.2et cætera.
• QA canal : 1.2.3-qa.1, 1.2.3-qa.2et cætera.
• Staging canal : 1.2.3-rc.1, 1.2.3-rc.2et cætera.
• Production canal : 1.2.3, 1.2.4et cætera.

En utilisant semver avec des identificateurs de version préalables est une approche recommandée, mais pas strictement requise. La clé est de trouver un schéma de versionnement qui communique clairement les relations entre vos builds et s'aligne sur le processus de développement de votre équipe.

Annuler une mise à jour en direct

Si vous déploiez une mise à jour en direct qui introduit une erreur ou qui doit être réversée, vous pouvez facilement annuler la mise à jour. À partir de la section « Canaux » de la console :

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

La version sélectionnée deviendra immédiatement la version active pour ce canal. Les applications recevront la version rétablie 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 de mise à jour en direct en tant que partie de votre pipeline CI/CD. En intégrant Capgo à votre processus de build, vous pouvez télécharger automatiquement de nouvelles archives et les affecter à des canaux chaque fois que vous poussez vers certaines branches ou créez de nouvelles versions.

Consultez les Intégration CI/CD docs to learn more about automating Capgo live updates.

Prévisualisations avec les privilèges les moins élevés

Utilisez un Prévisualisation d'application une clé API lorsqu'un CI en a besoin pour une canalisation temporaire par demande de tirage, mais ne doit pas gérer les canaux existants par défaut. La clé reste liée à l'organisation propriétaire et à l'application sélectionnée ; elle n'a tout simplement pas de rôl’organisationnel.

1. Créez une clé API sécurisée limitée à l'application de prévisualisation et sélectionnez Prévisualisation d'applicationVoir Clés API.
2. Utilisez un canal unique, non public tel que pr-123Ne passez pas --default, --self-assign, les 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 ensuite le canal et le bundle propriété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 manquant, télécharge le bundle et le promeut en une seule opération. La suppression est atomique et vérifie la propriété : 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/défaut existant, un canal de visionnage d'un autre clé, ou un bundle d'un 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é de visionnage d'application ne peut pas activer les aperçus elle-même car elle n'a pas la permission d'application-settings. Dans GitHub Actions, exécutez les tâches de visionnage secrètes sur pull_request, et non pull_request_target, et les restreindre aux PRs 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 à commencer à déployer des mises à jour en direct sur des appareils réels. Le processus de base est :

1. Installez le Capgo SDK dans votre application
2. Configurez l'application pour écouter votre canal souhaité
3. Téléchargez une build et affectez-l’à ce canal
4. Lancez l'application et attendez l'update !

Pour une présentation détaillée, consultez le guide de mise à jour en direct Mise à jour de canal avancée : segmentation des utilisateurs

guide de mise à jour en direct

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 :

• Des drapeaux de fonctionnalité pour différents niveaux d'utilisateurs
• Des tests A/B
• Des déploiements graduels de fonctionnalités
• Des programmes de test bêta

Apprenez à mettre en œuvre ces cas d'utilisation avancés dans notre guide : Comment segmenter les utilisateurs par abonnement et les canaux pour les drapeaux de fonctionnalité et les tests A/B.

Continuez depuis les canaux

Si vous utilisez Les canaux pour planifier la mise en route du canal et la mise en production étape par étape, connectez-l’à Canaux pour les détails d'implémentation dans Canaux, Canaux pour les détails d'implémentation dans Canaux, Solution de test bêta pour le flux de travail du produit dans Solution de test bêta, Solution de ciblage de version pour le flux de travail du produit dans Solution de ciblage de version, et Capgo Pratiques de l'environnement : Staging avec un ID d'application mobile unique pour le contexte pratique dans Capgo Pratiques de l'environnement : Staging avec un ID d'application mobile unique.