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 version 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 un nouveau fichier binaire iOS / Android
3. Soumettre à 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 direct. L'upload des bundles vers Capgo n'affecte que les appareils sur un fichier binaire Capgo-activé.

Voir aussi troubleshooting.

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

---

Liste de paramétrage une fois pour toutes

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

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

   • Application solo → production
   • Équipe → development

3. Canal de production : public sur, auto-configuration de l'appareil désactivée, blocage des mises à jour sous native activé, garde de mise à jour automatique activée major.

4. Chaîne de test (development / staging): public off, device self-set on pour les 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 la versionnement semantique. Validez avant de l'uploader. Testeur de SemVer avant de l'uploader.

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

7. Équipe & sécurité : invitez une fois, les moindres permissions, 2FA pour l'org, une seule clé API dans CI.

Laissez l'encryption, min_update_versionmetadata, et aperçu off à moins que vous ayez une raison claire.

---

Sélectionnez votre taille

Simplifié: 1 application, 1 canal : production

Équipe: development + production. Téléchargez sur dev, déployez sur prod.

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 de production principal.

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

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

Prudence

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'ensemble de fichiers vs commentaire

Les noms d'ensemble de fichiers sont version obligatoire suivre les instructions la versionnement semantique 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 l'upload.

• Nom = semver à partir de 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 nombreux builds sous le même MAJOR.MINOR.PATCHPar exemple, gardez 1.8.0 et ajoutez la date ou le compteur de build dans la préversion : 1.8.0-20260629.1, 1.8.0-beta.2N'inventez pas de formats personnalisés comme fix-login-bug ou 2.5.2026062306Ils ne sont pas valides semver et les téléchargements échoueront ou comporteront des comportements imprévisibles.

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

Voir aussi ciblage de version et gestion de version du bundle.

---

Section intitulée « Delta upload »

--delta 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. Par défaut :

(manifeste + sauvegarde zip) --delta Section intitulée « Par défaut : --delta (manifeste + sauvegarde zip) »

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

C'est la valeur recommandée par défaut pour la plupart des applications. Capgo stocke le manifeste et garde la version zip complète en tant que sauvegarde. C'est bon 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

Utiliser --delta-only lorsque vous voulez réduire Capgo stockage. Seuls les fichiers delta/manifest sont stockés, pas la version zip complète. Choisissez cette option pour les applications volumineuses ou un volume d'envoi élevé où le stockage s'accumule.

Compromis : sans la sauvegarde zip sur le serveur, vous vous appuyez entièrement sur le chemin du manifeste. Omittez --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 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	Correction
Attendre la mise à jour OTA avant une nouvelle mise à jour de magasin	Rebâtir et envoyer l'application native après avoir ajouté le plugin
Charger un bundle mais ne pas déployer sur un canal	Attribuer le bundle à un canal (par exemple, un canal par fonctionnalité, ticket ou développeur) production)
Utiliser uniquement les voies de mise à jour permanentes	Noms de canaux CI dynamiques
Noms fixes :	Trop de canaux pour une application simple development, production
Utilisez uniquement les voies de mise à jour permanentes	Commencez avec 1-2 canaux
Appareil configuré automatiquement en production	Désactivé pour la production, activé pour les canaux de test
Sauter --delta	Ajouter --delta aux téléchargements ; utilisez --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 Testeur de SemVer
Modification du schéma de versionnement au fil du temps	__CAPGO_KEEP_0__1.8.0-20260629.1)
Métadonnées / prévisualisation activée sans raison	Désactivé par défaut

---

En savoir plus

Canaux Défauts, priorités et routage.

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

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

Packages Résumé de somme, dépendances et métadonnées.