Si vous regardez autour des bureaux de Google à Mountain View, en Californie, vous verrez des machines Windows, des Chromebooks, des Mac et des ordinateurs de bureau gLinux. G quoi, vous demandez-vous ? Eh bien, en plus de s'appuyer sur Linux pour ses serveurs, Google possède en fait sa propre distribution de bureau Linux. Mais impossible - bon sang! - de la télécharger depuis plus d'une décennie. Au départ, elle a été dénommée Goobuntu, non sans cacher un lien de parenté avec la célèbre distro Ubuntu. Mais en 2018, la firme américaine a a fait évolué son développement vers une autre distribution Linux, nommée gLinux, cette fois-ci basée sur Debian. Pourquoi ? Google a expliqué que recourir à la version LTS de Goobuntu signifiait de mettre à niveau chaque système de sa flotte, soit plus de 100 000 terminaux, avant la date de fin de vie de l'OS. Un chantier titanesque. Ajoutez à cela la nécessité fastidieuse de personnaliser entièrement les PC des ingénieurs, et Google a décidé que cela coûtait trop cher. En outre, l'effort de mise à niveau de la flotte de terminaux vers Goobuntu aurait pris une bonne partie de l'année, soit autant de temps mordu sur un support étalé sur deux ans avant de devoir recommencer le même processus pour une prochaine version LTS.

« L'ensemble de ce processus a été un énorme facteur de stress pour notre équipe, car nous avons reçu des centaines de bogues avec des demandes d'aide pour des cas critiques », a expliqué Google qui en a eu assez et a donc basculé sur Debian Linux. La société a alors créé une distribution Debian en développement continu : GLinux Rolling Debian Testing (Rodete). L'idée ? Que les utilisateurs et les développeurs profitent de dernières mises à jour et correctifs au fur et à mesure de leur création et jugés prêts pour la mise en production. Ces distributions incluent Arch Linux, Debian Testing et openSUSE Tumbleweed. Pour Google, l'objectif immédiat était de sortir du cycle de mise à niveau de deux ans. Comme l'a montré le passage à l'intégration continue/déploiement continu (CI/CD), ces changements progressifs fonctionnent bien. Ils sont également plus faciles à contrôler et à annuler en cas de problème.

Une automatisation complète dans le pipeline qui change la vie

Pour que tout cela fonctionne sans beaucoup de sang, de sueur et de larmes, Google a créé un système de workflow, Sieve. Chaque fois que Sieve repère une dernière version d'un paquet Debian, il démarre une build. Ces packages sont intégrés dans des groupes de packages et une fois qu'ils ont été créés, Google exécute une suite de tests virtualisés pour s'assurer qu'aucun composant principal et aucun flux de travail de développeur ne sont rompus. Ensuite, chaque groupe est testé séparément avec une installation complète du système, un démarrage et une exécution de la suite de tests locaux. Le package se construit en quelques minutes, mais les tests peuvent prendre jusqu'à une heure. Une fois cela fait, tous les packages sont fusionnés avec le dernier pool de packages gLinux. Ensuite, lorsque l'éditeur décide qu'il est temps de le mettre en production, l'équipe prend alors un snapshot de ce pool avant déploiement et utilise les principes « d'ingénierie de fiabilité » (SRE) tels que le canarying incrémental pour s'assurer que rien ne tourne mal.

Aujourd'hui, grâce à Sieve, le développement gLinux se résume à un seul poste d'ingénieur de publication qui tourne entre les membres de l'équipe. Il n'y a pas de gros efforts de modernisation à fournir. Pas de versions alpha, bêta et de disponibilité générale (GA) en plusieurs étapes à gérer. Mieux encore, grâce au calendrier de publication glissant, Google peut rapidement corriger les failles de sécurité sur l'ensemble de la flotte sans compromettre la stabilité. Auparavant, les ingénieurs en sécurité devaient examiner attentivement chaque avis de sécurité Debian (DSA) pour s'assurer que le correctif était présent. En outre, « la suite de tests améliorée de Google et les tests d'intégration avec des équipes partenaires clés qui exécutent des systèmes de développement critiques ont également donné une expérience plus stable en utilisant une distribution Linux qui fournit les dernières versions du noyau Linux. Notre fort désir de tout automatiser dans le pipeline a réduit considérablement le labeur et le stress au sein de l'équipe. Il nous est désormais également possible de signaler des bogues et des incompatibilités avec d'autres versions de la bibliothèque tout en nous assurant que les outils Google fonctionnent mieux au sein de l'écosystème Linux », explique l'éditeur.

Une distro publique attendue mais pour l'instant en rêve

Pour le futur, l'équipe de Google a déclaré qu'elle travaillera plus étroitement avec Debian en amont et contribuera davantage à ses correctifs internes pour maintenir l'écosystème de ses paquets. Tout cela sonne bien mais amène à formuler deux remarques. Premièrement, pour certaines organisations, les versions LTS ont toujours un sens. Vous n'avez pas besoin des programmes les plus récents et les plus brillants pour votre entreprise ? Alors un Linux Ubuntu ou Red Hat LTS a toujours du sens. Ensuite, et c'est le plus important : Sieve sonne comme un cri de rassemblement. Qui ne veut pas d'un programme qui peut automatiser un pipeline de production de distribution en continu au point de ne nécessiter qu'un seul ingénieur pour le maintenir sur plus de 100 000 postes ? Personne... Alors qu'attend Google pour publier le code de Sieve afin de commencer à produire des versions de bureau Linux en continu ? Allez, encore un petit effort.