Checklist de configuration initiale

Copiez un prompt de configuration avec les étapes d'installation et le guide markdown complet pour ce plugin.

Vous avez terminé onboarding. Configure maintenant Capgo once. Ensuite, votre quotidien sera simplement upload → test → deploy.

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

Checklist de configuration initiale

Créer des canaux: choisissez l'ensemble le plus restreint (voir ci-dessous).
Définir le canal d'upload par défaut dans paramètres de l'app:
- App solo → production
- Équipe → development
Canal de production : public activé, appareil configuré sur off, blocage des mises à jour sous native activé, garde auto-update activée major.
Canal de test (development / staging): public off, device self-set on pour la QA.
Upload depuis la CI avec --delta (le checksum et les dépendances natives sont automatiques) :
Fenêtre de terminal
```
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 devez doit être valide versionnage sémantique. Validez-le dans le testeur SemVer avant l'upload.
Déployer en production seulement après les tests, depuis le dashboard ou CLI.
Équipe et sécurité : invitez une fois, permissions minimales, 2FA pour l'organisation, une clé API en CI.

Laissez le chiffrement, min_update_version, les métadonnées et l'aperçu désactivés sauf si vous avez une raison précise.

Choisissez votre taille

Simple : 1 app, 1 canal : production

Équipe: development + production. Envoyez vers le dev, déployez vers la prod.

Versions natives : ajoutez des canaux uniquement si nécessaire, ex : production-9.0 + test-9.0. Gardez les utilisateurs du store sur le canal de prod principal.

Plusieurs apps : même modèle simple par app (généralement un production chacune). Ne créez pas de canaux en trop juste parce que l'organisation est grande.

Train de release (optionnel) : staging → rc → production. Le même template pour chaque application concernée.

Nom du bundle vs commentaire

Les noms de bundle sont obligatoires pour respecter le versionnement sémantiqueCapgo utilise le semver pour les vérifications de compatibilité, les règles d'auto-update des canaux et les rollbacks. Validez chaque nom dans le SemVer test avant l'upload.

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

Utilisez le semver pre-release labels (la partie après -) quand vous déployez plusieurs builds sous le même MAJOR.MINOR.PATCH. Par exemple, gardez 1.8.0 et ajoutez la date ou le compteur de build dans la pré-release : 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 respectent pas le semver et l'upload échouera ou se comportera de manière imprévisible.

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

Voir aussi ciblage de version et le versioning de bundle.

L'upload delta

--delta uploads fichiers delta pour que les appareils ne téléchargent que les fichiers modifiés au lieu du bundle complet à chaque fois. Le checksum est toujours calculé automatiquement. Vous n'avez pas besoin de passer de flag checksum.

Par défaut : `--delta` (fichiers delta + backup zip)

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

C'est l'option par défaut recommandée pour la plupart des apps. Capgo stocke les fichiers delta et conserve le zip complet comme backup. Les appareils utilisant une ancienne version de plugin sans support Delta utiliseront le zip. Idéal si le coût de stockage n'est pas votre priorité.

É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 le stockage de Capgo. Seuls les fichiers delta sont stockés, pas le zip complet. Choisissez cette option pour les applications volumineuses ou les volumes d'upload élevés où le stockage s'accumule.

Compromis : sans la sauvegarde zip sur le serveur, vous dépendez entièrement des fichiers delta, et les appareils sur une ancienne version de plugin sans support Delta ne pourront pas se mettre à jour. Ignorer --delta-only à moins que vous n'ayez réellement besoin d'économiser du stockage.

Aucune configuration de plugin supplémentaire n'est requise sur l'appareil. L'updater lit la liste des fichiers delta et ne récupère que les fichiers modifiés.

Workflow quotidien

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

Erreurs courantes

Erreur	Correction
Expecting OTA before a new store release	Recompiler et déployer l'app native après l'ajout du plugin
Envoyer un bundle sans le déployer sur un canal	Assigner le bundle à un canal (ex. `production`)
Un canal par fonctionnalité, ticket ou développeur	Utiliser uniquement des canaux de release permanents
Noms de canaux CI dynamiques	Noms fixes : `development`, `production`
Trop de canaux pour une application simple	Commencer avec 1 ou 2 canaux
Auto-configuration de l'appareil en production	Désactivé en production, activé pour les canaux de test
Passer `--delta`	Ajouter `--delta` pour l'upload ; utilisez `--delta-only` uniquement si vous devez économiser du stockage
Noms de bundles non-semver	Suivez le versionnement sémantique et validez avec le testeur SemVer
Changer de schéma de versionnage au fil du temps	Keep semver; use pre-release labels for extra builds (`1.8.0-20260629.1`)
Métadonnées / preview activées sans raison	Désactivé par défaut

En savoir plus

Canaux Valeurs par défaut, priorité et routage.

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

CI/CD Automatisez l'upload et le déploiement.

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

Checklist de configuration initiale