Capgo Pratiques d'environnement protégées : 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 ID d'application (production + pré-production)
2. Un ID d'application + switching de l'environnement de runtime dynamique
3. Un ID d'application + Capgo les 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 ID d'applications dupliqués deviennent bruyants

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

• Deux pipelines de mise à jour
• Deux ensembles d'ID de push, de liens profonds et de mappage d'entitlement
• Deux identités d'analytique et de crash
• Des configurations divergentes et un 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 interne.

Pourquoi la configuration de runtime-switching est souvent embrouillée

Le modèle « un ID d'app + switch de runtime » est généralement synonyme de votre application qui 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'à :

• Le démarrage de la phase de test qualité fait en sorte que les flux prévus soient contournés 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 la configuration est utilisée par ce binaire ? » sur un appareil utilisateur.

Cette complexité augmente avec chaque mise à jour et c'est là que 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 version native du « shell » (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 :

• production: tous les utilisateurs
• staging: les candidats à la version de test interne et de mise en production
• beta: les testeurs invités
• hotfix: piste de mise à jour d'urgence

Votre application de test interne TestFlight/Play peut rester active "à vie". Vous pouvez mettre à jour JS/CSS/actifs à plusieurs reprises dans __CAPGO_KEEP_0__ sans publier une nouvelle application native. staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

1) Base de lancement native

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

Vous n'avez besoin de reconstruire le binaire natif que lorsque vous avez effectivement modifié la surface native.

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

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

Publiez les mises à jour avec des canaux :

: tous les utilisateurs

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 de pré-production :

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

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 duplicatas d'ID de production/étape de production)
• Une chaîne de 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 des changements natives vrais
• Le retour en arrière est testé régulièrement

Avantage pratique

Cette approche supprime la dérive de l'environnement, réduit la turbulence de construction 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,
• Votre équipe évite le « debt d'ID d'app »
• Vous pouvez faire passer rapidement de nombreuses corrections uniquement en JS à 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 de l'environnement : Étape avec un ID d'application mobile unique

Si vous utilisez Continuez de Capgo Pratiques de l'environnement : Étape avec un ID d'application mobile unique pour planifier la routage des canaux et la mise en production étape par étape, 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 la Solution de ciblage de version.