Liste de vérification de configuration unique

Vous avez terminé l'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

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écutez npx cap sync
2. Construirez une nouvelle version iOS / Android
3. Soumettrez à l'App Store, Play Store, TestFlight ou votre distribution interne

Les utilisateurs d'une ancienne version du magasin sans le plugin ne recevront jamais les mises à jour en temps réel. L'upload des bundles vers Capgo n'affecte que les appareils sur une version Capgo-activée.

Voir aussi le dépannage.

Règle : les canaux sont des voies de mise en production (development, production), pas des tickets, des fonctionnalités ou des noms de développeurs.

---

Checklist de configuration unique

1. Créer des canaux : choisir l'ensemble le plus petit qui convient (voir ci-dessous).

2. Définir le canal d'upload par défaut dans paramètres de l'application:

   • Application solo → production
   • Équipe → development

3. Canal de production : public on, appareil auto-arrêté, bloc des mises à jour sous native on, garde de mise à jour automatique on major.

4. Chaîne de test (development / staging): public off, appareil auto-arrêté pour QA.

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

   Le --bundle valeur doit être valide gestion de versionnement semantiqueVérifiez-l’avant de l'uploader 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é : invitez une fois, les permissions les moins élevées, 2FA pour l'org, une seule clé API dans CI.

Chiffrement des données, min_update_version, métadonnées et aperçu désactivé sauf si vous avez une raison claire.

---

Choisissez votre taille

Simple: 1 application, 1 canal : production

Équipe: development + productionEnvoyez vers le développement, déployez vers la production.

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

Beaucoup d'applications: même modèle simple par application (généralement un production chacune). N'installez pas de canaux supplémentaires uniquement 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 du paquet vs commentaire

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

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

Utilisez semver pré-version étiquettes (la partie après -) lorsque vous expédiez de nombreuses versions sous le même MAJOR.MINOR.PATCH . Par exemple, gardez 1.8.0 et ajoutez la date ou le compteur de version dans la pré-version : 1.8.0-20260629.1, 1.8.0-beta.2 . N'inventez pas de formats personnalisés comme fix-login-bug ou 2.5.2026062306 . Ils ne sont pas valides semver et les téléchargements échoueront ou se comporteront de manière imprévisible.

Placez les notes de version dans --comment , pas dans le nom du bundle.

Voir également __CAPGO_KEEP_0__ ciblage de version et et.

---

__CAPGO_KEEP_0__ gestion de version de bundle

--delta Section intitulée « Téléchargement delta » __CAPGO_KEEP_0__ télécharge __CAPGO_KEEP_0__ manifeste

Ainsi, les appareils téléchargent uniquement les fichiers modifiés au lieu du bundle complet à chaque fois. Le checksum est toujours calculé automatiquement. Vous n'avez pas besoin de passer un flag de checksum. --delta Par défaut :

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

C'est la configuration recommandée par défaut pour la plupart des applications. Capgo stocke le manifeste et garde le zip complet en tant que sauvegarde. C'est une bonne option lorsque le coût de stockage n'est pas votre principale préoccupation.

Économie de stockage : --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 souhaitez réduire __CAPGO_KEEP_0__ stockage reduce Capgo storageUtilisez lorsque vous souhaitez réduire le stockage __CAPGO_KEEP_0__.

Compromis : sans le sauvegarde zip sur le serveur, vous vous appuyez entièrement sur le chemin de manifeste. Passer --delta-only sauf si vous avez besoin effectivement des économies de stockage.

Aucune configuration supplémentaire du plugin n'est requise sur le dispositif. L'actualiseur lit le manifeste et récupère uniquement les fichiers modifiés.

Conseil

Voir les mises à jour delta pour le dépannage et directUpdate le comportement.

---

Flux quotidien

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

---

Erreurs courantes

Erreur	Correction
Attendre les mises à jour OTA avant une nouvelle mise en ligne de magasin	Rebâtir et envoyer l'application native après avoir ajouté le plugin
Télécharger un bundle mais ne pas déployer sur un canal	Attribuer le bundle à un canal (par exemple production)
Un canal par fonctionnalité, ticket ou développeur	Utiliser uniquement les voies de mise en ligne permanentes
Noms de canaux CI dynamiques	Noms fixes : development, production
Trop de canaux pour une application simple	Commencez par 1-2 canaux
Appareil auto-configuré en production	Éteint pour la production, allumé pour les canaux de test
Passer par là --delta	Ajouter --delta aux téléchargements; utilisez-le --delta-only seulement lorsque vous avez besoin de sauvegarder de l'espace de stockage
Noms de bundles non-semver	Suivez la versionnement semantique et validez dans le SemVer tester
Changement de schéma de versionnement au fil du temps	Conservation de semver; utilisation de labels de pré-version pour les builds supplémentaires (1.8.0-20260629.1)
Metadata / prévisualisation activée sans raison	Laissé par défaut

---

En savoir plus

Canaux Paramètres par défaut, 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.