Saltare al contenuto principale
Aggiornamenti di produzione

Ottieni ogni utente con la versione più aggiornata

Sostituisci un nuovo bundle web dal CLI o dal CI. Gli dispositivi lo scaricano in background e lo eseguono la prossima volta che l'app torna in primo piano. Rilascialo per percentuale, osservalo in Observe e annullalo se non funziona correttamente.

Nessuna carta di credito richiesta
Rollback automatico integrato
Aggiornamenti solo livello web

Il Problema

Un rilascio di store è un modo lento per inviare una piccola correzione

Il percorso di correzione solo per store

1

Trova il bug

Il monitoraggio o i rapporti di supporto segnalano uno schermo rotto. La correzione è poche righe di JavaScript o CSS.

2

Costruisci un nuovo binario

Aggiorni la versione, costruisci per iOS e Android, e prepara due invii di store.

3

Aspetta la revisione

La revisione del store può durare 24-48 ore, a volte molto di più. Una rifiutazione inizia di nuovo l'attesa.

4

Aspetta che gli utenti aggiornino

Dopo l'approvazione, ogni utente deve ancora installare la nuova versione. Fino a quel momento, eseguono la vecchia code.

Ogni passo aggiunge tempo tra la disponibilità della correzione e l'installazione della correzione sui dispositivi degli utenti.

Why store fixes reach users slowly

24–48h+

Tempo di revisione tipico del negozio

Apple e Google esaminano ogni nuovo binario. L'esame può durare 24–48 ore, a volte molto di più, e un rifiuto significa risubmettere.

Per utente

Store updates depend on each device

Un aggiornamento del negozio raggiunge un dispositivo solo quando l'utente, o le impostazioni di aggiornamento automatico, lo installa. Alcuni dispositivi rimangono su vecchie versioni per molto tempo.

2 negozi

Due presentazioni per ogni correzione

La stessa correzione web va attraverso l'App Store e Google Play separatamente, ognuno con la propria revisione e rilascio.

La Soluzione

Come un live update raggiunge i suoi utenti

Questo è il comportamento di aggiornamento predefinito di Capgo. Nessun promemoria di aggiornamento, nessun riavvio obbligatorio e nessuna sottoscrizione del store per le modifiche al layer web.

Flusso di aggiornamento predefinito

  1. L'app verifica gli aggiornamenti

    Quando l'app viene riportata in primo piano, e ogni 10 minuti mentre rimane aperta, l'aggiornatore chiede a Capgo il canale più recente del pacchetto.

    In primo piano

  2. Scarica in background

    Il nuovo pacchetto scarica mentre l'utente continua ad utilizzare la versione corrente. Con gli aggiornamenti delta, scaricano solo i file modificati.

    Nessuna interruzione

  3. Si attiva alla prossima ripresa

    Quando l'utente lascia l'app, l'aggiornatore installa il pacchetto. La prossima volta che lo apre, esegue la nuova versione.

    Prossimo in primo piano

Perché gli utenti vedano la nuova versione non appena aprono l'app? I modi di aggiornamento diretto applicano la versione alla partenza mentre lo schermo di caricamento è mostrato.

Vedi gli aggiornamenti diretti

Documentazione del comportamento di aggiornamento

Come funziona

Come le squadre di produzione inviano una correzione con Capgo

Una tipica distribuzione per un'app Capacitor già presente nei negozi. Ogni comando di seguito è tratto dai documenti di Capgo CLI.

  1. Configura l'aggiornatore una volta

    Esegui il wizard di configurazione, quindi assicurati che la tua app chiami notifyAppReady() dopo aver iniziato. Una bundle che non fa mai quel chiamata si annulla da sola.

    npx @capgo/cli@latest init
    # in your app start-up code
    await CapacitorUpdater.notifyAppReady()
    Documentazione di notifyAppReady()
  2. Carica la correzione in una porzione di produzione

    Usa --delta per far scaricare ai dispositivi solo i file modificati, e --rollout per iniziare con una piccola quota di dispositivi. Tutti gli altri restano sulla bundle stabile.

    npx @capgo/cli@latest bundle upload --channel production --delta --rollout 5
    Documentazione delle rotazioni progressive
  3. Fermare Capgo una distribuzione andata male

    Attiva l'auto-pausa con un limite di fallimenti (500 punti base è il 5%). Se le fallimenti superano il limite, Capgo ripristina la distribuzione. Controlla la nuova versione in Observe mentre funziona.

    npx @capgo/cli@latest channel set production \
      --auto-pause-enabled \
      --auto-pause-failure-rate-bps 500 \
      --auto-pause-action rollback
    Osserva documentazione
  4. Promuovi a tutti

    Quando i numeri sembrano giusti, promuovi il bundle a ogni dispositivo sul canale. Se no, invia il gruppo di distribuzione di ritorno a stabile.

    npx @capgo/cli@latest channel set production --rollout-promote
    # or, if something looks wrong
    npx @capgo/cli@latest channel set production --rollout-rollback
    Ripristini

Progettato per rilasci di produzione

I team di produzione utilizzano questi controlli per distribuire spesso senza sorprendere gli utenti.

Aggiornamenti delta

Carica con --delta e i dispositivi scaricano solo i file che sono stati modificati dal loro bundle corrente. I grandi asset che cambiano raramente vengono scaricati una volta.

  • Scarichi più piccoli per gli utenti su reti lente o a tariffa
  • In modalità predefinita, gli aggiornamenti si applicano tra le sessioni, non nel mezzo di una di esse
Documentazione aggiornamenti delta

--delta

Solo i file modificati vengono scaricati

Rilascio progressivo con pausa automatica

Invia un nuovo pacchetto a una quota casuale di un canale, mentre tutti gli altri restano sul pacchetto stabile. Aumenta la percentuale, promuovi o annulla dal CLI o dalla console.

  • La pausa automatica può bloccare o annullare un rilascio quando il tasso di fallimento supera il tuo limite
  • Observe confronta la nuova versione con la precedente prima di aumentare l'esposizione
Documentazione rilascio progressivo

1–5%

Un passo tipico del rilascio iniziale

Annullamento automatico

Ogni aggiornamento deve dimostrare di funzionare. Se un nuovo pacchetto non chiama notifyAppReady() in tempo, il dispositivo torna al pacchetto precedente e segna il nuovo come fallito.

  • Il trigger di annullamento si attiva se notifyAppReady() non viene chiamato entro appReadyTimeout (10 secondi di default)
  • Ripristina l'intero canale a qualsiasi bundle precedente dalla sua storia
Documentazione notifyAppReady()

10s

Tempo di attesa predefinito prima del rollback automatico

Distribuzione consapevole delle recensioni di store

Capgo fornisce il layer web di Capacitor: JavaScript, CSS e risorse. Non modifica il binario nativo, plugin, autorizzazioni, entità o metadati della store. La recensione della store è specifica dell'app, quindi rimani responsabile per la conformità alle politiche e l'approvazione.

  • Utilizza una rilascio nativa della store quando cambiano le capacità native, plugin, autorizzazioni o metadati della store
  • Mantieni le note del revisore chiare sulle funzionalità dell'app e sul percorso di aggiornamento della layer web.
  • Rivista le politiche correnti di Apple e Google prima di ogni invio

Cosa fanno le squadre di produzione con questo

Lavori di rilascio quotidiano una volta attivati gli aggiornamenti in tempo reale. Ogni scheda si collega ai documenti.

Risoluzione di bug critici

Una schermata di accesso o di checkout rotto riceve un aggiornamento di livello web. Caricalo e i dispositivi lo rileveranno alla prossima verifica di aggiornamento.

Documentazione del comportamento dell'aggiornamento

Modifiche di copia e contenuti

Aggiorna il testo di aiuto, sostituisci le immagini e gli altri asset inclusi senza dover creare un nuovo file binario.

Documentazione della compatibilità nativa

Salute della versione in Observe

Confrontare una nuova raccolta con la precedente: tasso di problemi, tempo di lancio e WebView, e marcatori di distribuzione per versione.

Documentazione di Observe

Aggiornamento più rapido con notifiche di aggiornamento

Dopo aver modificato il bundle di un canale, invia una notifica di aggiornamento silenziosa affinché i dispositivi verifichino ora anziché alla loro prossima attività in primo piano.

Proteggere le versioni native più vecchie

Proteggere le versioni native più vecchie

Blocca gli aggiornamenti principali su un canale in modo che un pacchetto che richiede nuove librerie native code non raggiunga un binario più vecchio.

Documentazione per la versione di destinazione

Ripristina da storia del canale

Scegli qualsiasi bundle precedente nella scheda Storia del canale per farlo tornare in vita per ogni dispositivo su quel canale.

Documentazione per i ripristini

Infrastruttura che già serve applicazioni di produzione

Capgo ha consegnato aggiornamenti live alle applicazioni di produzione dal 2021.

Aggiornamenti al mese
1B+
Dispositivi raggiunti
90M+
Applicazioni che utilizzano Capgo
4.700+
Latenza tipica del API
~50ms

App costruite con Capacitor

Le app ad alta affluenza richiedono aggiornamenti UI affidabili in produzione

Gli app di meteo, salute pubblica e telecomunicazioni dipendono da interfacce accurate, avvisi e navigazione. Gli aggiornamenti in produzione aiutano a distribuire aggiustamenti di interfaccia approvati mentre si monitora l'adozione prima di espandere ulteriormente.

Icona dell'app di previsione del tempo Windy.com METEO

Windy.com - Previsioni del tempo

Weather app where maps, alerts, and navigation fixes need careful production expansion.

Installo su Google Play
32,9M
Valutazione della store
4.7
Icona dell'app Conecte SUS MEDICALE

Connetti

Applicazione di salute pubblica dove le informazioni di orientamento e di servizio richiedono aggiornamenti veloci e affidabili.

Installo su Google Play
27,7M
Valutazione negli store
4.6
Icona dell'app Mi Orange TOOL

Arancia Mia

L'app di conto telefonico dove le notifiche e le superfici dell'account cambiano frequentemente.

Installazioni Google Play
9,3M
Valutazione negli store
4.2

Prova dei clienti

Ciò che le squadre che utilizzano Capgo dicono

5.0/5 valutato dalle squadre di sviluppatori 9,400+ team Leggi le recensioni
Ritratto di Sergiu S

Sergiu S

Capo Sviluppatore, drivolino GmbH

The Capgo Capacitor Updater plugin ha completamente rivoluzionato il modo in cui distribuiamo gli aggiornamenti. Ciò che un tempo richiedeva giorni ora richiede solo minuti.

Kapil

Fondatore, NuTriQ

“La possibilità di inviare aggiornamenti OTA in produzione istantaneamente senza dover attendere i cicli di revisione completo dell'App Store è stato un enorme vantaggio operativo.”

Ritratto di Michael Haberler

Michael Haberler

aggiornamenti in produzione

Bravo per il plugin di aggiornamento. Funziona senza problemi per me, e gli aggiornamenti in tempo reale sono un acceleratore incredibile per il ritorno veloce dei test.

FAQ

Domande dei team di produzione

Come gli aggiornamenti raggiungono i dispositivi e cosa fare quando uno va storto

Quando gli utenti ricevono un live update?

Di default, l'app controlla gli aggiornamenti quando viene riportata in primo piano e ogni 10 minuti mentre rimane aperta. Scarica il nuovo pacchetto in background, lo installa quando l'utente lascia l'app e lo esegue la prossima volta che l'apre. L'impostazione autoUpdate cambia questo comportamento.

Aggiorna la documentazione del comportamento

Can devices pick up an urgent fix faster?

Sì. Dopo aver modificato il canale di un bundle, invia una notifica di aggiornamento dal console o aggiungi --send-update-notification al caricamento del bundle. I dispositivi ricevono un push silenzioso e controllano immediatamente. Questo richiede Capgo Notifiche con credenziali di push iOS e Android. La consegna è di tipo 'meglio sforzo': un'app offline o chiusa forzatamente controlla al suo prossimo avvio.

Invia notifica di aggiornamento

Cosa succede se un aggiornamento rompe l'app?

Se un nuovo bundle non chiama notifyAppReady() entro 10 secondi (il timeout di default appReady), il dispositivo torna al bundle lavorante precedente e segna il nuovo come fallito. Per bug che non bloccano l'app dal partire, annulla il roll-back progressivo o scegli un bundle precedente dalla storia del canale.

Documentazione dei roll-back

Come rilasciamo a un piccolo gruppo di utenti per primo?

Carica con --rollout per inviare il bundle a una condivisione casuale e 'stick' del canale mentre tutti gli altri restano su stable. Aumenta la percentuale, promuovi o annulla dal CLI o dal console. L'auto-pausa può fermare l'esposizione quando il tasso di fallimento supera un certo livello.

Documentazione dei roll-out progressivi

Cosa non può cambiare un live update?

Le aggiornamenti in tempo reale sostituiscono la layer web: JavaScript, HTML, CSS e asset. I plugin nativi, gli aggiornamenti Capacitor, le modifiche a capacitor.config e i file del progetto iOS o Android richiedono un rilascio di store. Capgo controlla i bundle per compatibilità nativa al caricamento, e i canali possono bloccare gli aggiornamenti ai binari più vecchi.

Documentazione di compatibilità nativa

Invia la tua prossima correzione come live update

Prova il flusso completo sul tuo'app durante la prova: carica un pacchetto, distribuiscilo a pochi dispositivi e torna indietro.