Aggiornamenti frequenti del sistema operativo sono fondamentali per garantire la sicurezza e l'accesso alle funzionalità più recenti. Per impostazione predefinita, ChromeOS rilascia un aggiornamento completo del sistema operativo sul canale stabile (Stable) ogni quattro settimane circa. Gli aggiornamenti di minore entità, ad esempio le correzioni di sicurezza e gli aggiornamenti del software, si verificano ogni due o tre settimane. Gli sviluppatori possono testare le loro applicazioni sui canali Dev o Beta prima del rilascio di ogni nuova versione stabile, per assicurarsi che funzionino correttamente. Il canale Dev viene aggiornato 1 o 2 volte alla settimana e mostra a cosa sta lavorando il team di Chrome in questo momento. Questa build è ancora soggetta a bug, ma offre un'anteprima di 9-12 settimane di ciò che verrà aggiunto alla versione stabile. Il canale beta offre un'anteprima di 4-6 settimane delle funzionalità disponibili nella versione stabile.
Tuttavia, i test mensili con questi canali esistenti possono essere difficili da gestire per gli amministratori di sistema e gli sviluppatori. Per fornire un supporto migliore e dare a tutti più tempo per i test, abbiamo creato un nuovo piano di assistenza a lungo termine, con canali di assistenza a lungo termine, per ChromeOS.
Versioni con assistenza a lungo termine
Le release di supporto a lungo termine di ChromeOS sono uno strumento efficace per ridurre l'impegno necessario per gestire i dispositivi in un'organizzazione e certificare che le app funzionino correttamente per ogni aggiornamento del sistema operativo. Amministratori e sviluppatori devono familiarizzare con queste funzionalità per offrire un'esperienza ottimale alle organizzazioni che le adottano.
ChromeOS offre due versioni di assistenza a lungo termine: una versione candidato all'assistenza a lungo termine (LTC) e una versione stabile di assistenza a lungo termine (LTS).
- Candidato all'assistenza a lungo termine (LTC): utilizzato come base per la successiva versione LTS e viene estratto dalla versione stabile tre mesi prima di LTS, offrendo agli amministratori un'anteprima per prepararsi.
- Canale di assistenza a lungo termine (LTS): aggiornato ogni 6 mesi, questo canale ha la cadenza di rilascio più lenta ed è pensato per sostituire il normale canale stabile. Ad eccezione di alcuni utenti che devono rimanere su LTC a scopo di test, la maggior parte deve utilizzare LTS quando si adottano versioni di supporto a lungo termine in un'organizzazione.
Cronologia delle release stabile, LTC e LTS
Il ciclo di vita LTC / LTS funziona nel seguente modo:
- La release LTC (108 LTC nel diagramma) viene creata a partire dalla release stabile (108 Stable), quindi durante il primo mese sono identiche.
- LTC inizia a ricevere correzioni di sicurezza ogni due settimane per i tre mesi successivi fino alla prossima release LTS (LTS 108 nel diagramma). Ciò significa che tre mesi dopo il rilascio iniziale di LTC, LTC rispecchierà LTS.
- Una volta rilasciato LTS, continuerà a ricevere correzioni di sicurezza ogni due settimane.
- I dispositivi lasciati su LTC dopo il rilascio di LTS continueranno a ricevere correzioni di sicurezza ogni due settimane e verranno aggiornati automaticamente alla successiva release di LTC quando verrà rilasciata.
Oltre alle funzionalità del sistema operativo e alle correzioni di bug, gli aggiornamenti firmware sono inclusi anche nelle release LTS fino alla scadenza degli aggiornamenti automatici (AUE) di un dispositivo.
Per attivare uno dei due canali, devi disporre di un dominio Google e di un dispositivo gestito. Puoi registrarti per una prova di Chrome Enterprise Upgrade per accedere alla Console di amministrazione Google, che ti consente di configurare ed eseguire il deployment dei Chromebook gestiti. Infine, passa i dispositivi gestiti al canale LTS o LTC dalla Console di amministrazione. Ti consigliamo di mantenere la maggior parte dei dispositivi sul canale LTS e di utilizzare LTC per testare la prossima release LTS.
Flusso di lavoro di test per LTC / LTS
LTC e LTS sono progettati per ridurre notevolmente gli sforzi di test per gli amministratori, garantendo al contempo un'esperienza sicura del sistema operativo. Per mantenere gli amministratori di sistema e gli sviluppatori in linea con il ciclo di vita del supporto a lungo termine, devi:
- Esegui test su Dev e Beta prima della release stabile che corrisponde alla prossima release del canale LTC.
- Una volta rilasciata la versione LTC, esegui dei test per assicurarti che le correzioni di sicurezza applicate non influiscano sul tuo lavoro fino al rilascio della versione LTS.
- Una volta che LTC viene promosso a LTS, LTS continuerà a ricevere correzioni di sicurezza ogni due settimane. Ti consigliamo di testarli.
Prendendo come riferimento il diagramma del ciclo di vita:
- Inizia i test sulle versioni 108 Dev e 108 Beta per assicurarti che tutto funzioni correttamente prima della release 108 Stable, da cui verrà estratta la versione 108 LTC.
- Esegui test su 108 LTC ogni due settimane fino al rilascio di 108 LTS tre mesi dopo la data di taglio iniziale.
- Continua a eseguire regolarmente i test sulla versione LTS per assicurarti che le correzioni di sicurezza non causino problemi.
Gestione delle modifiche tra le versioni LTC/LTS
Che tu adotti una versione di ChromeOS con assistenza a lungo termine o lavori con un'organizzazione che lo fa, la gestione corretta delle modifiche tra le versioni è fondamentale. Puoi aggiungere una funzionalità basata sulle nuove funzionalità della piattaforma o fare affidamento su una funzionalità ritirata nelle versioni successive. In alternativa, potresti fare affidamento su funzionalità specifiche di una versione specifica di un'app o voler offrire agli utenti la possibilità di scegliere la versione da eseguire. Per garantire un accesso senza problemi all'applicazione, devi assicurarti che sia compatibile con le versioni precedenti, fornire istanze separate per versione o entrambe le cose.
Garantire la compatibilità con le versioni precedenti
La compatibilità con le versioni precedenti consente alle versioni più recenti dell'applicazione di essere eseguite su versioni precedenti della piattaforma. Puoi farlo con una tecnica chiamata rilevamento delle funzionalità, in cui controlli la disponibilità di una nuova funzionalità prima di provare a utilizzarla. Se esiste, lo utilizzi; in caso contrario, fornisci facoltativamente un elemento di riserva. La versione generalizzata di questa tecnica è chiamata feature flag, in cui viene caricato un percorso di codice a seconda che una funzionalità sia abilitata, tramite la disponibilità della funzionalità o la configurazione a livello di app o utente. Le app per Android, le estensioni di Chrome e le app web traggono tutte vantaggio da questa tecnica. Se ti assicuri che le versioni più recenti della tua app siano compatibili con le versioni precedenti, puoi gestire una singola applicazione per tutti i tuoi utenti.
Un'app web che vuole fornire animazioni che richiedono molte risorse di calcolo potrebbe voler implementare WebGPU per i browser che lo supportano e ricorrere ad animazioni più semplici basate su JavaScript se non è disponibile. Per farlo, potrebbero:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Fornire istanze separate
A volte le differenze tra le versioni sono troppo grandi per essere gestite tramite tecniche di compatibilità con le versioni precedenti. Le differenze tra le funzionalità potrebbero essere troppo grandi o potresti avere esigenze aziendali che richiedono una versione con supporto a lungo termine separata dall'applicazione principale. In questo caso, ti consigliamo di fornire istanze separate per ogni versione. Sebbene ciò garantisca che gli utenti utilizzino una versione specifica della tua app, potrebbe aumentare i costi operativi, quindi tienilo presente quando scegli questa soluzione.
Per le app web, fornire un'istanza separata di solito significa ospitare le diverse versioni dell'applicazione su URL diversi, il che potrebbe richiedere server, database o altre infrastrutture del sito web separati. Per le applicazioni per Android, ciò significa avere schede del Play Store separate per ogni versione. Ciò potrebbe confondere gli utenti, in quanto sarebbero disponibili più applicazioni simili e potrebbero non sapere quale scegliere. Le estensioni Chrome possono anche avere più schede oppure puoi consigliare ai tuoi clienti di bloccare la versione dell'estensione Chrome di cui hanno bisogno tramite la Console di amministrazione Chrome facendo riferimento a questa documentazione, che descrive in dettaglio come bloccare le estensioni e alcuni avvisi associati al blocco.
Un'app per Android che vuole fornire solo una versione con supporto a lungo termine agli utenti di ChromeOS può creare una scheda separata con quanto segue nel file AndroidManifest.xml per specificare che deve essere distribuita solo ai dispositivi ChromeOS:
<uses-feature android:name="org.chromium.arc" android:required="true" />