Liste de vérification de configuration unique

Vous avez terminé l'inscription d'inscription. Maintenant, configurez Capgo une fois. Après cela, le travail quotidien est uniquement télécharger → tester → déployer.

Envoyez une nouvelle mise à jour de magasin en premier

L'installation du plugin Capgo dans votre projet n'est pas suffisante. Les mises à jour OTA ne fonctionnent que sur les appareils exécutant une application native qui inclut déjà le plugin.

Après avoir ajouté Capgo et appelé CapacitorUpdater.notifyAppReady():

1. Exécuter npx cap sync
2. Construire une nouvelle version binaire iOS / Android
3. Soumettre à l'App Store, Play Store, TestFlight ou votre distribution interne

Les utilisateurs d'une version de magasin plus ancienne ne recevront jamais les mises à jour en temps réel sans le plugin. sans the plugin will never receive live updates. Uploading bundles to Capgo only affects devices on a Capgo-enabled binary.

ne recevront jamais les mises à jour en temps réel. La mise en ligne des bundles dans __CAPGO_KEEP_0__ n'affecte que les appareils sur un __CAPGO_KEEP_1__-activé..

Voir aussi le dépannagedevelopment, productionRègle :

---

les canaux sont des voies de lancement (

1. Liste de vérification une fois pour toutesSection intitulée “Liste de vérification une fois pour toutes” : : Créer des canaux, choisissez l'ensemble le plus petit qui convient (voir ci-dessous).

2. Configure le canal de téléchargement par défaut dans paramètres de l'application:

   • Application unique → production
   • Équipe → development

3. Canal de production : public activé, auto-mise à jour activée, mise à jour native bloquée, garde de mise à jour auto activée major.

4. Canal de test (development / staging): public désactivé, auto-mise à jour activée pour les tests.

5. Télécharger depuis CI avec --delta (le checksum et les dépendances natives sont automatiques) :

   npx @capgo/cli@latest bundle upload \
     --channel development \
     --bundle "1.8.0-${BUILD_NUMBER}" \
     --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
     --delta

   La --bundle valeur doit être valide la versionnement sémantique. Validez-le dans le testeur SemVer avant de l'uploader.

6. Déployez en production seulement après avoir testé, à partir de tableau de bord ou CLI.

7. Équipe & sécurité : invite une fois, les permissions les moins élevées, 2FA pour l'org, une clé API dans CI.

Chiffrement partagé, min_update_version, les métadonnées, et la prévisualisation off sauf si vous avez une raison claire.

---

Choisissez votre taille

Simple: 1 application, 1 canal : production

Équipe: development + production. Télécharger sur dev, déployer sur prod.

Versions natives: ajouter des canaux uniquement lorsque nécessaire, par exemple. production-9.0 + test-9.0. Garder les utilisateurs de l'application sur le canal de production principal.

Beaucoup d'applications: même modèle simple par application (généralement un production chacune). Ne créez pas de canaux supplémentaires juste parce que l'organisation est grande.

Train de lancement (facultatif) : staging → rc → production. Même modèle sur chaque application qui en a besoin.

Attention

N'utilisez pas de canaux nommés d'après des tickets, des personnes ou des variables CI comme ${inputs_capgo_channel}.

---

Nom de l'archive vs commentaire

Les noms d'archive sont obligatoires pour suivre la versionnement semantique. Capgo utilise semver pour les vérifications de compatibilité, les règles d'actualisation automatique des canaux et les retours en arrière. Vérifiez chaque nom dans le Testeur de SemVer avant l'upload.

• Nom = semver depuis CI, par exemple. 1.8.0, 1.8.0-beta.1, ou 1.8.0-20260629.42
• Commentaire = texte libre pour les humains → commit abc1234 run 28059070270

Utiliser semver étiquette préalable étiquettes (la partie après -) lorsque vous expédiez de nombreux builds sous le même MAJOR.MINOR.PATCH. Par exemple, garder 1.8.0 et ajouter la date ou le compteur de build dans la pré-étiquette : 1.8.0-20260629.1, 1.8.0-beta.2. Ne créez pas de formats personnalisés comme "ou ". Ils ne sont pas valides semver et les téléchargements échoueront ou comporteront des comportements imprévisibles. fix-login-bug Placez les notes de version dans 2.5.2026062306et non dans le nom du bundle.

Voir aussi --commentciblage de version

et gestion de version de bundle Téléchargement delta Section intitulée “Téléchargement delta”.

---

télécharge

--delta une manifest Ainsi, les appareils téléchargent uniquement les fichiers modifiés au lieu de la version complète à chaque fois. Le checksum est toujours calculé automatiquement. Vous n'avez pas besoin de passer un flag de checksum.

Default : --delta Section intitulée « Default : --delta (manifest + zip backup) »

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --delta

This is the recommended default for most apps. Capgo stores the manifest garde la version zip complète en tant que sauvegarde. C'est utile lorsque le coût de stockage n'est pas votre principale préoccupation. Économie de stockage :

Section intitulée « Économie de stockage : --delta-only » --delta-only

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta-only

Utilisez --delta-only lorsque vous voulez réduire __CAPGO_KEEP_0__ stockage reduce Capgo storageCompromis : sans le zip de sauvegarde sur le serveur, vous vous appuyez entièrement sur le chemin du manifeste. Omittez

sauf si vous avez besoin effectivement des économies de stockage. --delta-only Aucune configuration supplémentaire du plugin n'est requise sur le dispositif. L'actualiseur lit le manifeste et télécharge uniquement les fichiers modifiés.

Conseil

Voir

Fenêtre de terminal Mises à jour Delta pour le dépannage et directUpdate le comportement.

---

Flux de travail quotidien

Upload to development (--delta)
  → test
  → deploy to production
  → don't touch channel settings again

---

Erreurs courantes

Erreur	Réparation
Attendre les mises à jour OTA avant une nouvelle mise à jour de magasin	Rebâtir et expédier l'application native après avoir ajouté le plugin
Télécharger un bundle mais ne pas déployer vers un canal	Attribuer le bundle à un canal (par exemple production)
Un canal par fonctionnalité, ticket ou développeur	Utiliser uniquement les voies de libération permanentes
Noms de canaux CI dynamiques	Noms fixes : development, production
Trop de canaux pour une application simple	Commencez par 1-2 canaux
L'appareil est configuré automatiquement pour la production	Désactivé pour la production, activé pour les canaux de test
Ignorer --delta	Ajouter --delta pour les téléchargements; utilisez --delta-only seulement lorsque vous avez besoin de sauvegarder de l'espace de stockage
Les noms de paquets non-semver	Suivez la versionnement semantique et validez dans le Testeur de SemVer
Le schéma de versionnement change en fonction du temps	Conservez semver; utilisez des étiquettes de pré-version pour les builds supplémentaires (1.8.0-20260629.1)
Métadonnées / aperçu activé sans raison	Désactivez par défaut

---

En savoir plus

Canaux Défauts, priorité et routage.

Mises à jour Delta Pourquoi et comment utiliser --delta.

CI/CD Automatiser l'upload et la mise en ligne.

Bundles Checksum, dépendances et métadonnées.