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

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écutez npx cap sync
2. Construirez une nouvelle version 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 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 à jour (development, production), pas des tickets, des fonctionnalités ou des noms de développeurs.

---

Liste de vérification 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 self-set off, bloc de mises à jour sous native on, garde de mise à jour automatique on major.

4. Chaîne de test (development / staging): public off, appareil self-set on pour QA.

5. Télécharger depuis CI avec --delta (coche de somme et 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 Vérifiez-l’avant de l'uploader.

6. Déployez en production seulement après avoir testé, à partir de la ou __CAPGO_KEEP_0__. or CLI.

7. invitez une fois, avec les permissions les moins élevées, 2FA pour l'org, une seule clé __CAPGO_KEEP_0__ dans CI. 2FA pour l'organisation, 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 + production. Téléversez 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 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 de l'ensemble vs commentaire

Noms de bundle sont obligatoires à suivre 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 tester SemVer avant l'upload.

• Noms = semver à partir de CI, par exemple 1.8.0, 1.8.0-beta.1, ou 1.8.0-20260629.42
• Commentaires = 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.PATCH. Par exemple, conservez 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.2. N'inventez pas de formats personnalisés comme fix-login-bug ou 2.5.2026062306context : texte HTML fragment d'une chaîne de Capgo UI plus longue (clé parente `alternatives_cta_questions`). Page/zone : page de comparaison des alternatives de mise à jour en direct de Capacitor. Rôle : long paragraphe de marketing ou juridique. Vu dans : page alternatives.astro. Conservez les termes de produit et de marque de Capgo ainsi que les termes de développeur exactement. Clé de message `alternatives_cta_questions` (Questions de CTA pour les alternatives). | Texte HTML fragment d'une chaîne de Capgo UI plus longue (clé parente `appflow_cta_questions`). Page/zone : page de comparaison/migration de Appflow. Rôle : long paragraphe de marketing ou juridique. Vu 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_cta_questions` (Questions de CTA pour Appflow). | Texte HTML fragment d'une chaîne de Capgo UI plus longue (clé parente `capwesome_cta_questions`). Page/zone : page de comparaison de Capawesome. Rôle : long paragraphe de marketing ou juridique. Vu dans : page capwesome.astro. Conservez les termes de produit et de marque de Capgo ainsi que les termes de développeur exactement. Clé de message `capwesome_cta_questions` (Questions de CTA pour Capwesome). | Texte HTML fragment d'une chaîne de Capgo UI plus longue (clé parente `consulting_faq_subtitle`). Page/zone : page de services de conseil. Rôle : sous-titre ou slogan de section. Vu dans : page consulting.astro. Conservez les termes de produit et de marque de Capgo ainsi que les termes de développeur exactement. Clé de message `consulting_faq_subtitle` (Sous-titre FAQ pour les services de conseil). | Page/zone : page de comparaison/migration d'Appflow. Rôle : étiquette de navigation ou élément de navigation court. Vu dans : page ionic-appflow.astro, page ionic-enterprise-plugins.astro, page solutions/ionic-enterprise-plugins.astro. Clé de message `appflow_plugins_or` (Appflow Plugins ou)

pré-version. Ils ne sont pas valides semver et les téléchargements échoueront ou se comporteront de manière imprévisible. --commentInsérez les notes de version dans

, pas dans le nom du bundle. ciblage de version et et.

---

gestion de version de bundle

--delta Section intitulée « Envoi de delta » envoie un manifeste

de sorte que 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 contexte : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page trust.astro. Clé de message `and` (Et).

garde le zip complet en tant que sauvegarde. C'est bon quand le coût de stockage n'est pas votre principale préoccupation. --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

Coller dans le presse-papier --delta-only Utilisez lorsque vous voulez réduire Capgo stockage. Seuls les fichiers delta/manifest sont stockés, pas le zip complet. Choisissez cette option pour les applications volumineuses ou un volume d'envoi élevé où le stockage s'accumule.

Compromis : sans le backup zip sur le serveur, vous vous appuyez entièrement sur le chemin de manifeste. Passer --delta-only à moins que vous n'ayez vraiment besoin de l'économie de stockage.

Aucune configuration supplémentaire de plugin n'est requise sur le dispositif. Le metteur à jour 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 version 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 à jour permanentes
Noms de canaux CI dynamiques	Noms fixes : development, production
Nombre de canaux trop élevé pour une application simple	Démarrer avec 1-2 canaux
Appareil configuré automatiquement en production	Désactivé pour la production, activé pour les canaux de test
Passer par là --delta	Ajouter --delta à l'envoi ; utilisez-le --delta-only seulement lorsque vous avez besoin de sauvegarder de l'espace de stockage
Noms de bundles non conforme à la 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 marques de version préliminaires 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 Défauts, priorité et routage.

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

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

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