Checklist di configurazione una volta

Copia un prompt di configurazione con i passaggi di installazione e la guida markdown completa per questo plugin.

Hai finito OnboardingConfigura ora Capgo Una volta. Dopo di che, il lavoro quotidiano è solo carica → testa → distribuisci.

Regola: i canali sono corsie di rilascio (development, production), non biglietti, caratteristiche o nomi degli sviluppatori.

Checklist di configurazione una volta sola

Creare canali: scegli il set più piccolo che si adatta (vedi di seguito).
Imposta il canale di upload predefinito in impostazioni dell'app:
- Applicazione → production
- Team → development
Canale di produzione: pubblico acceso, dispositivo auto-disabilitato, blocca aggiornamenti sotto native acceso, guardia auto-aggiornamento acceso major.
Canale di test (development / staging): pubblico spento, dispositivo autoaccendimento per QA.
Carica da CI context --delta (calcolo del checksum e dipendenze native sono automatici):
Finestra del terminale
```
npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta
```
Il --bundle valore deve essere valido semantico. Verificalo nelValida in esso prima di caricarlo. Distribuisci in produzione
protectedTokens solo dopo aver testato, dal dashboard CLI.
Team e sicurezza: invita una volta, meno permessi, 2FA per l'organizzazione, una sola chiave API in CI.

Lascia l'encryption, min_update_version, i metadati e la anteprima off a meno che tu abbia una chiara ragione.

Scegli il tuo dimensione

Semplice: 1 app, 1 canale: production

Team: development + productionCarica sul dev, distribuisci sul prod.

Versioni nativeAggiungi canali solo quando necessario, ad esempio production-9.0 + test-9.0: aggiungi canali solo quando necessario, ad esempio

Molti app: stesso modello semplice per app (di solito uno) production Non creare canali aggiuntivi solo perché l'organizzazione è grande.

Treno di rilascio (facoltativo): staging → rc → production. Stesso template in ogni app che ne ha bisogno.

Nome pacchetto vs commento

I nomi dei pacchetti sono richiesti per seguire la versione semantica.Capgo utilizza semver per controlli di compatibilità, regole di aggiornamento automatico del canale e rollback. Verifica ogni nome nella Tester SemVer prima dell'upload.

Nome = semver da CI, ad esempio 1.8.0, 1.8.0-beta.1, o 1.8.0-20260629.42
Commento = testo libero per gli utenti → commit abc1234 run 28059070270

Usa semver pre-release ) quando rilasci molti build sotto lo stesso -) quando invii molti build sotto lo stesso MAJOR.MINOR.PATCHPer esempio, conserva 1.8.0 e aggiungi la data o il numero di build nella versione di anteprima: 1.8.0-20260629.1, 1.8.0-beta.2. Non inventare formati personalizzati come fix-login-bug o 2.5.2026062306Essi non sono validi semver e le pubblicazioni falliranno o comporteranno comportamenti imprevedibili.

Inserisci note di rilascio --commenttargetamento della versione

e gestione delle versioni del pacchetto and Caricamento del delta.

Nota delle versioni

--delta carichi file delta così i dispositivi scaricano solo i file modificati invece che l'intero bundle ogni volta. Il checksum viene sempre calcolato automaticamente. Non passi un flag di checksum.

Predefinito: `--delta` (file delta + backup zip)

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --delta

Questo è il predefinito consigliato per la maggior parte degli app. Capgo conserva i file delta e context: Pagina/Area: Sito web di marketing di Capgo. Ruolo: Etichetta di navigazione breve o elemento di navigazione. Visto in: pagina trust.astro. Chiave di messaggio `e` (E).

Salvataggio di spazio di archiviazione: `--delta-only`

npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \
  --delta-only

Usa --delta-only quando desideri ridurre lo __CAPGO_KEEP_0__ spazio di archiviazione ridurre lo spazio di archiviazione CapgoSolo i file delta vengono archiviati, non il zip completo. Scegliere questo per le grandi app o per un alto volume di caricamento in cui lo storage si accumula.

Trade-off: without the zip backup on the server, you rely fully on delta files, and devices on an old plugin version without Delta support cannot update. Skip --delta-only unless you actually need the storage savings.

Nessuna configurazione aggiuntiva del plugin è richiesta sul dispositivo. L'aggiornatore legge l'elenco dei file delta e recupera solo i file modificati.

Flusso di lavoro quotidiano

Upload to development (--delta)
  → test
  → deploy to production
  → don't touch channel settings again

Errori comuni

Errore	Soluzione
Expecting OTA before a new store release	Riavvia e distribuisci l'app nativa dopo aver aggiunto il plugin
Carica un bundle ma non distribuisci su un canale	Assegna il bundle a un canale (ad es. `production`)
Canale per feature, ticket o sviluppatore	Usa solo corsie di rilascio permanenti
Nomine di canale dinamiche CI	Nomine fisse: `development`, `production`
Troppi canali per un'app semplice	Inizia con 1-2 canali
Dispositivo impostato su produzione	Spento per la produzione, acceso per i canali di test
Saltare `--delta`	Aggiungi `--delta` utilizza le upload `--delta-only` only when you need to save storage
Nomi di bundle non semver	Follow Versioning Semantico e e verificare SemVer tester
Cambiamento dello schema di versioning nel tempo	Metadati / anteprima abilitata senza motivo`1.8.0-20260629.1`)
Lascia disabilitato per impostazione predefinita	Aggiungi a caricamenti; utilizza

Scopri di più

Canali Preferenze, precedenza e routing.

Aggiornamenti delta Perché e come utilizzare --delta.

CI/CD Automatizza l'upload e la distribuzione.

Pacchetti Checksum, dipendenze e metadati.

Checklist di configurazione una volta