Come mantenere aggiornamenti Capgo snelli e veloci

L'aggiornamento live migliore è quello che i tuoi utenti notano a malapena.

Ciò significa in genere tre cose:

1. Il download è piccolo.
2. La distribuzione è controllata.
3. La ripresa è istantanea se qualcosa va storto.

Lo stesso consiglio di mantenere gli aggiornamenti OTA leggeri 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 extra: Aggiornamenti delta, canali, rollindietro automatico, target versione, e facoltativo crittografia end-to-end.

Se utilizzi questi insieme, ottieni pacchetti più piccoli, installazioni più veloci e molto meno disordine operativo.

Lean conta anche quando il MAU rimane lo stesso

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

Ridurre un bundle non è principalmente un trucco per ridurre il conteggio del MAU. Importa perché migliora le parti che gli utenti e le squadre sentono effettivamente:

• Scarichi più veloci su cellulare o Wi-Fi debole
• Miglior esperienza con aggiornamenti diretti
• Minore banda sprecata su rilasci falliti o annullati
• Un raggio d'azione più piccolo quando si testa o si stagiona una versione

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 inviano solo i file che sono stati modificati tra le versioni invece di scaricare nuovamente l'intero pacchetto web. È il più grande vantaggio singolo per le prestazioni OTA routine.

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

Quando la tua passata di QA è completata:

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

Se desideri che CI rimanga rigoroso, utilizza --delta-only in modo che nessuno cada accidentalmente in upload di pacchetti completi:

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

Sii rigoroso --delta-only se il tuo parco di produzione supporta gli aggiornamenti Delta. Su versioni di plugin miste, i dispositivi più vecchi che non supportano la consegna basata sul manifesto degli aggiornamenti Delta non saranno in grado di scaricare l'aggiornamento.

This matters even more if you use directUpdateperché 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 le raccolte OTA diventano silenziosamente gonfie.

Alcune regole pratiche:

• Non incolonnare grandi immagini o media all'interno di JavaScript quando un file di asset normale farà al caso.
• Tieni il contenuto che cambia frequentemente sul tuo CDN o API se non deve vivere all'interno della bundle dell'app spedita.
• Sii cauto con le immagini di marketing, i video di onboarding e gli asset di campagna uno-a-uno che vengono sostituiti ogni rilascio.
• Lascia gli asset stabili 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 l'app cresce. Il peggior pattern è una piccola correzione UI che costringe gli utenti a scaricare un mucchio di media non correlati.

3. Tieni i rilasci nativi per le vere modifiche native

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

Non è il canale giusto per:

• nuove plugin native
• cambiamenti di autorizzazione
• capacitor.config.ts cambiamenti
• qualsiasi cosa che modifica 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 corsie di rilascio di proposito:

CORSIA NATIVA

Per cambiamenti di plugin, cambiamenti di autorizzazione e configurazione nativa:

bun run build
bunx cap sync

Poi rilascia una versione normale del negozio.

Capgo CORSIA

Per iterazione sicura del layer web:

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

Rinfresca regolarmente la tua baseline nativa se hai aggiunto recentemente molti asset di lunga durata. Una nuova costruzione del magazzino incorpora quella nuova baseline, che mantiene future Capgo differenze più piccole.

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

Una "aggiornamento sottile" non riguarda solo i megabyte. Si tratta anche di quanti dispositivi ricevono l'aggiornamento prima di sapere che è buono.

Capgo's Il sistema dei canali è il modo più pulito per controllare questo:

• staging per le prove di qualità
• beta per i tester invitati
• production per tutti
• hotfix per la ripresa di emergenza

Un semplice flusso assomiglia a questo:

1. Carica su staging.
2. Verifica sulle reali dispositivi.
3. Lanciare gradualmente, sia attraverso canali controllati o percentuale di distribuzione.
4. Ritornare immediatamente se la salute diminuisce.

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

Per i team che desiderano anche dei loop di revisione più stretti, Capgo funziona bene anche per anteprime dei PR . Ciò consente ai prodotti, QA e stakeholder di testare le modifiche solo JS senza dover attendere nuovi TestFlight o Play interni.

5. Se abiliti gli aggiornamenti diretti, ottimizza il caricamento.

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

Capgo’s aggiornare il comportamento i documenti raccomandano esplicitamente di associare directUpdate con gli aggiornamenti Delta. Questo è il default giusto.

Il secondo ostacolo è notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

Se il tuo'app non segnala pronto entro il default di 10 secondi notifyAppReady() o entro ciò che hai impostato nel tuo __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ può segnalare quel pacchetto come invalido e ripristinare la versione precedente buona. Questo comportamento di rollback è ciò che desideri in produzione, ma significa anche che dovresti mantenere il caricamento pulito: 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:

• in il posto giusto notifyAppReady() Evita il lavoro di avvio lento nella via critica
• Salva e ripristina lo stato dell'app con cura se si ricarica immediatamente
• Testa i casi di scenario di rete cattiva e dispositivi di bassa gamma prima di una distribuzione ampia
• Testare i casi di scenario di rete cattiva e dispositivi di bassa gamma prima di una distribuzione ampia

If non hai riletto recentemente, il notifyAppReady guide è degno di essere riletto.

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

Un sacco di team mobili perdono tempo costruendo binari per modifiche che sono chiaramente web-only.

Se la modifica è:

• copia,
• polish UI,
• flusso di onboarding,
• logica della schermata di prezzo,
• cablaggio degli analytics,
• flag di feature,
• o API di risposta di rendering,

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

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

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

7. Mantieni separato il lean dal segreto

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 L'aggiornamento in tempo reale crittografia,
• utilizzare archiviazione personalizzata o consegna auto-hosted,
• tenere le chiavi private solo in CI o workflow di operatori sicurizzati.

Ciò non rende irrilevante la dimensione degli aggiornamenti. Significa solo che dovresti ottimizzare per entrambe le dimensioni:

• essere veloci,
• crittografati per il controllo della consegna,
• canali per il controllo della distribuzione,
• rollback per la ripristino.

Un flusso di lavoro pratico “essere veloci Capgo”

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

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

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

Ultimo pensiero

Per le Capgo squadre, 'sottile e veloce' non è solo un problema di dimensione del pacchetto.

È un problema di design di rilascio.

Utilizza gli aggiornamenti Delta per la dimensione del carico, i canali per la dimensione del rilascio e le annullazioni per la dimensione degli errori. Una volta che pensi all'OTA in questo modo, le tue aggiornamenti rimangono veloci anche quando l'app, la squadra e la base utenti aumentano.

Continua da Come mantenere gli aggiornamenti Capgo sottili e veloci.

Se stai utilizzando Come mantenere gli aggiornamenti Capgo sottili e veloci per pianificare la routing dei canali e il rilascio in fasi, connettilo con Canali per i dettagli di implementazione in Canali, Canali Dal dettaglio di implementazione nei canali, Canali Dal dettaglio di implementazione nei canali, Soluzione di testing beta Dal workflow del prodotto in Soluzione di testing beta, e Soluzione di targeting versione Dal workflow del prodotto in Soluzione di targeting versione.