Come mantenere gli aggiornamenti di Capgo sottili e veloci

The miglior aggiornamento live è quello che i tuoi utenti notano a malapena.

Solitamente ciò significa tre cose:

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

The same “keep OTA lean” advice that works in React Native land also applies to Capgo. The difference is that Capgo gives Capacitor teams a few extra levers: Aggiornamenti delta, canali, rollback automatico, target di versione, e facoltativo crittografia end-to-end.

Se li utilizzate insieme, si ottengono carichi più piccoli, installazioni più veloci e molto meno disordine operativo.

Lean è importante anche quando il MAU rimane lo stesso.

Un utile dettaglio specifico di Capgo: il MAU di 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. È importante 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 spreco di banda per rilasci falliti o annullati
• Raggio d'azione più piccolo quando si testa o si staga un rilascio

Aggiornamenti lean sono realmente sulla velocità, la sicurezza e la disciplina operativa.

1. Impostare le aggiornamenti Delta come default

Se fai solo una cosa, fai questo.

Capgo’s Aggiornamenti Delta invia solo i file che sono stati modificati tra le versioni anziché scaricare nuovamente l'intero pacchetto web. Questo è 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 su upload di pacchetti completi:

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

Utilizza solo --delta-only quando la tua flotta di produzione supporta gli aggiornamenti Delta. In caso di 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 l'aggiornamento.

Questo è ancora più importante se utilizzi 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 i pacchetti OTA quietamente si gonfiano.

Alcune regole pratiche:

• Non inlinare grandi immagini o media all'interno di JavaScript quando un file di asset normale farà al caso.
• Mantieni il contenuto che cambia frequentemente sul tuo proprio CDN o API se non deve vivere all'interno del pacchetto di distribuzione dell'applicazione.
• 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 che gli asset stabili rimangano stabili. Con gli aggiornamenti Delta, i file invariati vengono riutilizzati al posto di essere scaricati nuovamente.

Questa è una delle vie più facili per mantenere Capgo veloce man mano che l'app cresce. Il peggior modello è una piccola correzione UI che costringe gli utenti a scaricare un mucchio di media non correlati.

3. Mantieni 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
• 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 continuate a spingere cambiamenti strutturali importanti nella strada dell'aggiornamento OTA, la vostra strategia di aggiornamento diventa più pesante e rischiosa nel tempo.

Usate due linee di rilascio a scopo:

Canale nativo

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

bun run build
bunx cap sync

Poi rilasciate una versione normale del negozio.

Canale Capgo

Per iterazioni sicure del layer web:

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

Rinfrescate anche la vostra linea di base nativa regolarmente se avete aggiunto recentemente molti asset di lunga durata. Un nuovo build del negozio incorpora quella nuova linea di base, che mantiene le differenze future Capgo più piccole.

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

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

del canale Capgo sistema dei canali è il modo più pulito per controllare questo:

• staging per QA
• beta per i tester invitati
• production per tutti
• hotfix per il ripristino di emergenza

Un flusso semplice assomiglia a questo:

1. Carica su staging.
2. Verifica su dispositivi reali.
3. Rilascia gradualmente, sia attraverso i canali controllati o la distribuzione basata sulle percentuali.
4. Ritorna immediatamente se la salute diminuisce.

Se la tua app ha più basi native in circolazione, associa i canali con version targeting. Questo tiene lontano le bundle incompatibili o troppo pesanti dai binari più vecchi.

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

5. Se abiliti gli aggiornamenti diretti, ottimizza la fase di avvio

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

Capgo's comportamento di aggiornamento documentazione raccomanda esplicitamente di associarlo directUpdate con gli aggiornamenti Delta. Questo è il default giusto.

La seconda barriera è notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

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

• Salva e ripristina lo stato dell'app con cura se si ricarica immediatamente notifyAppReady() 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, la guida
• notificaAppReady
• è degna di essere riletta.

6. Utilizza i canali di aggiornamento interni al posto di rebuilds nativi non necessari Se il tuo app non segnala pronto entro i 10 secondi di default o entro ciò che hai impostato nel tuo config

6. Utilizza i canali di aggiornamento interni al posto di rebuilds nativi non necessari

A molte squadre mobili perd tempo a costruire 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
• flag di feature
• rendering di una risposta o API

allora un Capgo aggiornamento è spesso l'artifact di revisione più veloce.

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

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

7. Mantieni separato il lean da quello segreto

Le piccole raccolte e le raccolte sicure risolvono problemi diversi.

I canali controllano l'accesso. Non rendono una raccolta confidenziale da sole.

Se hai bisogno di garanzie di consegna più forti:

• abilita la crittografia degli aggiornamenti in tempo reale,
• utilizza un archivio personalizzato o una consegna auto-hosted,
• mantieni le chiavi private solo nei flussi di lavoro di CI o operatori sicuri.

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

• per velocità
• crittografato per il controllo della consegna
• canali per il controllo della distribuzione
• rollback per la ripristino.

Un flusso di lavoro pratico "lean Capgo"

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

1. Tenere separate le linee di rilascio native e OTA.
2. Caricare modifiche JS con --delta di default.
3. Usare staging e beta canali prima production.
4. Guarda Aggiorna le statistiche e i log, non solo prima della distribuzione, ma anche dopo. Trasforma i PR in anteprime installabili quando non è necessario un build nativo.
5. Tieni fuori dal bundle grandi file di media che cambiano frequentemente, se possibile.
6. Aggiorna il baseline nativo dopo un aumento significativo degli asset o delle modifiche native.
7. Tratta
8. e il comportamento di rollback come parte dell'ingegneria di rilascio, non come trivia di configurazione. notifyAppReady() Quella combinazione rimane veloce molto più a lungo dell'approccio comune 'carica solo le modifiche'.

Pensiero finale

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

For Capgo teams, “lean and fast” is not just a bundle-size problem.

Ingegneria

Utilizza gli aggiornamenti Delta per il dimensione del payload, i canali per la dimensione del rollout e i ripristini 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.

Continua da Come mantenere gli aggiornamenti di Capgo sottili e veloci

Se stai utilizzando Come mantenere gli aggiornamenti di Capgo sottili e veloci per pianificare la routing dei canali e il rollout a fasi, connettilo con Canali contexto: nome del feature di Capgo per i canali di rilascio. Pagina/area: pagina di marketing delle soluzioni di Capgo. Ruolo: breve etichetta UI o elemento di navigazione. Visto in: pagina solutions/white-label.astro. Chiave di messaggio `solutions_white_label_visual_cell2_value` (Valore della cella visiva del white label delle soluzioni). per i dettagli di implementazione in Canali, Canali contexto: nome del feature di Capgo per i canali di rilascio. Pagina/area: pagina di marketing delle soluzioni di Capgo. Ruolo: breve etichetta UI o elemento di navigazione. Visto in: pagina solutions/white-label.astro. Chiave di messaggio `solutions_white_label_visual_cell2_value` (Valore della cella visiva del white label delle soluzioni). per i dettagli di implementazione in Canali, Canali per il workflow del prodotto nella Soluzione di Test Beta, e Soluzione di Targeting della Versione per il workflow del prodotto nella Soluzione di Targeting della Versione.