Capgo Pratiques d'environnement de qualité : mise en scène avec un seul ID d'application mobile

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

1. Deux ID d'application (production + pré-production)
2. Un ID d'application + un environnement de runtime dynamique de basculement
3. Un ID d'application + des Capgo 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.

Why duplicated app IDs become noisy

En utilisant com.myapp et com.myapp.beta semble simple, mais vous obtenez rapidement des doublons :

• Deux pipelines de mise à jour
• Deux ensembles d'IDs de push, de liens profonds et de mappage des droits
• Deux identités d'analytique et de crash
• Une configuration divergente et un comportement incohérent entre les environnements

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

Pourquoi la configuration de runtime 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 d'actualisation dynamiquement.

Cela fonctionne jusqu'à ce que :

• Les flux prévus sont contournés par la QA car l'état de la configuration est obsolète.
• Quelqu'un utilise le mauvais endpoint en production
• drift des environnements cause des bogues difficiles à reproduire.
• Vous devez déboguer « quelle version de configuration utilise ce binaire ? » sur un appareil utilisateur.

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

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

Capgo rend le contrôle des environnements explicite à travers les canaux :

• Keep one production app ID in App Store / Play.
• Envoyez un seul binaire natif pour le “shell” (jusqu'à ce que des changements natifs nécessitent une véritable reconstruction).
• Routez le comportement par canal, et non par une identité d'application dupliquée.

En pratique, cela signifie :

• production: all users
• stagingQA interne et candidats à la mise en production
• betatesteurs invités
• hotfixchemin d'urgence de mise à jour

Votre application de test interne TestFlight/Play peut rester sur staging Indéfiniment.\ Vous effectuez des mises à jour de JS/CSS/actifs là-bas à plusieurs reprises via Capgo sans publier une nouvelle application native.

Structure recommandée en pratique

1) Base de lancement native

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 réellement modifié la surface native.

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

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

• Aucune soumission native fréquente pour chaque changement de JS.
• QA valide toujours près de la production code via le canal de pré-production.
• Utilisateurs de production ne reçoivent que les bundles de canaux 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
});

Ceci 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 vérification opérationnelle

• Un seul ID d'application (pas de duplicats d'ID de production/staging)
• Un pipeline de construction native de base
• La cartographie du canal est documentée (staging, beta, production, hotfix)
• Voie de promotion appliquée dans CI/CD
• Seulles reconstruire natives sur des changements natives vrais
• Rollback testé régulièrement

Avantages pratiques

Cette approche supprime le dérive de l'environnement, réduit la fréquence de build et accélère les corrections :

• Les QA obtiennent des binaires réalistes (pas d'identité de « staging app » fictive),
• Votre chemin de TestFlight reste stable,
• your team avoids “two app ID debt,”
• Vous pouvez envoyer de nombreuses corrections JS uniquement rapidement via Capgo.

Le résultat final est une gouvernance simplifiée : 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 qualité : Staging avec un seul ID d'application mobile

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