Capgo Pratiques de l'environnement : Staging avec un seul ID d'application mobile

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

1. Deux identifiants d'application (production + pré-production)
2. Un identifiant d'application + un environnement de temps de exécution dynamique
3. Un identifiant d'application + Capgo canaux

Les deux premiers peuvent fonctionner, mais ils 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 identifiants d'application dupliqués deviennent bruyants

Utiliser com.myapp et com.myapp.beta semble simple, mais vous obtenez rapidement des duplicatas :

• Deux pipelines de publication
• Deux ensembles d'IDs de push, de liens profonds et de mappage d'entitlement
• Deux identités d'analytique et de crash
• La configuration divergente et le comportement incohérent entre les environnements

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

Pourquoi la configuration de basculement en temps réel 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-routent les API, les clés et le comportement de mise à jour dynamiquement.

Cela fonctionne jusqu'à ce que :

• Les équipes de test commencent à contourner les flux prévus 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 configuration utilise ce binaire ? » sur un appareil utilisateur.

Cette complexité augmente avec chaque version et c'est là que les équipes perdent de la vitesse.

La manière Capgo : un ID d'application, plusieurs canaux

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

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

En pratique, cela signifie :

• production: tous les utilisateurs
• staging: les candidats à la QA interne et les candidats à la mise en production
• beta: les testeurs invités
• hotfix: le suivi des correctifs d'urgence

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

Structure recommandée en pratique

1) Base de lancement native de base

Votre dernier 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 binaire natif que lorsque vous avez effectivement changé la surface de l'interface native.

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

Publiez les mises à jour avec les 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 versionnement 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é aux mises à jour pré-production :

• Aucun soumission fréquent de binaire natif pour chaque changement de JS.
• QA always validates near-production code via the staging channel.
• Les utilisateurs de production ne reçoivent que les bundles de canal de production promus.

4) Utilisez uniquement le basculement 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
});

Ceci est facultatif. La plupart des équipes utilisent les affectations de canal à partir du tableau de bord et ne commutent que le canal pour les utilisateurs internes, pas tous les clients.

Liste de vérification opérationnelle

• Un seul ID d'application (pas de duplicata des IDs de production/étape)
• Un pipeline de construction native de base
• La cartographie du canal est documentée (staging, beta, production, hotfix)
• La voie de promotion est appliquée dans CI/CD
• Reconstruction native uniquement sur les vraies modifications natives
• La mise en œuvre de reversion est testée régulièrement

Avantage pratique

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

• Les QA obtiennent des binaires réalistes (pas d'identité de « staging app » fictive),
• Votre chemin TestFlight reste stable,
• Votre équipe évite le « endettement d'ID d'application »,
• Vous pouvez envoyer de nombreuses corrections JS uniquement à travers Capgo rapidement.

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 publication.

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

Si vous utilisez Capgo Pratiques d'environnement de meilleure qualité : Étapes avec un seul ID d'application mobile pour planifier la routage de canal et la mise en production étalée, connectez-le avec Channels pour les détails d'implémentation dans Channels, Channels pour les détails d'implémentation dans Channels, 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.