Capgo Pratiche per l'ambiente: Staging con un unico ID dell'applicazione mobile

Le squadre di sviluppo solitamente scelgono uno dei tre approcci per ambienti mobili:

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

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

Perché gli ID applicazioni duplicati diventano rumorosi

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

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

Finisci per gestire due prodotti su console di negozio, team e istruzioni di QA interne.

Perché la configurazione di runtime-switching è spesso confusa

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

Funziona fino a quando:

• La QA inizia a bypassare i flussi previsti perché lo stato della configurazione è datato
• Qualcuno utilizza la porta sbagliata in produzione
• Il drift dell'ambiente causa bug difficili da riprodurre
• Hai bisogno di debuggare "qual è la versione della configurazione che sta utilizzando questo binario?" su un dispositivo del cliente

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

Il modo Capgo : un ID app, molti canali

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

• Conserva un ID di app di produzione unico in App Store / Play.
• Consegna un binario nativo unico per lo “shell” (fino a quando le modifiche native richiedono una vera ricostruzione).
• Configura il comportamento delle rotte per canale, non per l'identità duplicata dell'app.

In pratica, ciò significa:

• production: tutti gli utenti
• staging: QA interna e candidati per la release
• beta: tester invitati
• hotfix: traccia di patch di emergenza

La tua app di testing interno di TestFlight/Play può rimanere su staging per sempre. Puoi aggiornare ripetutamente JS/CSS/asset lì attraverso Capgo senza pubblicare una nuova app nativa.

Struttura raccomandata in pratica

1) Baseline di rilascio nativo

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

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

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

2) Utilizza canali dedicati per gli ambienti

Pubblica aggiornamenti con canali:

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 una 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”

Nelle workflow iOS, ciò significa che il tuo build TestFlight può rimanere associato ad aggiornamenti pre-produzione:

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

4) Utilizza il cambio di canale solo per flussi di lavoro controllati

For team avanzati, esporre commutatori di canale controllati per gli utenti QA/admin:

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

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

Questo è facoltativo. La maggior parte delle squadre utilizza assegnazioni di canale dal dashboard e cambia solo il canale per gli utenti interni, non per tutti i clienti.

Checklist operativa

• Un solo ID dell'applicazione (nessun ID di produzione/di staging duplicato)
• Un solo pipeline di costruzione nativa di base
• La mappatura dei canali documentata (staging, beta, production, hotfix)
• La via di promozione impostata nel CI/CD
• Ri-costruzione nativa solo per modifiche native vere
• La rollback testata regolarmente

Beneficio pratico

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

• La QA riceve binari realistici (nessun falso 'identità dell'applicazione di staging')
• il tuo percorso di TestFlight rimane stabile,
• il tuo team evita il “debito di ID app”,
• puoi inviare molte correzioni JS solo attraverso Capgo velocemente.

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

Continua da Capgo Environment Best Practices: Staging con un solo ID App Mobile

Se stai utilizzando Capgo Environment Best Practices: Staging con un solo ID App Mobile per pianificare la routing dei canali e la distribuzione in fase di staging, connettilo con Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Canali per i dettagli di implementazione in Canali, Soluzione di testing beta per il flusso di lavoro del prodotto in Soluzione di testing beta, e Soluzione di targeting versione per il flusso di lavoro del prodotto in Soluzione di targeting versione.