Pratiques d'environnement Capgo : Étape de développement avec un ID d'application mobile unique

Les équipes choisissent généralement l'une des trois approches pour les environnements mobiles :

Deux ID d'application (production + pré-production)
Un ID d'application + switching de l'environnement de runtime dynamique
Un ID d'application + Capgo les canaux

Les deux premières peuvent fonctionner, mais elles créent une friction à long terme. Dans les équipes réelles, le modèle de canal Capgo est généralement le plus propre.

Pourquoi les ID d'application dupliqués deviennent bruyants

Utiliser com.myapp et com.myapp.beta semble simple, mais vous vous retrouvez rapidement avec des doublons :

Deux pipelines de publication
Deux ensembles d'IDs de mise à jour, de liens profonds et de mappage d'entitlement
Deux identités d'analytique et de crash
Des configurations divergentes et des comportements incohérents entre environnements

Vous finissez par gérer deux produits sur les consoles de magasin, les équipes et les instructions de test interne.

Pourquoi la configuration de basculement en temps d'exécution est souvent chaotique

Le modèle « un ID d'application + basculement de runtime » signifie généralement que votre application lit les variables d'environnement ou les drapeaux au démarrage et re-routifie les APIs, les clés et le comportement de mise à jour dynamiquement.

Cela fonctionne jusqu'à ce que :

Les équipes QA commencent à contourner les flux intentionnels car l'état de la configuration est obsolète,
quelqu'un utilise le mauvais endpoint en production,
le dérive de l'environnement entraîne des bogues difficiles à reproduire,
vous devez déboguer « quelle version de config est-ce que ce binaire utilise ? » sur un appareil utilisateur.

Cette complexité augmente avec chaque mise à jour et c'est là où les équipes perdent de la vitesse.

The Capgo way: one app ID, many channels

Capgo makes environment control explicit through channels:

Conservez une seule ID d'application de production dans l'App Store / Play.
Envoyez une seule binary native pour la « coquille » (jusqu'à ce que des changements natives nécessitent une véritable reconstruction).
Routez le comportement par canal, et non par une identité d'application dupliquée.

En pratique, cela signifie :

productiontous les utilisateurs
stagingQA interne et candidats à la mise en production
betades testeurs invités
hotfixla piste de mise à jour d'urgence

Votre application de test interne TestFlight/Play peut rester active staging à tout jamais. Vous pouvez mettre à jour JS/CSS/actifs à plusieurs reprises via Capgo sans publier une nouvelle application native.

Structure recommandée en pratique

1) Base de mise à jour native

Votre dernier fichier binaire natif reste le même pour de nombreuses itérations de JS :

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

Vous n'avez besoin de reconstruire le fichier binaire natif que lorsque vous avez effectué des modifications sur la surface native.

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

Publiez les 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 une version explicite :

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

3) Gardez TestFlight "toujours pré-prod"

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

Aucun soumission native fréquent pour chaque changement JS.
La QA valide toujours le code proche de la production via le canal de mise en scène.
Seuls les utilisateurs de production reçoivent les paquets de canal de production promus.

4) Utilisez uniquement les commutateurs de canal pour des workflows contrôlés

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

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

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

Cela est facultatif. La plupart des équipes utilisent les affectations de canal depuis le tableau de bord et ne changent que le canal pour les utilisateurs internes, pas tous les clients.

Liste de contrôle opérationnelle

Un seul ID d'application (pas de duplicats d'ID de production/stage)
Un pipeline de build native de base
La cartographie du canal est documentéestaging, beta, production, hotfix)
chemin de promotion mis en œuvre dans CI/CD
Reconstruction native uniquement sur les changements natifs vrais
Annulation testée régulièrement

Avantage pratique

Cette approche supprime la dérive de l'environnement, réduit la rotation de construction et accélère les correctifs :

Les QA obtiennent des binaires réalistes (pas d'identité de « staging app » fictive),
votre chemin de TestFlight reste stable,
votre équipe évite le « debt d'ID d'application »
vous pouvez faire passer rapidement de nombreux correctifs JS uniquement à travers Capgo.

Le résultat final est une gouvernance plus simple : moins d'artefacts, des données de télémétrie plus propres et moins de surprises dans les opérations de mise en production.

Continuez de Capgo Pratiques d'environnement de meilleure qualité : Staging avec un seul ID d'application mobile

Si vous utilisez Capgo Pratiques de l'environnement : Étapes avec un seul ID d'application mobile pour planifier la mise en route des canaux et la mise en production étalée, connectez-le à Canaux pour les détails d'implémentation dans Canaux, Canaux pour les détails d'implémentation dans Canaux, Canaux pour les détails d'implémentation dans Canaux, Solution de test bêta pour le flux de travail du produit dans Solution de test bêta, et Solution de ciblage de version pour le flux de travail du produit dans Solution de ciblage de version.

Capgo Pratiques d'environnement de protection : Étapes avec un ID d'application mobile unique