Come mantenere gli aggiornamenti di Capgo sottili e veloci

L'aggiornamento live migliore è quello che i tuoi utenti quasi non notano.

Ciò solitamente significa tre cose:

1. Il download è piccolo.
2. Il rilascio è controllato.
3. La ripresa è istantanea se qualcosa va storto.

Lo stesso consiglio "mantieni OTA sottile" che funziona nel territorio di React Native si applica anche a Capgo. La differenza è che Capgo dà ai team di Capacitor un paio di leve aggiuntive: Aggiornamenti delta, canali, rollback automatici, target di versionee crittografia end-to-end facoltativa Se li utilizzate insieme, ottenete pacchetti più piccoli, installazioni più veloci e molto meno disordine operativo..

Il lean è importante anche quando il MAU rimane lo stesso

Un utile dettaglio specifico di __CAPGO_KEEP_0__: il MAU di __CAPGO_KEEP_1__ è effettivamente il numero di dispositivi attivi mensili che hanno contattato il servizio di aggiornamento negli ultimi 30 giorni.

One useful Capgo-specific detail: Capgo MAU is effectively the number of monthly active devices that contacted the update service in the last 30 days.

Non è principalmente una truffa per ridurre il conteggio MAU. Importa perché migliora le parti che gli utenti e le squadre sentono realmente:

• Scarichi più veloci su cellulare o Wi-Fi debole
• Miglior esperienza con aggiornamenti diretti
• Minore spreco di banda su rilasci falliti o annullati
• Raggio d'azione più piccolo quando si testa o si staga un rilascio

Gli aggiornamenti lean sono davvero sulla velocità, la sicurezza e la disciplina operativa.

1. Imposta per impostazione predefinita gli aggiornamenti Delta

Se fai solo una cosa, fai questo.

Capgo’s Gli aggiornamenti Delta inviare solo i file che sono stati modificati tra le versioni invece di scaricare nuovamente il bundle web completo. È il più grande singolo vantaggio per le prestazioni OTA routine.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

When il tuo pass di QA è completato:

bunx @capgo/cli@latest bundle upload --channel production --delta

Se desideri che CI rimanga rigoroso, utilizza --delta-only così che nessuno cade accidentalmente su upload di bundle completo:

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Sii cauto con --delta-only utilizzalo solo quando la tua flotta di produzione supporta gli aggiornamenti Delta. Sui plugin di versioni miste, i dispositivi più vecchi che non supportano la consegna basata sul manifesto degli aggiornamenti Delta non saranno in grado di scaricare quell'aggiornamento.

Questo conta ancora di più se utilizzi directUpdate, perché il tempo tra “aggiornamento trovato” e “app riavviata” diventa visibile all'utente.

2. Tratta gli asset come asset, non come bagaglio JavaScript

Gli asset grandi sono dove i pacchetti OTA silenziosamente si gonfiano.

Alcune regole pratiche:

• Non incolli grandi immagini o media all'interno di JavaScript quando un file di asset normale farà al caso tuo.
• Tieni il contenuto che cambia frequentemente sul tuo CDN o API se non deve vivere dentro il pacchetto di bundle dell'app spedita.
• Attieniti alle immagini di marketing, ai video di onboarding e agli asset di campagna unici che vengono sostituiti ogni rilascio.
• Conserva gli asset stabili. Con gli aggiornamenti Delta, i file invariati vengono riutilizzati al posto di essere scaricati nuovamente.

Questo è uno dei modi più facili per mantenere Capgo veloce mentre il tuo app cresce. Il peggior pattern è una piccola correzione UI che costringe gli utenti a scaricare un mucchio di media non correlate.

3. Conserva i rilasci nativi per le modifiche native reali

Capgo aggiorna il layer web: HTML, CSS, JavaScript e asset caricati in esecuzione.

Non è il canale giusto per:

• nuovi plugin nativi,
• modifiche di autorizzazione,
• capacitor.config.ts modifiche,
• qualsiasi cosa che modifichi lo stato del progetto nativo iOS o Android.

Quella riga conta anche per le prestazioni. Se continui a spingere cambiamenti strutturali importanti nella strada dell'aggiornamento OTA, la tua strategia di aggiornamento diventa più pesante e rischiosa nel tempo.

Usa due linee di rilascio a scopo:

Pista nativa

Per modifiche dei plugin, modifiche delle autorizzazioni e configurazione nativa:

bun run build
bunx cap sync

Poi rilascia una versione di store normale.

Capgo pista

Per iterazione sicura del layer web:

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

Rinfresca inoltre regolarmente la tua baseline nativa se hai aggiunto recentemente molti asset di lunga durata. Un nuovo build di store incorpora quella nuova baseline, che mantiene le future Capgo differenze più piccole.

4. Utilizza i canali per mantenere la dimensione del rilascio piccola

Un aggiornamento “snello” non riguarda solo i megabyte. Si tratta anche del numero di dispositivi che ricevono l'aggiornamento prima di sapere che è buono.

Capgo’s Il sistema dei canali è il modo più pulito per controllare ciò:

• staging per QA
• beta For gli utenti invitati
• production Per tutti
• hotfix Per il ripristino di emergenza

Un flusso semplice assomiglia a questo:

1. Incarica su staging.
2. Verifica su dispositivi reali.
3. Rilascia gradualmente, sia attraverso canali controllati o percentuale di distribuzione.
4. Ritorna immediatamente se la salute diminuisce.

Se il tuo'applicazione ha più basi native multiple in circolazione, pair i canali con target versione. Ciò tiene lontani i pacchetti incompatibili o inutilmente pesanti dai binari più vecchi.

Per le squadre che desiderano anche dei loop di revisione più stretti, Capgo funziona bene anche Previsioni di PR. Ciò consente al prodotto, alla QA e ai stakeholder di testare le modifiche esclusivamente in JavaScript senza dover attendere nuove versioni di TestFlight o Play.

5. Se abiliti gli aggiornamenti diretti, ottimizza il percorso di avvio

Più velocemente desideri che un aggiornamento venga applicato, più disciplinato deve essere il percorso di avvio.

Capgo’s il comportamento di aggiornamento i documenti raccomandano esplicitamente di associare directUpdate con gli aggiornamenti Delta. Ciò è la configurazione predefinita corretta.

Il secondo ostacolo è notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

Se l'app non segnala di essere pronta entro la finestra di default di 10 secondi, o entro quanto notifyAppReady() hai impostato nella tua configurazione di __CAPGO_KEEP_0__ , __CAPGO_KEEP_1__ può segnalare quella bundle come non valida e ripristinare la versione precedente buona. Quel comportamento di rollback è quello che desideri in produzione, ma significa anche che dovresti mantenere pulito l'avvio: appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

• Chiamare notifyAppReady() in un luogo giusto
• Evita il lavoro di avvio lento nella critical path
• Salva e ripristina lo stato dell'applicazione con cura se si ricarica immediatamente
• Testa i casi di scenario di rete cattiva e dispositivi di bassa gamma prima di una distribuzione ampia

Se non l'hai rivisto di recente, il __CAPGO_KEEP_0__ è ancora utile da leggere.

6. Utilizza i canali di aggiornamento interni al posto di rebuild native non necessari

Molti team mobili perdono tempo costruendo binari per modifiche che sono chiaramente web-only.

Se la modifica è:

• copia,
• Polish dell'interfaccia utente,
• flusso di onboarding,
• logica della schermata di prezzo,
• cablaggio degli analytics,
• bandiere di feature,
• rendere una risposta API o una richiesta di prompt,

poi un aggiornamento Capgo è spesso l'artefatto di revisione più veloce.

Ciò significa meno rebuild native, meno churn di TestFlight e un ciclo di feedback più stretto per l'equipaggio. È uno dei benefici più sottovalutati di Capgo: puoi spostare più lavoro di revisione e QA nella strada OTA senza infrangere il confine native/web.

La nostra guida su staging con un ID di app mobile unico copre un modo pratico per mantenere questo pulito nel tempo.

7. Mantieni lean separato dai segreti

Piccoli pacchetti e pacchetti sicuri risolvono problemi diversi.

I canali controllano l'accesso. Non rendono un pacchetto confidenziale da soli.

Se hai bisogno di garanzie di consegna più forti:

• abilita Crittografia di aggiornamento in tempo reale,
• utilizza archiviazione personalizzata o consegna auto-hosted,
• tieni le chiavi private solo in CI o workflow di operatori protetti.

Ciò non significa che la dimensione dell'aggiornamento sia irrilevante. Significa solo che dovresti ottimizzare per entrambe le dimensioni:

• sii snello per la velocità,
• crittografato per il controllo della consegna,
• i canali per il controllo del rilascio,
• rollback per la ripristino.

Un flusso di lavoro pratico “lean Capgo”

Se desideri un modello operativo di default semplice, utilizza questo:

1. Mantieni le linee di rilascio native e OTA separate.
2. Carica le modifiche JS con --delta di default.
3. Utilizza staging e i canali prima di beta Guarda production.
4. aggiorna le statistiche e i log dopo il rollout, non solo prima di esso. channels before "Watch".
5. Trasforma i PR in anteprime installabili quando un build nativo non è necessario.
6. Conserva grandi, frequentemente modificati media fuori dal bundle quando possibile.
7. Aggiorna il baseline nativo dopo un significativo aumento degli asset o delle modifiche native.
8. Tieni notifyAppReady() e il comportamento di rollback come parte dell'ingegneria di rilascio, non come trivia di configurazione.

Quella combinazione rimane veloce molto più a lungo dell'approccio comune "carica solo le modifiche".

Pensiero finale

Per Capgo team, "sottile e veloce" non è solo un problema di dimensione del bundle.

È un problema di design di rilascio.

Utilizza gli aggiornamenti Delta per la dimensione del payload, i canali per la dimensione di distribuzione e i rollback per la dimensione degli errori. Una volta che pensi all'OTA in questo modo, le tue aggiornamenti rimangono veloci anche quando l'app, il team e la base utenti crescono.