Bonnes pratiques pour l'environnement Capgo : staging avec un seul ID d'app mobile

Les équipes choisissent généralement l’une de ces trois approches pour leurs environnements mobiles :

1. Deux IDs d’app (production + pré-production)
2. Un seul ID d’app + bascule d’environnement dynamique au runtime
3. Un seul ID d’app + canaux Capgo

Les deux premières options fonctionnent, mais elles créent des frictions à long terme. Dans les équipes réelles, le modèle de canaux Capgo est généralement le plus simple.

Pourquoi les app IDs dupliqués créent du bruit

Utiliser com.myapp et com.myapp.beta semble simple, mais la duplication apparaît rapidement :

• Deux pipelines de release
• Deux ensembles d’IDs push, de deep links et de mapping des entitlements
• Deux identités pour l’analyse et les crashs
• Config divergente et comportement incohérent entre les environnements

Vous finissez par gérer deux produits à travers les consoles des stores, les équipes et les instructions de QA interne.

Pourquoi la config commutable au runtime est souvent un bazar

Le motif « un seul app ID + commutation au runtime » signifie généralement que votre application lit des variables d’environnement ou des flags au démarrage et redirige dynamiquement les API, les clés et le comportement des mises à jour.

Ça fonctionne jusqu'au moment où :

• la QA contourne les flux prévus car l'état de la config est obsolète,
• quelqu'un utilise le mauvais endpoint en production,
• environment drift causes hard-to-repro bugs,
• vous devez déboguer « quelle version de config utilise ce binaire ? » sur l'appareil d'un utilisateur.

Cette complexité croît à chaque release et c'est là que les équipes perdent en vélocité.

La méthode Capgo : un seul ID d'app, plusieurs canaux

Capgo rend explicite le contrôle de l'environnement via les canaux :

• Gardez un seul ID d'app de production sur l'App Store / Play Store.
• Déployez un seul build natif pour la « shell » (jusqu'à ce que des changements natifs nécessitent un nouveau build).
• Gérez le comportement par canal, et non en dupliquant l'identité de l'app.

En pratique, cela signifie :

• production: all users
• staging: QA interne et candidats à la release
• beta: testeurs invités
• hotfix: piste de correctif d’urgence

Votre app de test interne TestFlight/Play peut rester sur staging la version actuelle. Vous y effectuez des mises à jour JS/CSS/actifs à répétition via Capgo sans publier une nouvelle app native.

Structure recommandée en pratique

1) Baseline de release native

Votre dernier binaire native reste identique pour de nombreuses itérations JS :

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

Vous ne recompilez le binaire native que lorsque vous avez réellement modifié la surface native.

2) Utiliser des canaux dédiés pour les environnements

Publiez des mises à jour avec des canaux :

bun run build
bunx @capgo/cli deploy --channel staging

Testez sur QA, corrigez les problèmes, puis promouvez :

bunx @capgo/cli promote vX.Y.Z --channel production

Si vous préférez un versionnage explicite :

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) Garder TestFlight « toujours en pré-prod »

Dans les workflows iOS, cela signifie que votre build TestFlight peut rester associé aux mises à jour de préproduction :

• Pas de soumissions natives fréquentes pour chaque modification JS.
• La QA valide toujours les code quasi de production via le canal de staging.
• Seuls les utilisateurs en production reçoivent les bundles du canal de production promu.

4) Utiliser le changement de canal uniquement pour des workflows contrôlés

Pour les équipes avancées, exposez des bascules de canal contrôlées pour les utilisateurs QA/admin :

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

Ceci est optionnel. La plupart des équipes gèrent les affectations de canaux depuis le dashboard et ne basculent de canal que pour les utilisateurs internes, pas pour tous les clients.

Checklist opérationnelle

• Un seul app ID (pas d’IDs production/staging dupliqués)
• Un seul pipeline de build natif de référence
• Cartographie des canaux documentée (staging, beta, production, hotfix)
• Chemin de promotion appliqué en CI/CD
• Rebuild natif uniquement sur vrais changements natifs
• Rollback testé régulièrement

Avantage concret

Cette approche élimine les dérive d’environnement, réduit les builds inutiles et accélère les correctifs :

• QA obtient des binaires réalistes (pas de fausse identité d’app de staging),
• votre parcours TestFlight reste stable,
• votre équipe évite la « dette des deux app ID »,
• vous pouvez déployer rapidement de nombreux correctifs JS uniquement via Capgo.

Le résultat final est une gouvernance plus simple : moins d’artefacts, une télémétrie plus propre et moins de surprises dans les opérations de release.

Poursuivez avec Capgo : bonnes pratiques d’environnement — staging avec un seul app ID mobile

Si vous utilisez Bonnes pratiques pour l'environnement Capgo : staging avec un seul ID d'app mobile pour planifier le routage des canaux et le déploiement progressif, connectez-l’avec Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Solution de bêta-test pour le workflow produit de la Solution de bêta-test, et Solution de ciblage de version pour le workflow produit de la Solution de ciblage de version.