Checklist di configurazione una volta sola

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

Hai finito onboarding. Ora configura Capgo una volta. Dopo di che, il lavoro quotidiano è solo carica → test → distribuisci.

Regola: i canali sono le linee di rilascio (development, production), non biglietti, funzionalità o nomi degli sviluppatori.

Checklist di configurazione una volta sola

Crea canali: scegli il set più piccolo che si adatti (vedi di seguito).
Imposta canale di caricamento predefinito in impostazioni dell'app:
- Solo app → production
- Team → development
Canale di produzione: pubblico acceso, dispositivo auto-impostazione spento, blocca aggiornamenti sotto native acceso, guardia auto-aggiornamento acceso major.
Canale di test (development / staging): pubblico spento, dispositivo auto-impostazione acceso per QA.
Carica da CI con --delta (il calcolo del checksum e le dipendenze native sono automatici):
Fermata 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
```
La --bundle valore deve essere valido gestione delle versioni semanticheVerifica che sia corretta nella testatore di SemVer prima di caricarlo.
Deploya in produzione solo dopo aver effettuato i test, dal o __CAPGO_KEEP_0__. or CLI.
invita una volta, meno permessi, 2FA per l'organizzazione, una sola chiave __CAPGO_KEEP_0__ in CI. for the org, one API key in CI.

Crittografia dei dati, min_update_version, metadati e anteprima disattiva se hai una ragione chiara.

Scegli il tuo piano

Semplice: 1 app, 1 canale: production

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

Versioni native: aggiungi canali solo quando necessario, ad es. production-9.0 + test-9.0Conserva gli utenti del negozio sul canale principale di produzione.

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

Train di rilascio (facoltativo): staging → rc → productionConsiglio

Sottosezione intitolata “Nome pacchetto vs commento”

I nomi dei bundle sono obbligatori per seguire la versione semantica. Capgo uses semver for compatibility checks, channel auto-update rules, and rollbacks. Validate every name in the tester SemVer prima di caricarlo.

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

Usa semver pre-release etichette (la parte dopo -quando rilasciate molti build sotto lo stesso MAJOR.MINOR.PATCH. Ad esempio, conserva 1.8.0 e aggiungi la data o il contatore di build nella pre-release: 1.8.0-20260629.1, 1.8.0-beta.2. Non inventare formati personalizzati come fix-login-bug o 2.5.2026062306context:HTML testo frammento da una stringa UI Capgo più lunga (chiave genitrice `alternatives_cta_questions`). Pagina/area: pagina di confronto delle alternative di aggiornamento in tempo reale di Capacitor. Ruolo: lungo paragrafo di marketing o legale. Visto in: pagina alternatives.astro. Preservare esattamente i termini del prodotto e della marca Capgo e i termini dei developer.

Usa note di rilascio in --comment, non nel nome del pacchetto.

Vedi anche version targeting e bundle versioning.

Carica delta

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

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

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

Questo è il consigliato predefinito per la maggior parte degli app. Capgo memorizza il manifesto e conserva il file zip completo come backup. Buono quando il costo dello storage non è la tua principale preoccupazione.

Salvataggio di storage: `--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 vuoi ridurre __CAPGO_KEEP_0__ lo storage reduce Capgo storageStorage saving:

Scelta: senza il backup zip sul server, ti affidate interamente alla cartella del manifesto. Saltare --delta-only se effettivamente hai bisogno delle risorse di archiviazione.

Non è richiesta alcuna configurazione aggiuntiva del plugin sul dispositivo. L'aggiornatore legge il manifesto e recupera solo i file modificati.

del comportamento.

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

Errori comuni

Errore	Risoluzione
Sperare nell'aggiornamento OTA prima di una nuova versione del negozio	Ricompilare e distribuire l'app nativa dopo aver aggiunto il plugin
Caricare un bundle ma non distribuirlo a un canale	Assegnare il bundle a un canale (ad es. `production`)
Canale per feature, ticket o sviluppatore	Usare solo corsie di rilascio permanenti
Nomine dinamiche dei canali CI	Nomine fisse: `development`, `production`
Troppi canali per un'app semplice	Inizia con 1-2 canali
Dispositivo impostato su produzione da parte del dispositivo	Spento per la produzione, acceso per i canali di test
Saltare `--delta`	Aggiungi `--delta` agli upload; utilizza `--delta-only` solo quando hai bisogno di risparmiare spazio di archiviazione
Nomina di bundle non semver	Segui la versione semantica e valuta in SemVer tester
Modifica lo schema di versioning nel tempo	Tieni semver; utilizza etichette di rilascio prenotate per costruzioni aggiuntive (`1.8.0-20260629.1`)
Metadata / abilitato anteprima senza motivo	Disabilitato per impostazione predefinita

Scopri di più

Canali Predefiniti, precedenza e routing.

Aggiornamenti delta Perché e come utilizzare --delta.

CI/CD Automazione dell'upload e della distribuzione.

Buste Checksum, dipendenze e metadati.

Checklist di configurazione una volta sola