Regelmäßige Betriebssystemupdates sind wichtig, um die Sicherheit zu gewährleisten und Zugriff auf die neuesten Funktionen zu erhalten. Standardmäßig wird etwa alle vier Wochen ein vollständiges Update von ChromeOS für die stabile Version (Stable) veröffentlicht. Kleinere Updates wie Sicherheitspatches und Software-Updates gibt es alle zwei bis drei Wochen. Entwickler können ihre Anwendungen im Entwickler- (Dev) oder Betakanal (Beta) testen, bevor eine neue stabile Version veröffentlicht wird, um sicherzugehen, dass ihre Apps richtig funktionieren. Die Entwicklerversion wird ein- bis zweimal wöchentlich aktualisiert und zeigt, woran das Chrome-Team gerade arbeitet. Diese Version kann noch Fehler enthalten, bietet aber eine Vorschau von neun bis zwölf Wochen auf zukünftige Entwicklungen für die stabile Version. In der Betaversion erhalten Sie eine Vorschau von vier bis sechs Wochen auf zukünftige Funktionen der stabilen Version.
Monatliche Tests mit diesen vorhandenen Channels können jedoch für Systemadministratoren und Entwickler schwierig zu verwalten sein. Um einen besseren Support zu bieten und allen mehr Zeit zum Testen zu geben, haben wir einen neuen Langzeitsupportplan mit Langzeitsupportkanälen für ChromeOS erstellt.
Releases mit Langzeitsupport
Die LTS-Versionen von ChromeOS sind ein leistungsstarkes Tool, um den Aufwand für die Verwaltung von Geräten in einer Organisation zu reduzieren und zu bestätigen, dass Apps bei jedem Betriebssystemupdate gut funktionieren. Administratoren und Entwickler sollten sich mit ihnen vertraut machen, um Organisationen, die sie verwenden, eine optimale Nutzererfahrung zu bieten.
ChromeOS bietet zwei Langzeitsupport-Releases: einen LTS-Kandidaten (LTC) und einen LTS-Release.
- Kandidat für Langzeitsupport: Diese Version wird als Grundlage für die nächste Version „Langzeitsupport“ verwendet und drei Monate vor der Version „Langzeitsupport“ aus der stabilen Version abgeleitet. Administratoren können sich so rechtzeitig darauf vorbereiten.
- Version mit Langzeitsupport (LTS): Diese Version wird alle 6 Monate aktualisiert. Sie hat die langsamste Veröffentlichungsfrequenz und ist als Ersatz für die normale stabile Version gedacht. Mit Ausnahme einiger Nutzer, die zu Testzwecken auf LTC bleiben sollten, sollten die meisten Nutzer auf LTS sein, wenn Langzeitsupport-Releases in einer Organisation eingeführt werden.
Zeitachse für stabile Versionen, Kandidaten für Langzeitsupport und Langzeitsupport
Der Lebenszyklus von LTC / LTS funktioniert so:
- Der LTC-Release (108 LTC im Diagramm) wird aus dem stabilen Release (108 Stable) abgeleitet. Im ersten Monat sind beide Releases also identisch.
- Die Version „Kandidat für Langzeitsupport“ erhält in den nächsten drei Monaten alle zwei Wochen Sicherheitsupdates, bis die nächste Version „Langzeitsupport“ (108 LTS im Diagramm) veröffentlicht wird. Das bedeutet, dass die Version „Kandidat für Langzeitsupport“ drei Monate nach der Erstveröffentlichung der Version „Langzeitsupport“ entspricht.
- Nach der Veröffentlichung von LTS werden weiterhin alle zwei Wochen Sicherheitsupdates bereitgestellt.
- Geräte, die nach der Veröffentlichung der Version „Langzeitsupport“ weiterhin die Version „Kandidat für Langzeitsupport“ nutzen, erhalten ebenfalls alle zwei Wochen Sicherheitsupdates und werden automatisch auf die nächste Version „Kandidat für Langzeitsupport“ aktualisiert, wenn diese veröffentlicht wird.
Neben Betriebssystemfunktionen und Fehlerkorrekturen sind Firmware-Updates bis zum Ende der automatischen Updates (Auto Update Expiration, AUE) eines Geräts auch in LTS-Releases enthalten.
Um einen der beiden Kanäle zu aktivieren, benötigen Sie eine Google-Domain und ein verwaltetes Gerät. Sie können sich für eine Testversion für Chrome Enterprise-Upgrade registrieren, um Zugriff auf die Admin-Konsole zu erhalten. Dort können Sie verwaltete Chromebooks einrichten und bereitstellen. Stellen Sie Ihre verwalteten Geräte in der Admin-Konsole auf die Release-Version „Langzeitsupport“ oder „Kandidat für Langzeitsupport“ um. Wir empfehlen, die meisten Ihrer Geräte mit der Release-Version „Langzeitsupport“ zu verwenden und die Release-Version „Kandidat für Langzeitsupport“ zu nutzen, um das bevorstehende LTS-Release zu testen.
Test-Workflow für LTC / LTS
LTC und LTS sollen den Testaufwand für Administratoren erheblich reduzieren und gleichzeitig ein sicheres Betriebssystem gewährleisten. Damit Systemadministratoren und Entwickler über den langfristigen Supportlebenszyklus informiert sind, sollten Sie Folgendes tun:
- Testen Sie in der Entwickler- und Betaversion vor dem stabilen Release, das dem anstehenden LTC-Channel-Release entspricht.
- Sobald LTC veröffentlicht wurde, sollten Sie es testen, um sicherzustellen, dass sich angewendete Sicherheitskorrekturen nicht auf Ihre Arbeit auswirken, bis LTS veröffentlicht wird.
- Sobald die Version „Kandidat für Langzeitsupport“ zur Version „Langzeitsupport“ wird, erhält die Version „Langzeitsupport“ weiterhin alle zwei Wochen Sicherheitsupdates. Sie sollten sie auch testen.
Lebenszyklusdiagramm:
- Beginnen Sie mit dem Testen in Chrome 108 Dev und Chrome 108 Beta, um sicherzustellen, dass alles gut funktioniert, bevor Chrome 108 Stable veröffentlicht wird, aus dem Chrome 108 LTC abgeleitet wird.
- Teste alle zwei Wochen auf 108 LTC, bis 108 LTS drei Monate nach dem ursprünglichen Schnittdatum veröffentlicht wird.
- Führen Sie regelmäßig Tests auf LTS durch, um sicherzustellen, dass Sicherheitskorrekturen nichts beschädigen.
Änderungen zwischen LTC- und LTS-Versionen verwalten
Unabhängig davon, ob Sie eine LTS-Version von ChromeOS verwenden oder mit einer Organisation zusammenarbeiten, die dies tut, ist es wichtig, Änderungen zwischen den Versionen richtig zu verwalten. Sie können eine Funktion basierend auf neuen Plattformfunktionen hinzufügen oder sich auf eine Funktion verlassen, die in späteren Versionen eingestellt wurde. Vielleicht möchten Sie auch bestimmte Funktionen einer bestimmten Version einer App nutzen oder Nutzern die Möglichkeit geben, die Version auszuwählen, die sie verwenden möchten. Damit der Zugriff auf die Anwendung nahtlos funktioniert, sollten Sie dafür sorgen, dass Ihre App abwärtskompatibel ist, separate Instanzen pro Version bereitstellen oder beides.
Für Abwärtskompatibilität sorgen
Durch Abwärtskompatibilität können neuere Versionen Ihrer Anwendung auf älteren Versionen der Plattform ausgeführt werden. Dazu können Sie die sogenannte Funktionserkennung verwenden. Dabei wird geprüft, ob eine neue Funktion verfügbar ist, bevor versucht wird, sie zu nutzen. Wenn sie vorhanden ist, verwenden Sie sie. Andernfalls können Sie optional einen Fallback angeben. Die verallgemeinerte Version dieser Technik wird als Feature-Flags bezeichnet. Dabei wird ein Codepfad geladen, je nachdem, ob eine Funktion aktiviert ist. Dies kann durch die Verfügbarkeit von Funktionen oder durch die Konfiguration auf App- oder Nutzerebene erfolgen. Android-Apps, Chrome-Erweiterungen und Web-Apps profitieren alle von dieser Technik. Wenn Sie dafür sorgen, dass neuere Versionen Ihrer App abwärtskompatibel sind, können Sie eine einzelne Anwendung für alle Ihre Nutzer verwalten.
Eine Web-App, die rechenintensive Animationen bereitstellen möchte, kann WebGPU für Browser implementieren, die es unterstützen, und auf einfachere JavaScript-basierte Animationen zurückgreifen, wenn es nicht verfügbar ist. Dazu können sie Folgendes tun:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Separate Instanzen bereitstellen
Manchmal sind die Unterschiede zwischen den Versionen zu groß, um sie durch Techniken zur Abwärtskompatibilität zu bewältigen. Die Unterschiede zwischen den Funktionen sind möglicherweise zu groß oder Sie haben geschäftliche Anforderungen, die eine separate LTS-Version für Ihre Hauptanwendung erfordern. In diesem Fall sollten Sie für jede Version separate Instanzen bereitstellen. So wird zwar sichergestellt, dass Nutzer eine bestimmte Version Ihrer App verwenden, aber es kann auch zu höheren Betriebskosten führen. Berücksichtigen Sie dies, wenn Sie sich für diese Lösung entscheiden.
Bei Web-Apps bedeutet die Bereitstellung einer separaten Instanz in der Regel, dass die verschiedenen Versionen Ihrer Anwendung unter verschiedenen URLs gehostet werden. Dies erfordert möglicherweise separate Server, Datenbanken oder eine andere Websiteinfrastruktur. Für Android-Anwendungen bedeutet das, dass für jede Version ein separater Play Store-Eintrag vorhanden sein muss. Dies kann zu Verwirrung bei Ihren Nutzern führen, da mehrere ähnliche Anwendungen verfügbar sind und sie möglicherweise nicht wissen, welche sie auswählen sollen. Chrome-Erweiterungen können entweder auch mehrere Einträge haben oder Sie können Ihren Kunden empfehlen, die benötigte Version Ihrer Chrome-Erweiterung über die Chrome-Admin-Konsole anzupinnen. Verweisen Sie sie dazu auf diese Dokumentation, in der beschrieben wird, wie Erweiterungen angepinnt werden und welche Einschränkungen damit verbunden sind.
Wenn eine Android-App ChromeOS-Nutzern nur eine Version mit langfristigem Support zur Verfügung stellen möchte, kann sie einen separaten Eintrag mit dem folgenden Code in der Datei „AndroidManifest.xml“ erstellen, um anzugeben, dass die App nur auf ChromeOS-Geräten bereitgestellt werden soll:
<uses-feature android:name="org.chromium.arc" android:required="true" />