Las actualizaciones frecuentes del sistema operativo son fundamentales para garantizar la seguridad y el acceso a las funciones más recientes. De forma predeterminada, ChromeOS lanza una actualización completa del SO en el canal estable (Stable) aproximadamente cada 4 semanas. Las actualizaciones menores, como las correcciones de seguridad y actualizaciones de software, se realizan cada 2 o 3 semanas. Los desarrolladores pueden probar sus aplicaciones en los canales para desarrolladores (Dev) o beta (Beta) antes de que se lance cada nueva versión estable para asegurarse de que sus apps funcionen correctamente. Se actualiza una o dos veces por semana y muestra en qué está trabajando el equipo de Chrome en este momento. Esta compilación aún está sujeta a errores, pero ofrece una vista previa de 9 a 12 semanas de lo que se lanzará en la versión estable. La versión beta te ofrece una vista previa de entre 4 y 6 semanas de las funciones que se incluirán en la versión estable.
Sin embargo, para los administradores de sistemas y los desarrolladores, puede ser difícil mantenerse al día con las pruebas mensuales en estos canales existentes. Para brindar una mejor asistencia y darles a todos más tiempo para realizar pruebas, creamos un nuevo plan de asistencia a largo plazo para ChromeOS, con canales de asistencia a largo plazo.
Versiones con asistencia a largo plazo
Las versiones de asistencia a largo plazo de ChromeOS son una herramienta poderosa para reducir el esfuerzo necesario para administrar dispositivos en una organización y certificar que las apps funcionan bien con cada actualización del SO. Tanto los administradores como los desarrolladores deben familiarizarse con ellas para brindar una excelente experiencia a las organizaciones que las adopten.
ChromeOS ofrece dos versiones de asistencia a largo plazo: una versión de candidato para asistencia a largo plazo (LTC) y una versión estable a largo plazo (LTS).
- Candidato para asistencia a largo plazo (LTC): Se usa como base para la próxima versión de LTS y se extrae de la versión estable tres meses antes de la versión de LTS, lo que les brinda a los administradores una vista previa para prepararse.
- Canal de asistencia a largo plazo (LTS): Se actualiza cada 6 meses, tiene la cadencia de lanzamiento más lenta y está diseñado para reemplazar el canal estable normal. Excepto por algunos usuarios que deben permanecer en LTC para realizar pruebas, la mayoría debe estar en LTS cuando se adopten versiones de asistencia a largo plazo en toda la organización.
Cronograma de versiones estables, LTC y LTS
El ciclo de vida de LTC / LTS funciona de la siguiente manera:
- La versión de LTC (108 LTC en el diagrama) se extrae de la versión estable (108 Stable), por lo que, durante el primer mes, ambas son idénticas.
- El canal de LTC comienza a recibir correcciones de seguridad cada dos semanas durante los próximos 3 meses hasta el próximo lanzamiento de LTS (LTS 108 en el diagrama). Esto significa que, 3 meses después del lanzamiento inicial del canal de LTC, este reflejará el canal de LTS.
- Una vez que se lance la versión de LTS, seguirá recibiendo correcciones de seguridad cada dos semanas.
- Los dispositivos que se dejen en el canal de LTC después del lanzamiento de LTS también seguirán recibiendo correcciones de seguridad cada dos semanas y se actualizarán automáticamente a la próxima versión de LTC cuando se lance.
Además de las funciones del sistema operativo y las correcciones de errores, las actualizaciones de firmware también se incluyen en las versiones de LTS hasta el vencimiento de la actualización automática (AUE) de un dispositivo.
Para habilitar cualquiera de los canales, debes tener un dominio de Google y un dispositivo administrado. Puedes registrarte para obtener una prueba de Chrome Enterprise Upgrade y acceder a la Consola del administrador de Google, que te permite configurar y implementar Chromebooks administradas. Por último, cambia tus dispositivos administrados al canal de LTS o LTC desde la Consola del administrador. Te recomendamos que la mayoría de tus dispositivos permanezcan en el canal de LTS y que uses el canal de LTC para probar la próxima versión de LTS.
Flujo de trabajo de prueba para LTC / LTS
Las versiones LTC y LTS están diseñadas para reducir considerablemente los esfuerzos de prueba de los administradores y, al mismo tiempo, garantizar una experiencia segura del sistema operativo. Para mantener a los administradores del sistema y a los desarrolladores en sintonía con el ciclo de vida de la asistencia a largo plazo, debes hacer lo siguiente:
- Realiza pruebas en los canales Beta y para desarrolladores antes del lanzamiento de la versión estable que coincida con el próximo lanzamiento del canal de LTC.
- Una vez que se lance la versión LTC, realízale pruebas para asegurarte de que las correcciones de seguridad aplicadas no afecten tu trabajo hasta que se lance la versión LTS.
- Una vez que LTC se promocione a LTS, LTS seguirá recibiendo correcciones de seguridad cada dos semanas. También deberías probarlos.
Si tomamos el diagrama de ciclo de vida como referencia, tenemos lo siguiente:
- Comienza las pruebas en las versiones 108 de Dev y Beta para asegurarte de que todo funcione bien antes del lanzamiento de la versión 108 Estable, a partir de la cual se creará la versión 108 de LTC.
- Realiza pruebas en 108 LTC cada dos semanas hasta que se lance 108 LTS tres meses después de la fecha de corte inicial.
- Sigue realizando pruebas en la versión LTS con regularidad para asegurarte de que las correcciones de seguridad no interrumpan nada.
Administra los cambios entre las versiones de LTC y LTS
Ya sea que adoptes una versión de ChromeOS con asistencia a largo plazo o trabajes con una organización que lo haya hecho, es fundamental administrar correctamente los cambios entre versiones. Puedes agregar una función basada en las nuevas capacidades de la plataforma o usar una que se haya dejado de usar en versiones posteriores. También puedes depender de funciones específicas de una versión específica de una app o querer ofrecer a los usuarios la capacidad de elegir qué versión ejecutar. Para garantizar un acceso sin problemas a la aplicación, debes asegurarte de que sea compatible con versiones anteriores, proporcionar instancias separadas por versión o ambas opciones.
Garantiza la retrocompatibilidad
La retrocompatibilidad permite que las versiones más recientes de tu aplicación se ejecuten en versiones anteriores de la plataforma. Puedes hacerlo con una técnica llamada detección de funciones, en la que verificas la disponibilidad de una función nueva antes de intentar usarla. Si existe, úsalo; si no, proporciona una alternativa de forma opcional. La versión generalizada de esta técnica se denomina marcas de funciones, en la que se carga una ruta de código según si una función está habilitada, ya sea a través de la disponibilidad de la capacidad o la configuración a nivel del usuario o de la app. Las apps para Android, las extensiones de Chrome y las apps web se benefician de esta técnica. Si te aseguras de que las versiones más recientes de tu app sean retrocompatibles, podrás administrar una sola aplicación para todos tus usuarios.
Una app web que busca proporcionar animaciones que requieren mucha capacidad de procesamiento puede implementar WebGPU para los navegadores que lo admiten y recurrir a animaciones más simples basadas en JavaScript si no está disponible. Para ello, pueden hacer lo siguiente:
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
Proporciona instancias separadas
A veces, las diferencias entre las versiones son demasiado grandes para manejarlas con técnicas de retrocompatibilidad. Las diferencias entre las funciones pueden ser demasiado grandes, o bien es posible que tengas necesidades comerciales que exijan una versión de asistencia a largo plazo independiente de tu aplicación principal. En ese caso, te recomendamos que proporciones instancias separadas para cada versión. Si bien esto garantiza que los usuarios utilicen una versión específica de tu app, puede aumentar tus costos operativos, por lo que debes tenerlo en cuenta cuando optes por esta solución.
En el caso de las apps web, proporcionar una instancia separada suele significar alojar las diferentes versiones de tu aplicación en URLs diferentes, lo que podría requerir servidores, bases de datos o infraestructura de sitios web independientes. En el caso de las aplicaciones para Android, esto significa tener fichas separadas de Play Store para cada versión. Esto puede confundir a los usuarios, ya que habrá varias aplicaciones similares disponibles y es posible que no sepan cuál elegir. Las extensiones de Chrome también pueden tener varias fichas, o bien puedes recomendar a tus clientes que fijen la versión de tu extensión de Chrome que necesiten a través de la Consola del administrador de Chrome. Para ello, remítelos a esta documentación, en la que se detalla cómo fijar extensiones y algunas advertencias asociadas a la fijación.
Una app para Android que solo quiera proporcionar una versión de asistencia a largo plazo para los usuarios de ChromeOS puede crear una ficha separada con lo siguiente en su archivo AndroidManifest.xml para especificar que solo se debe entregar a dispositivos ChromeOS:
<uses-feature android:name="org.chromium.arc" android:required="true" />