Capgo Environment Best Practices: Staging con un unico Mobile App ID

I team di solito scelgono uno dei tre approcci per gli ambienti mobile:

Due app ID (produzione + pre-produzione)
Un unico app ID + switching dinamico dell'ambiente a runtime
Un unico app ID + canali Capgo

I primi due possono funzionare, ma creano attriti a lungo termine. Nei team reali, il modello a canali Capgo è solitamente il più pulito.

Perché gli app ID duplicati creano confusione

Usare com.myapp e com.myapp.beta sembra semplice, ma si finisce subito per avere duplicazioni:

Due pipeline di rilascio
Due set di push ID, deep link e mapping delle entitlement
Due identità per analytics e crash report
Configurazioni divergenti e comportamenti inconsistenti tra gli ambienti

Ti ritroverai a gestire due prodotti diversi tra console degli store, team e istruzioni per il QA interno.

Perché il runtime-switching della config è spesso disordinato

Il pattern “un solo app ID + runtime switch” di solito implica che l'app legga variabili d'ambiente o flag all'avvio, reindirizzando dinamicamente API, chiavi e il comportamento degli update.

Tutto questo funziona finché:

il QA inizia a saltare i flussi previsti perché la config è obsoleta,
qualcuno usa l'endpoint sbagliato in produzione,
l'environment drift causa bug difficili da riprodurre,
devi debuggare "quale versione della config usa questo binario?" su un device.

La complessità aumenta a ogni release, rallentando il team.

Il metodo Capgo: un app ID, molti canali

Capgo rende esplicito il controllo degli environment tramite i canali:

Mantieni un unico app ID di produzione su App Store / Play.
Distribuisci un unico binario nativo per la "shell" (fino a quando i cambiamenti nativi richiedono un rebuild).
Gestisci il comportamento tramite canale, non duplicando l'app identity.

In pratica, questo significa:

production: tutti gli utenti
staging: QA interna e release candidate
beta: tester invitati
hotfix: canale per patch di emergenza

La tua app di test interno su TestFlight/Play può rimanere attiva staging per sempre. Puoi aggiornare lì JS/CSS/asset più volte tramite Capgo senza pubblicare una nuova app nativa.

Struttura consigliata in pratica

1) Baseline della release nativa

L'ultimo binario nativo rimane invariato per molte iterazioni JS:

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

Ricostruisci il binario nativo solo quando modifichi effettivamente la parte nativa.

2) Usa canali dedicati per gli ambienti

Pubblica gli update con i canali:

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

Testa in QA, correggi i problemi, poi promuovi:

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

Se preferisci un versionamento esplicito:

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

3) Mantieni TestFlight "sempre pre-prod"

Nei workflow iOS, questo significa che la build su TestFlight può restare associata agli update di pre-produzione:

Nessun invio nativo frequente per ogni modifica JS.
La QA valida sempre code quasi di produzione tramite il canale staging.
Gli utenti in produzione ricevono solo i bundle promossi del canale production.

4) Usa lo switch dei canali solo per workflow controllati

Per i team avanzati, esponi switch di canale controllati per utenti QA/admin:

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

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

È opzionale. La maggior parte dei team usa le assegnazioni dei canali dal dashboard e cambia canale solo per gli utenti interni, non per tutti i clienti.

Checklist operativa

Un solo app ID (niente ID duplicati tra production e staging)
Una pipeline Native Build di base
Mappatura dei canali documentata (staging, beta, production, hotfix)
Percorso di promozione gestito in CI/CD
Rebuild nativo solo per modifiche native reali
Rollback testati regolarmente

Vantaggio pratico

Questo approccio elimina il drift tra gli ambienti, riduce i build e velocizza i fix:

Il team QA riceve binari realistici (senza un'identità "app di staging" fittizia),
il tuo percorso TestFlight rimane stabile,
il tuo team evita il "debito di due app ID",
puoi distribuire rapidamente molti fix JS-only tramite Capgo.

Il risultato è una governance più semplice: meno artifact, telemetria più pulita e meno sorprese nelle release.

Continua da Capgo Best practice per gli ambienti: Staging con un unico Mobile App ID

Se stai usando Capgo Environment Best Practices: Staging con un unico Mobile App ID per pianificare il routing dei canali e il rollout graduale, connettilo a Canali per i dettagli di implementazione nei Channels, Canali per i dettagli di implementazione nei Channels, Canali per i dettagli di implementazione nei Channels, Soluzione Beta Testing per il workflow di prodotto nella Soluzione Beta Testing, e Soluzione Version Targeting per il workflow di prodotto nella Soluzione Version Targeting.