Capgo Pratiche per l'ambiente: Staging con un unico ID di App Mobile

Di solito, le squadre scelgono uno dei tre approcci per gli ambienti mobili:

1. Due ID di app (produzione + pre-produzione)
2. Un ID di app + switching dinamico dell'ambiente runtime
3. Un ID di app + canali Capgo

I primi due possono funzionare, ma creano una frizione a lungo termine. In reali team, il modello del canale Capgo è solitamente il più pulito.

Perché gli ID delle app duplicati diventano rumorosi

Usando com.myapp e com.myapp.beta sembra semplice, ma si ottiene rapidamente la duplicazione:

• Due pipeline di rilascio
• Due set di ID di push, collegamenti profondi e mapping delle autorizzazioni
• Due identità di analytics e crash
• Configurazione divergente e comportamento inconsistente tra ambienti

Finisci per gestire due prodotti attraverso console delle store, team e istruzioni QA interne.

Perché la configurazione di runtime-switching è spesso disordinata

Il modello "un ID di app + switch di runtime" solitamente significa che il tuo app legge le variabili di ambiente o le bandiere al avvio e reindirizza le API, le chiavi e il comportamento dell'aggiornamento dinamicamente.

Funziona fino a quando:

• I test di QA iniziano a bypassare i flussi previsti perché lo stato di configurazione è datato,
• qualcuno utilizza l'endpoint sbagliato in produzione,
• la deriva dell'ambiente causa bug difficili da riprodurre,
• hai bisogno di debuggare “qual è la versione di configurazione utilizzata da questo binario?” su un dispositivo del cliente.

Questa complessità cresce con ogni rilascio e è dove le squadre perdono velocità.

Il modo Capgo : un ID applicazione, molti canali

Il Capgo rende il controllo dell'ambiente esplicito attraverso i canali:

• Mantieni un unico ID applicazione in App Store / Play.
• Invia un binario nativo unico per la “shell” (fino a quando le modifiche native richiedono una vera ricostruzione).
• Routa il comportamento per canale, non per l'identità duplicata dell'applicazione.

In pratica, ciò significa:

• production: tutti gli utenti
• staging: candidati alla QA interna e alle versioni di rilascio
• beta: tester invitati
• hotfix: track di patch di emergenza

Il tuo app di testing interno TestFlight/Play può rimanere sempre attiva. Puoi aggiornare ripetutamente JS/CSS/asset lì senza pubblicare una nuova app nativa. __CAPGO_KEEP_0__ staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

1) Baseline di rilascio nativo

Il tuo ultimo binario nativo rimane lo stesso per molte iterazioni di JS:

Riavrai il binario nativo solo quando effettivamente hai modificato la superficie nativa.

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

2) Utilizza canali dedicati per gli ambienti

Pubblica gli aggiornamenti con canali:

2) Utilizza canali dedicati per gli ambienti

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

Testa su QA, risolvi gli issue, poi promuovi:

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

Se preferisci la versioning 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”

In flussi iOS, ciò significa che il tuo build TestFlight può rimanere associato agli aggiornamenti pre-produzione:

• Nessuna sottoscrizione nativa frequente per ogni cambiamento JS.
• La QA sempre valuta vicino alla produzione code tramite il canale di staging.
• Gli utenti di produzione ricevono solo i bundle del canale di produzione promosso.

4) Utilizza solo le scelte di canale per flussi di lavoro controllati

Per team avanzati, esponi le scelte di canale controllate per gli utenti QA/amministratore:

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

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

Ciò è facoltativo. La maggior parte dei team utilizza le assegnazioni di canale dal pannello di controllo e cambia solo il canale per gli utenti interni, non per tutti i clienti.

Checklist operativa

• Solo un ID dell'app (nessun ID di produzione/duplicato ID di staging)
• Una pipeline di costruzione nativa di base
• Mappatura del canale documentata (staging, beta, production, hotfix)
• La via di promozione è impostata in CI/CD
• Ri-costruzione nativa solo per modifiche native vere
• Il rollback viene testato regolarmente

Beneficio pratico

Questa approccio elimina la deriva dell'ambiente, riduce la churn di costruzione e accelera le correzioni:

• La QA riceve binari realistici (nessun falso "applicazione di staging" di identità)
• Il tuo percorso di TestFlight rimane stabile
• Il tuo team evita il "debito di ID applicazione due",
• Puoi inviare molte correzioni solo JS attraverso Capgo velocemente.

Il risultato finale è una governance più semplice: meno artefatti, telemetria più pulita e meno sorprese nelle operazioni di rilascio.