Częste aktualizacje systemu operacyjnego są niezbędne, aby zapewnić bezpieczeństwo i dostęp do najnowszych funkcji. Domyślnie ChromeOS udostępnia pełną aktualizację systemu w kanale stabilnym (Stable) średnio co 4 tygodnie. Mniejsze aktualizacje, na przykład poprawki zabezpieczeń i aktualizacje oprogramowania, są udostępniane co 2–3 tygodnie. Deweloperzy mogą testować swoje aplikacje w wersji deweloperskiej lub beta przed wydaniem każdej nowej stabilnej wersji, aby upewnić się, że działają one prawidłowo. Jest on aktualizowany 1 lub 2 razy w tygodniu i pokazuje, nad czym obecnie pracuje zespół Chrome. Ta kompilacja może zawierać błędy, ale pozwala na 9–12-tygodniowe wyprzedzenie wersji stabilnej. Wersja beta udostępnia funkcje 4–6 tygodni wcześniej niż wersja stabilna.
Jednak testowanie co miesiąc na tych kanałach może być trudne do śledzenia dla administratorów systemów i programistów. Aby zapewnić lepsze wsparcie i dać wszystkim więcej czasu na testowanie, stworzyliśmy nowy plan wsparcia długoterminowego z kanałami wsparcia długoterminowego dla ChromeOS.
Wersje wspierane długoterminowo
Wersje ChromeOS z długoterminowym wsparciem to przydatne narzędzie, które ułatwia zarządzanie urządzeniami w organizacji i zapewnia, że aplikacje działają prawidłowo po każdej aktualizacji systemu operacyjnego. Zarówno administratorzy, jak i deweloperzy powinni się z nimi zapoznać, aby zapewnić organizacjom, które je wdrażają, jak najlepsze wrażenia.
ChromeOS oferuje 2 wersje wsparcia długoterminowego: kandydującą do wsparcia długoterminowego (LTC) i stabilną wsparcia długoterminowego (LTS).
- Kandydat do wsparcia długoterminowego (LTC) – używany jako podstawa następnej wersji LTS. Jest wyodrębniany z wersji stabilnej 3 miesiące przed LTS, co daje administratorom możliwość przygotowania się.
- Kanał wsparcia długoterminowego (LTS) – aktualizowany co 6 miesięcy. Ten kanał jest aktualizowany najrzadziej i ma zastąpić zwykły kanał stabilny. Z wyjątkiem kilku użytkowników, którzy powinni pozostać w kanale LTC na potrzeby testów, większość powinna korzystać z wersji LTS, gdy w organizacji zostaną wdrożone wersje z długoterminowym wsparciem.
Harmonogram wersji stabilnych, LTC i LTS
Cykl życia LTC / LTS wygląda następująco:
- Wersja LTC (108 LTC na diagramie) jest wycinana z wersji stabilnej (108 Stable), więc w pierwszym miesiącu obie są identyczne.
- LTC zaczyna otrzymywać poprawki zabezpieczeń co 2 tygodnie przez kolejne 3 miesiące, aż do następnej wersji LTS (LTS 108 na diagramie). Oznacza to, że 3 miesiące po pierwszej wersji kanału LTC będzie on odzwierciedlać kanał LTS.
- Po udostępnieniu kanału LTS urządzenia będą nadal otrzymywać poprawki zabezpieczeń co 2 tygodnie.
- Urządzenia pozostawione na kanale LTC po udostępnieniu kanału LTS będą nadal otrzymywać poprawki zabezpieczeń co 2 tygodnie i automatycznie zaktualizują się do następnej wersji kanału LTC, gdy zostanie ona udostępniona.
Oprócz funkcji systemu operacyjnego i poprawek błędów aktualizacje oprogramowania układowego są też dołączane do wersji LTS aż do daty zakończenia automatycznych aktualizacji urządzenia.
Aby włączyć dowolny kanał, musisz mieć domenę Google i zarządzane urządzenie. Możesz zarejestrować się w wersji próbnej Chrome Enterprise, aby uzyskać dostęp do konsoli administracyjnej Google, która umożliwia konfigurowanie i wdrażanie zarządzanych Chromebooków. Na koniec przełącz zarządzane urządzenia na kanał LTS lub LTC w konsoli administracyjnej. Zalecamy, aby większość urządzeń korzystała z kanału LTS, a kanału LTC używać do testowania nadchodzącej wersji LTS.
Proces testowania w przypadku kanałów LTC i LTS
Wersje LTC i LTS zostały zaprojektowane tak, aby znacznie ograniczyć wysiłek administratorów związany z testowaniem, a jednocześnie zapewnić bezpieczne korzystanie z systemu operacyjnego. Aby administratorzy systemów i deweloperzy mogli dostosować się do długoterminowego cyklu życia pomocy, powinni:
- Testuj w wersji deweloperskiej i beta przed wprowadzeniem wersji stabilnej, która będzie zgodna z nadchodzącą wersją kanału LTC.
- Gdy LTC zostanie udostępniona, przetestuj ją, aby mieć pewność, że zastosowane poprawki zabezpieczeń nie wpłyną na Twoją pracę do czasu udostępnienia LTS.
- Gdy kanał LTC zostanie przekształcony w LTS, będzie nadal otrzymywać poprawki zabezpieczeń co 2 tygodnie. Warto je też przetestować.
Korzystając z diagramu cyklu życia:
- Rozpocznij testowanie w wersji deweloperskiej 108 i wersji beta 108, aby upewnić się, że wszystko działa prawidłowo przed wydaniem wersji stabilnej 108, z której zostanie wyodrębniona wersja 108 LTC.
- Testuj na 108 LTC co 2 tygodnie, aż 108 LTS zostanie wydany 3 miesiące od początkowej daty wydania.
- Regularnie przeprowadzaj testy na LTS, aby mieć pewność, że poprawki zabezpieczeń nie powodują żadnych problemów.
Zarządzanie zmianami między wersjami LTC/LTS
Niezależnie od tego, czy wdrażasz wersję ChromeOS z długoterminowym wsparciem, czy współpracujesz z organizacją, która to robi, prawidłowe zarządzanie zmianami między wersjami ma kluczowe znaczenie. Możesz dodać funkcję opartą na nowych możliwościach platformy lub skorzystać z funkcji, która została wycofana w późniejszych wersjach. Możesz też korzystać z określonych funkcji konkretnej wersji aplikacji lub chcesz dać użytkownikom możliwość wyboru wersji, z której będą korzystać. Aby zapewnić bezproblemowy dostęp do aplikacji, zadbaj o jej wsteczną kompatybilność, udostępnij osobne instancje dla każdej wersji lub zastosuj oba te rozwiązania.
Zapewnianie zgodności wstecznej
Zgodność wsteczna umożliwia uruchamianie nowszych wersji aplikacji na starszych wersjach platformy. Możesz to zrobić za pomocą techniki wykrywania funkcji, która polega na sprawdzeniu dostępności nowej funkcji przed jej użyciem. Jeśli istnieje, użyj jej. Jeśli nie, możesz podać wartość domyślną. Uogólniona wersja tej techniki to flagi funkcji, w których ścieżka kodu jest wczytywana w zależności od tego, czy funkcja jest włączona (na podstawie dostępności funkcji lub konfiguracji na poziomie aplikacji lub użytkownika). Ta technika jest przydatna w przypadku aplikacji na Androida, rozszerzeń do Chrome i aplikacji internetowych. Dzięki zapewnieniu wstecznej zgodności nowszych wersji aplikacji możesz zarządzać jedną aplikacją dla wszystkich użytkowników.
Aplikacja internetowa, która chce wyświetlać animacje wymagające dużej mocy obliczeniowej, może zaimplementować WebGPU w przeglądarkach, które go obsługują, a w przypadku braku tej funkcji używać prostszych animacji opartych na JavaScript. Aby to zrobić, mogą wykonać te czynności:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Zapewnij osobne instancje
Czasami różnice między wersjami są zbyt duże, aby można było je rozwiązać za pomocą technik zgodności wstecznej. Różnice w funkcjach mogą być zbyt duże lub możesz mieć potrzeby biznesowe, które wymagają oddzielnej wersji z długoterminowym wsparciem w porównaniu z główną aplikacją. W takim przypadku warto rozważyć udostępnienie osobnych instancji dla każdej wersji. Dzięki temu użytkownicy będą korzystać z określonej wersji aplikacji, ale może to zwiększyć koszty operacyjne. Pamiętaj o tym, wybierając to rozwiązanie.
W przypadku aplikacji internetowych udostępnienie osobnej instancji zwykle oznacza hostowanie różnych wersji aplikacji pod różnymi adresami URL, co może wymagać oddzielnych serwerów, baz danych lub innej infrastruktury witryny. W przypadku aplikacji na Androida oznacza to, że każda wersja musi mieć osobną stronę w Sklepie Play. Może to wprowadzać użytkowników w błąd, ponieważ będą dostępne różne podobne aplikacje i nie będą wiedzieć, którą wybrać. Rozszerzenia Chrome mogą mieć wiele wersji. Możesz też zalecić klientom przypięcie potrzebnej wersji rozszerzenia Chrome w konsoli administracyjnej Chrome. W tym celu skieruj ich do tej dokumentacji, w której znajdą szczegółowe informacje o przypinaniu rozszerzeń i związanych z tym ograniczeniach.
Aplikacja na Androida, która chce udostępniać wersję z długoterminowym wsparciem tylko użytkownikom ChromeOS, może utworzyć osobną kartę z następującym wpisem w pliku AndroidManifest.xml, aby określić, że powinna być dostarczana tylko na urządzenia z ChromeOS:
<uses-feature android:name="org.chromium.arc" android:required="true" />