Il est essentiel de mettre à jour fréquemment votre système d'exploitation pour assurer la sécurité et accéder aux dernières fonctionnalités. Par défaut, ChromeOS publie une mise à jour complète de l'OS sur le canal stable (Stable) toutes les quatre semaines environ. Des mises à jour mineures (correctifs de sécurité et mises à jour logicielles, par exemple) ont lieu toutes les deux à trois semaines. Les développeurs peuvent tester leurs applications sur les canaux de développement (Dev) ou bêta (Beta) avant chaque nouvelle version stable, pour s'assurer qu'elles fonctionnent correctement. Elle est mise à jour une ou deux fois par semaine et montre sur quoi l'équipe Chrome travaille actuellement. Cette version peut encore contenir des bugs, mais elle permet de tester les nouveautés qui seront disponibles dans la version stable dans neuf à 12 semaines. La version bêta vous offre pendant quatre à six semaines un aperçu des fonctionnalités prévues pour la version stable.
Toutefois, les tests mensuels avec ces canaux existants peuvent être difficiles à suivre pour les administrateurs système et les développeurs. Pour mieux vous aider et vous donner plus de temps pour tester, nous avons créé un nouveau plan d'assistance à long terme pour ChromeOS, avec des canaux d'assistance à long terme.
Versions avec support à long terme
Les versions à assistance à long terme de ChromeOS sont un outil puissant qui permet de réduire l'effort nécessaire pour gérer les appareils d'une organisation et de s'assurer que les applications fonctionnent correctement pour chaque mise à jour de l'OS. Les administrateurs et les développeurs doivent se familiariser avec ces fonctionnalités pour offrir une expérience optimale aux organisations qui les adoptent.
ChromeOS propose deux versions à long terme : une version candidate à un support à long terme (LTC) et une version stable à long terme (LTS).
- Candidat à un support à long terme (LTC) : utilisé comme base pour la prochaine version LTS. Il est extrait de la version stable trois mois avant la version LTS, ce qui permet aux administrateurs de se préparer.
- Version avec support à long terme (LTS) : mise à jour tous les six mois, cette version a la fréquence de publication la plus lente et est destinée à remplacer la version stable normale. À l'exception de quelques utilisateurs qui doivent rester sur la version LTC à des fins de test, la plupart doivent utiliser la version LTS lors de l'adoption des versions à assistance à long terme dans une organisation.
Chronologie des versions stables, LTC et LTS
Le cycle de vie LTC / LTS fonctionne comme suit :
- La version LTC (108 LTC dans le diagramme) est issue de la version stable (108 Stable). Elles sont donc identiques le premier mois.
- La version LTC commence à recevoir des correctifs de sécurité toutes les deux semaines pendant les trois mois suivants, jusqu'à la prochaine version LTS (LTS 108 dans le diagramme). Cela signifie que trois mois après la publication initiale de la version LTC, celle-ci sera identique à la version LTS.
- Une fois la version LTS publiée, elle continuera de recevoir des correctifs de sécurité toutes les deux semaines.
- Les appareils qui restent à la version LTC après la sortie de la version LTS continueront également de recevoir des correctifs de sécurité toutes les deux semaines et seront automatiquement mis à jour vers la prochaine version LTC lorsqu'elle sera disponible.
En plus des fonctionnalités et des corrections de bugs du système d'exploitation, les mises à jour du micrologiciel sont également incluses dans les versions LTS jusqu'à la date d'expiration des mises à jour automatiques d'un appareil.
Pour activer l'un ou l'autre de ces canaux, vous devez disposer d'un domaine Google et d'un appareil géré. Vous pouvez vous inscrire à un essai de Chrome Enterprise Upgrade pour accéder à la console d'administration Google, qui vous permet de configurer et de déployer des Chromebooks gérés. Enfin, passez vos appareils gérés à la version LTS ou LTC depuis la console d'administration. Nous vous recommandons de laisser la majorité de vos appareils sur le canal LTS et d'utiliser LTC pour tester la prochaine version LTS.
Workflow de test pour LTC / LTS
Les canaux LTC et LTS sont conçus pour réduire considérablement les efforts de test des administrateurs, tout en garantissant une expérience sécurisée du système d'exploitation. Pour que les administrateurs système et les développeurs soient en phase avec le cycle de vie de l'assistance à long terme, vous devez :
- Testez les versions Dev et Bêta avant la sortie de la version stable correspondant à la prochaine version du canal LTC.
- Une fois LTC publié, testez-le pour vous assurer que les correctifs de sécurité appliqués n'affectent pas votre travail jusqu'à ce que LTS soit coupé.
- Une fois que la version LTC est promue en version LTS, celle-ci continue de recevoir des correctifs de sécurité toutes les deux semaines. Vous devriez également les tester.
En prenant le diagramme du cycle de vie comme référence :
- Commencez à tester les versions 108 en développement et bêta pour vous assurer que tout fonctionne correctement avant la sortie de la version stable 108, à partir de laquelle la version LTC 108 sera créée.
- Effectuez des tests sur 108 LTC toutes les deux semaines jusqu'à la sortie de 108 LTS, trois mois après la date de montage initiale.
- Continuez à effectuer des tests sur la version LTS régulièrement pour vous assurer que les correctifs de sécurité ne cassent rien.
Gérer les modifications entre les versions LTC/LTS
Que vous adoptiez une version à assistance à long terme de ChromeOS ou que vous travailliez avec une organisation qui l'a fait, il est essentiel de gérer correctement les changements entre les versions. Vous pouvez ajouter une fonctionnalité basée sur de nouvelles capacités de la plate-forme ou vous appuyer sur une fonctionnalité qui a été abandonnée dans les versions ultérieures. Vous pouvez également vous appuyer sur des fonctionnalités spécifiques d'une version spécifique d'une application ou vouloir offrir aux utilisateurs la possibilité de choisir la version qu'ils exécutent. Pour assurer un accès fluide aux applications, vous devez vous assurer que votre application est rétrocompatible, fournir des instances distinctes par version ou les deux.
Assurer la rétrocompatibilité
La rétrocompatibilité permet aux versions plus récentes de votre application de s'exécuter sur des versions plus anciennes de leur plate-forme. Pour ce faire, vous pouvez utiliser une technique appelée "détection de fonctionnalité", qui consiste à vérifier la disponibilité d'une nouvelle fonctionnalité avant d'essayer de l'utiliser. Si elle existe, utilisez-la. Sinon, fournissez éventuellement une solution de remplacement. La version généralisée de cette technique est appelée "feature flags" (indicateurs de fonctionnalité). Un chemin de code est chargé selon qu'une fonctionnalité est activée ou non, soit en fonction de la disponibilité d'une fonctionnalité, soit en fonction d'une configuration au niveau de l'application ou de l'utilisateur. Les applications Android, les extensions Chrome et les applications Web bénéficient toutes de cette technique. En vous assurant que les nouvelles versions de votre application sont rétrocompatibles, vous pouvez gérer une seule application pour tous vos utilisateurs.
Une application Web qui souhaite fournir des animations gourmandes en ressources de calcul peut implémenter WebGPU pour les navigateurs qui le prennent en charge et revenir à des animations plus simples alimentées par JavaScript si ce n'est pas le cas. Pour ce faire, ils peuvent procéder comme suit :
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Fournir des instances distinctes
Parfois, les différences entre les versions sont trop importantes pour être gérées par des techniques de rétrocompatibilité. Les différences entre les fonctionnalités peuvent être trop importantes ou vous pouvez avoir des besoins commerciaux qui nécessitent une version d'assistance à long terme distincte de votre application principale. Dans ce cas, vous pouvez envisager de fournir des instances distinctes pour chaque version. Bien que cela garantisse que les utilisateurs utilisent une version spécifique de votre application, cela peut augmenter vos coûts opérationnels. Gardez-le à l'esprit lorsque vous optez pour cette solution.
Pour les applications Web, fournir une instance distincte signifie généralement héberger les différentes versions de votre application à différentes URL, ce qui peut nécessiter des serveurs, des bases de données ou d'autres infrastructures de site Web distincts. Pour les applications Android, cela signifie avoir des fiches Play Store distinctes pour chaque version. Cela peut perturber vos utilisateurs, car plusieurs applications similaires seront disponibles et ils ne sauront pas laquelle choisir. Les extensions Chrome peuvent également avoir plusieurs fiches. Vous pouvez aussi recommander à vos clients d'épingler la version de votre extension Chrome dont ils ont besoin dans la console d'administration Chrome en leur fournissant cette documentation, qui explique comment épingler des extensions et certaines mises en garde associées à l'épinglage.
Une application Android qui ne souhaite fournir qu'une version à assistance à long terme aux utilisateurs de ChromeOS peut créer une fiche distincte avec les éléments suivants dans son fichier AndroidManifest.xml pour spécifier qu'elle ne doit être distribuée qu'aux appareils ChromeOS :
<uses-feature android:name="org.chromium.arc" android:required="true" />