Update sistem operasi secara rutin sangat penting untuk memastikan keamanan dan akses ke fitur terbaru. Secara default, ChromeOS merilis update OS lengkap ke saluran stabil (Stabil) kira-kira setiap 4 minggu. Update minor, seperti perbaikan keamanan dan update software, dilakukan setiap 2–3 minggu. Developer dapat menguji aplikasi mereka di saluran developer (Dev) atau beta (Beta) sebelum setiap versi stabil baru dirilis, untuk memastikan aplikasi mereka berfungsi dengan baik. Saluran Dev diupdate satu atau dua kali seminggu, dan menampilkan apa yang sedang dikerjakan tim Chrome saat ini. Build ini masih dapat berisi bug, tetapi memberikan pratinjau 9–12 minggu tentang fitur yang akan hadir di versi Stabil. Beta memberi Anda pratinjau fitur yang akan hadir pada versi Stabil selama 4–6 minggu.
Namun, pengujian bulanan dengan saluran yang ada ini dapat menyulitkan administrator dan developer sistem untuk terus mengikutinya. Untuk memberikan dukungan yang lebih baik dan memberi semua orang lebih banyak waktu untuk menguji, kami telah membuat rencana dukungan jangka panjang baru, dengan saluran dukungan jangka panjang, untuk ChromeOS.
Rilis dukungan jangka panjang
Rilis dukungan jangka panjang ChromeOS adalah alat yang efektif untuk mengurangi upaya pengelolaan perangkat di organisasi dan memastikan bahwa aplikasi berfungsi dengan baik untuk setiap update OS. Admin dan developer harus memahami fitur ini untuk memberikan pengalaman yang luar biasa kepada organisasi yang menggunakannya.
ChromeOS menawarkan dua rilis dukungan jangka panjang: rilis kandidat dukungan jangka panjang (LTC) dan rilis stabil dukungan jangka panjang (LTS).
- Kandidat dukungan jangka panjang (LTC) - digunakan sebagai dasar untuk versi LTS berikutnya dan dipotong dari Stabil tiga bulan sebelum LTS, sehingga admin dapat melihat pratinjau untuk bersiap.
- Saluran dukungan jangka panjang (LTS) - diupdate setiap 6 bulan, saluran ini memiliki ritme rilis paling lambat dan dimaksudkan sebagai pengganti saluran stabil normal. Kecuali beberapa pengguna yang harus tetap menggunakan LTC untuk tujuan pengujian, sebagian besar pengguna harus menggunakan LTS saat mengadopsi rilis dukungan jangka panjang di seluruh organisasi.
Linimasa rilis stabil, LTC, dan LTS
Siklus proses LTC / LTS berfungsi sebagai berikut:
- Rilis LTC (108 LTC dalam diagram) dibuat dari rilis stabil (108 Stabil), sehingga selama bulan pertama, keduanya identik.
- LTC mulai menerima perbaikan keamanan setiap dua minggu selama 3 bulan berikutnya hingga rilis LTS berikutnya (108 LTS dalam diagram). Artinya, 3 bulan setelah rilis LTC awal, LTC akan mencerminkan LTS.
- Setelah dirilis, LTS akan terus menerima perbaikan keamanan setiap dua minggu.
- Perangkat yang tetap menggunakan LTC setelah LTS dirilis juga akan terus menerima perbaikan keamanan setiap dua minggu, dan akan otomatis diupdate ke rilis LTC berikutnya saat rilis tersebut diluncurkan.
Selain fitur sistem operasi dan perbaikan bug, update firmware juga disertakan dalam rilis LTS hingga batas akhir update otomatis (AUE) perangkat.
Untuk mengaktifkan salah satu saluran, Anda harus memiliki domain Google dan perangkat terkelola. Anda dapat mendaftar ke uji coba Chrome Enterprise Upgrade untuk mendapatkan akses ke konsol Google Admin yang memungkinkan Anda menyiapkan dan men-deploy Chromebook terkelola. Terakhir, alihkan perangkat terkelola Anda ke saluran LTS atau LTC dari konsol Admin. Sebaiknya sebagian besar perangkat Anda tetap menggunakan saluran LTS dan gunakan LTC untuk menguji rilis LTS mendatang.
Alur kerja pengujian untuk LTC / LTS
LTC dan LTS dirancang untuk mengurangi upaya pengujian secara signifikan bagi admin, sekaligus memastikan pengalaman sistem operasi yang aman. Untuk menjaga keselarasan administrator sistem dan developer dengan siklus proses dukungan jangka panjang, Anda harus:
- Lakukan pengujian di Dev dan Beta sebelum rilis stabil yang cocok dengan rilis saluran LTC mendatang.
- Setelah LTC dirilis, lakukan pengujian untuk memastikan bahwa semua perbaikan keamanan yang diterapkan tidak memengaruhi pekerjaan Anda hingga LTS dirilis.
- Setelah LTC dipromosikan ke LTS, LTS akan terus mendapatkan perbaikan keamanan setiap dua minggu. Anda juga harus mengujinya.
Dengan mengambil diagram siklus proses sebagai referensi:
- Mulai pengujian di Chrome 108 Dev dan 108 Beta untuk memastikan semuanya berfungsi dengan baik sebelum rilis Stabil 108 yang akan menjadi dasar untuk membuat 108 LTC.
- Lakukan pengujian di 108 LTC setiap dua minggu hingga 108 LTS dirilis tiga bulan sejak tanggal pemotongan awal.
- Lanjutkan pengujian di LTS secara rutin untuk memastikan bahwa perbaikan keamanan tidak merusak apa pun.
Mengelola perubahan antara versi LTC/LTS
Baik saat mengadopsi versi ChromeOS dengan dukungan jangka panjang maupun bekerja dengan organisasi yang telah mengadopsinya, mengelola perubahan antarversi dengan benar sangatlah penting. Anda dapat menambahkan fitur berdasarkan kemampuan platform baru atau mengandalkan fitur yang tidak digunakan lagi dalam versi yang lebih baru. Atau, Anda dapat mengandalkan fitur tertentu dari aplikasi versi tertentu, atau ingin menawarkan kemampuan kepada pengguna untuk memilih versi yang mereka jalankan. Untuk memastikan akses aplikasi yang lancar, Anda harus berupaya memastikan aplikasi Anda kompatibel dengan versi sebelumnya, menyediakan instance terpisah per versi, atau keduanya.
Memastikan kompatibilitas mundur
Kompatibilitas mundur memungkinkan versi aplikasi Anda yang lebih baru berjalan di versi platform yang lebih lama. Anda dapat melakukannya dengan teknik yang disebut deteksi fitur, yaitu Anda memeriksa ketersediaan fitur baru sebelum mencoba menggunakannya. Jika ada, Anda menggunakannya; jika tidak, Anda dapat memberikan penggantian. Versi umum dari teknik ini disebut flag fitur, di mana jalur kode dimuat bergantung pada apakah fitur diaktifkan, baik melalui ketersediaan kemampuan atau konfigurasi tingkat aplikasi atau pengguna. Aplikasi Android, ekstensi Chrome, dan aplikasi web semuanya mendapatkan manfaat dari teknik ini. Dengan memastikan bahwa versi aplikasi yang lebih baru kompatibel mundur, Anda dapat mengelola satu aplikasi untuk semua pengguna.
Aplikasi web yang ingin menyediakan animasi intensif komputasi dapat menerapkan WebGPU untuk browser yang mendukungnya dan melakukan penggantian ke animasi yang lebih sederhana yang didukung JavaScript jika tidak tersedia. Untuk melakukannya, mereka dapat melakukan hal berikut:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Menyediakan instance terpisah
Terkadang, perbedaan antara versi terlalu besar untuk ditangani melalui teknik kompatibilitas mundur. Perbedaan fitur mungkin terlalu besar atau Anda mungkin memiliki kebutuhan bisnis yang mengharuskan adanya versi dukungan jangka panjang terpisah dari aplikasi utama Anda. Jika demikian, sebaiknya pertimbangkan untuk menyediakan instance terpisah untuk setiap versi. Meskipun hal ini memastikan bahwa pengguna menggunakan versi tertentu dari aplikasi Anda, hal ini dapat meningkatkan biaya operasional Anda, jadi ingatlah hal ini saat memilih solusi ini.
Untuk aplikasi web, menyediakan instance terpisah biasanya berarti menghosting berbagai versi aplikasi Anda di URL yang berbeda, yang berpotensi memerlukan server, database, atau infrastruktur situs lainnya yang terpisah. Untuk aplikasi Android, hal ini berarti memiliki listingan Play Store terpisah untuk setiap versi. Hal ini dapat menyebabkan kebingungan dari pengguna Anda karena akan ada beberapa aplikasi serupa yang tersedia dan mereka mungkin tidak tahu mana yang harus dipilih. Ekstensi Chrome juga dapat memiliki beberapa listingan, atau Anda dapat merekomendasikan pelanggan untuk menyematkan versi Ekstensi Chrome yang mereka butuhkan melalui konsol Admin Chrome dengan merujuk mereka ke dokumentasi ini yang menjelaskan cara menyematkan ekstensi dan beberapa peringatan terkait penyematan.
Aplikasi Android yang hanya ingin menyediakan versi dukungan jangka panjang kepada pengguna ChromeOS dapat membuat listingan terpisah dengan kode berikut dalam file AndroidManifest.xml untuk menentukan bahwa aplikasi hanya boleh dikirimkan ke perangkat ChromeOS:
<uses-feature android:name="org.chromium.arc" android:required="true" />