Développé par Google, Bazel est un outil permettant l'automatisation des builds et des tests logiciels. Il s'agit en réalité d'une version open source de l’outil de build Blaze utilisé en interne par Google. Bazel (anagramme de Blaze) a été publié en 2015 par Google et n’était alors disponible que pour les environnements Linux et macOS. Il a apporté beaucoup de souplesse dans les opérations de build des logiciels Google. Depuis, Google s’est efforcé de le rendre disponible également pour les utilisateurs Windows.Bazel utilise un langage de construction de haut niveau, prend en charge des projets écrits dans plusieurs langages (Java, Go, C++, Python, Objective-C, etc.) et crée des sorties pour plusieurs plateformes. Les règles et les macros sont créées dans le langage Starlark (anciennement appelé Skylark), issu de Python. Bazel peut produire des packages d'applications logicielles adaptés au déploiement pour les systèmes d'exploitation Android et iOS. Voici les principaux avantages que Google cite pour son outil :
- langage de construction de haut niveau : Bazel utilise un langage abstrait et lisible par l'homme pour décrire les propriétés de construction de votre projet à un niveau sémantique élevé. Contrairement à d'autres outils, Bazel fonctionne sur les concepts de bibliothèques, de binaires, de scripts et d'ensembles de données, vous protégeant de la complexité de l'écriture d'appels individuels vers des outils tels que des compilateurs et des linkers (éditeurs de liens) ;
- Bazel est rapide et fiable : Bazel met en cache tout le travail effectué précédemment et suit les modifications apportées au contenu des fichiers et aux commandes de compilation. De cette façon, Bazel sait quand quelque chose doit être reconstruit, et ne reconstruit que cela. Pour accélérer encore plus vos constructions, vous pouvez mettre en place votre projet pour construire de manière parallèle et incrémentale ;
- Bazel est un outil multiplateforme : Bazel fonctionne sous Linux, macOS et Windows. Il peut construire des binaires et des packages déployables pour plusieurs plateformes, aussi bien desktop, serveur que mobile, à partir du même projet ;
- Bazel est extensible : il supporte de nombreux langages, mais vous pouvez aussi étendre Bazel pour supporter tout autre langage ou framework.
La première version stable de Bazel introduit trois caractéristiques importantes pour l’outil, notamment au niveau du versioning, des supports à long terme (LTS), ainsi que quelques améliorations au niveau des langages pris en charge. À partir de Bazel v1.0.0, Google utilisera le versioning sémantique pour toutes les versions de Bazel. Par exemple, toutes les versions 1.x seront rétrocompatibles avec Bazel v1.0.0. Il y aura une fenêtre d’au moins trois mois entre les sorties majeures. Google publiera aussi des versions mineures de Bazel tous les mois, en coupant dans GitHub HEAD.
D’après Google, les versions LTS (Long-Term Support) donnent aux utilisateurs l'assurance que l'équipe Bazel a la capacité et le processus nécessaires pour fournir rapidement et en toute sécurité des correctifs pour les bogues critiques, y compris les vulnérabilités. Bazel v1.0.0 apporte des fonctionnalités complètes pour Angular, Android, Java et C. Elles comprennent la prise en charge de bout en bout de l'exécution à distance et de la mise en cache, ainsi que la prise en charge des gestionnaires de paquets standard et des dépendances tierces. En détail, les fonctionnalités les plus remarquables concernent le système d’exploitation Windows, l’exécution, la configuration, Android, C++ et Java. Voici de quoi il s’agit dans cette version 1.0.0 :
Windows
- genrule supporte maintenant les attributs cmd_bash, cmd_ps et cmd_bat pour une meilleure intégration sous Windows ;
- C++ : vous pouvez maintenant obtenir un fichier DEF généré à partir du groupe de sortie def_file de cc_library ;
- MSYS2/Bash : les cibles de test ("bazel test//foo"
, les cibles binaires ("bazel run //bar", et les règles de récupération du référentiel ne nécessitent plus MSYS2.
Exécution
- définissez l'option --experimental_allow_tags_propagation pour propager les balises aux exigences d'exécution de l'action à partir des cibles. De telles balises devraient commencer par : no-, requires-, supports-, block-, disable-, cpu ;
- toutes les règles ont maintenant un attribut exec_properties par défaut comme celui d'une règle de plateforme ;
- toutes les connexions gRPC de Bazel sont activées par défaut en TLS. Pour désactiver TLS, utilisez le schéma grpc:// dans vos URI. Les drapeaux affectés le sont : --remote_cache, --remote_executor et --bes_backend.
Configuration
- config_setting peut maintenant vérifier plusieurs valeurs sur les drapeaux de style --foo=firstVal, --foo=secondVal, ... ;
- bazelrc spécifique à la plateforme que vous utilisez : avec --enable_platform_specific_config vous pouvez activer des drapeaux dans bazelrc en fonction de votre plateforme hôte.
Android
- aapt2 est maintenant activé par défaut. Pour revenir à aapt, activez l'option --android_aapt=aapt ;
- correction de problèmes de chemin d'accès Windows avec aapt2.
C++
- les règles cc_* supportent les définitions non transitoires via un attribut local_defines ;
- Bazel supporte maintenant ThinLTO builds sur Linux pour Clang versions 6.0 ou supérieures. ThinLTO peut être activé par --features=thin_lto.
Java
- l'API Java-Starlark dépréciée java_common.create_provider est supprimée. D’autres suppressions ont eu lieu également ;
- maven_jar et maven_server interdisent maintenant l'utilisation d'URL HTTP simples sans somme de contrôle spécifique. Si vous utilisez toujours maven_jar, pensez à migrer vers rules_jvm_external pour la gestion des dépendances transitives ;
- ajout des attributs sha256 et sha256_src dans maven_jar. Veuillez envisager de migrer vers SHA-256, car SHA-1 a été jugé non sécurisé sur le plan cryptographique. Ou, utilisez rules_jvm_external pour gérer vos dépendances transitives de Maven avec l'épinglage d'artefacts et le support de vérification SHA-256.
Évaluation de Bazel pour le système de build de Firefox
Dans un billet de blog sur la plateforme de Mozilla, un ingénieur s'est demandé si Firefox devrait passer à Bazel pour son système de build.
La motivation derrière le changement de système de build était double. La première motivation était que les temps de build constituaient l'un des aspects les plus visibles du système de build destiné aux développeurs et que tout le monde appréciait les builds plus rapides. Ce qui est moins évident, mais tout aussi important, c’est que la création plus rapide améliore l’automatisation : moins de temps à attendre pour les essais, plus de flexibilité pour ajuster les dépenses d’infrastructure et moins de temps d’exécution avec les révisions automatisées des correctifs soumis pour révision.
« La deuxième motivation était que notre système de build est utilisé par exactement un projet (OK, deux projets), il y a donc beaucoup de coûts d'intégration, à la fois pour les développeurs qui utilisent le système de build et pour les développeurs qui ont besoin de développer le système de build. Si nous pouvions passer à quelque chose de plus commercial, nous pourrions améliorer l'expérience d'intégration et tirer parti du travail que d'autres parties effectuent avec le système de build que nous avons choisi ».
Il indique que Mozilla a examiné d’autres candidats, précisant qu'aucun n’était aussi profond que Bazel, et est parvenu à la conclusion que tous ont des problèmes divers qui les rendent impropres à un échange. Les raisons pour lesquelles d’autres possibilités ont été rejetées relèvent de deux grandes catégories :
- le support de la plateforme est insuffisant
- il est peu probable que les builds soient plus rapides et/ou améliorent l’expérience d’intégration / développement.
Pourquoi Mozilla a choisi Bazel ?
« Bazel se présente avec le slogan "{Fast, Correct} - Choose two". Ce qui est à l’origine de ce slogan, c’est que lorsqu’on génère un logiciel avec, par exemple Make, il est très facile d’écrire des Makefiles de manière à ce que les compilations soient rapides, mais qu’il arrive parfois (ou pas si rarement) d’échouer, car quelqu'un a oublié de spécifier "pour faire une build de X, vous devez avoir fait une build de Y”. La génération n'échoue généralement pas, car Y est généré avant X : peut-être que l'algorithme de planification pour une exécution parallèle dans Make choisit de générer Y en premier 99,9 % du temps, et 99 % des fois, la génération de Y se termine avant même de démarrer la génération de X.
« Bazel se vante de proposer un moyen de se sortir du bourbier des spécifications pour les builds de votre logiciel. C’est ce qu’il fait, du moins dans la mesure où je comprends les choses, et je suis sûr que l’Internet viendra me corriger si je me trompe, en vous demandant de spécifier explicitement les dépendances au préalable. L'exactitude des commandes de build peut ensuite être vérifiée en les exécutant dans un "bac à sable" contenant uniquement les fichiers spécifiés en tant que dépendances : si vous avez oublié de spécifier quelque chose qui était réellement nécessaire, la build échouera, car le ou les fichiers en question ne sont pas disponibles.
« Avoir une image complète du graphe de dépendance permet des builds plus rapides de trois manières différentes. La première est que vous pouvez paralléliser au maximum le travail dans la build. La seconde est que Bazel est livré avec des installations intégrées permettant d’assumer des tâches de buiild sur des machines distantes. Notez que toutes les tâches de build peuvent être distribuées, pas seulement la compilation C / C ++ / Rust comme via sccache. Ainsi, même si vous n’avez pas une machine de développement particulièrement puissante, vous pouvez toujours prétendre que vous disposez d’un grand système multicœur. La troisième est que Bazel est également livré avec des installations intégrées pour la mise en cache agressive d'artefacts de build. Encore une fois, comme pour l'exécution à distance, cette mise en cache s'applique à toutes les tâches de build, pas seulement à la compilation C / C ++ / Rust. En termes de développement de Firefox, il s'agit de build d'artefacts Firefox effectuées "correctement" : avec une configuration appropriée, votre build locale téléchargerait simplement ce qui était approprié pour les modifications dans votre arborescence locale actuelle et reconstruirait le reste.
« Avoir une image complète du graphe de dépendance active un certain nombre d'autres fonctionnalités intéressantes. Bazel est livré avec un langage de requête pour le graphe de dépendance, ce qui vous permet de poser des questions telles que "quels travaux doivent être exécutés étant donné que ces fichiers ont été modifiés ?" Ce type de requête serait très utile pour déterminer les travaux à exécuter en automatisation; nous en avons une version (mise à jour manuellement) dans des éléments tels que les fichiers modifiés dans les spécifications de travail Taskcluster. Mais des choses comme "exécuter les tests $OS pour les modifications de $ OS uniquement" deviennent faciles »
Source : Mozilla
Et vous ?
Que pensez-vous de Bazel ? Que pensez-vous de la perspective de Mozilla vis-à-vis de cet outil ? 
