Quelles sont les différences entre Bazel et Gradle?
Google vient de open-sourced son outil de construction Bazel . Quelles sont les différences entre cet outil et Gradle ? Que peut-il faire que Gradle ne puisse pas, que fait-il mieux et que fait-il mieux?
Avertissement: je travaille sur Bazel et je ne connais pas très bien Gradle. Cependant, un de mes collègues a écrit une comparaison des deux systèmes, que je vais paraphraser ici:
Bazel et Gradle mettent l'accent sur différents aspects de l'expérience de construction. Dans une certaine mesure, leurs priorités sont incompatibles - le désir de Gradle de flexibilité et de non-obstruction limite les restrictions qu’il peut imposer à la structure de construction, tandis que le désir de Bazel de fiabilité et de performance impose nécessairement des restrictions non négociables.
Gradle valorise les mêmes principes que Bazel, c’est-à-dire que l’équipe Gradle accorde une grande attention aux performances (constructions incrémentielles, configuration et exécution parallélisées, démon Gradle), à la correction (vérification "à jour" basée sur le contenu) et à la reproductibilité. (support riche pour la syntaxe déclarative, gestion des versions de dépendance, dépendances déclarées explicitement). Et Bazel respecte la nécessité de disposer de projets flexibles.
La nuance est que Gradle veut promouvoir les bonnes pratiques alors que Bazel veut les exiger. Gradle vise un compromis entre l'expérience Ant (liberté de définir votre propre structure de projet avec des résultats incohérents) et l'expérience Maven (meilleures pratiques appliquées sans possibilité de varier les besoins du projet). Bazel estime qu'un support de projet flexible est possible sans sacrifier les fortes garanties qui permettent son flux de travail puissant.
Aucune de ces deux conceptions n’est plus "correcte". L’outil qui convient le mieux à un projet dépend des valeurs de celui-ci.
Gradle Vue d'ensemble
Gradle est un système très flexible qui permet aux utilisateurs de créer facilement des flux de construction complets et fiables avec des contraintes minimales quant à la manière dont ils organisent leurs projets. Pour ce faire, il fournit de puissants blocs de construction (par exemple, le suivi et la récupération automatiques des dépendances, un support de plug-in parfaitement intégré) avec une interface de script générique, complète de Turing, capable de combiner ces blocs à la demande des utilisateurs.
Gradle met l'accent sur les caractéristiques suivantes:
- Migration facile depuis d’autres systèmes. Gradle s’adapte facilement à toute organisation de projet afin de mettre en œuvre facilement des structures de flux de travail arbitraires. Il comprend nativement les tâches Ant et s’intègre nativement aux référentiels Maven et Ivy.
- Modèle de script hautement extensible. Les utilisateurs implémentent toute la logique de construction en écrivant des scripts Groovy. Une "construction" est simplement une exécution séquencée par dépendance de tâches génériques, qui sont essentiellement des définitions de méthodes extensibles, ouvertes et non terminées.
- Gestion des dépendances riches. Les dépendances versionnées peuvent être déclarées et automatiquement mises en scène à partir de référentiels de code externes, de systèmes de fichiers locaux et d'autres projets Gradle. Les sorties de construction peuvent également être publiées automatiquement dans des référentiels et d’autres emplacements.
- Système de plugins étroitement intégré. Les plugins sont simplement des lots de tâches organisées pour faciliter le flux de travail souhaité. La plupart des fonctionnalités "fondamentales" de Gradle sont en réalité mises en œuvre via des plug-ins (par exemple, Java, Android). Les plugins interagissent (à leur discrétion) étroitement avec la logique de script de construction. Les plugins bénéficient d’un accès approfondi aux structures de données de base de Gradle.
Présentation de Bazel
Bazel est né de la nécessité de construire des projets Google internes de manière fiable et efficace. Étant donné que l’environnement de développement de Google est exceptionnellement volumineux et complexe, Bazel offre des garanties exceptionnellement solides quant à l’intégrité de ses versions et une charge de performance inhabituellement faible.
Cela fournit une base pour des flux de travail de développement puissants construits autour de générations reproductibles, où une "génération" devient une entité abstraite pouvant être référencée, répétée, transmise à différentes machines et transmise à des programmes et services arbitraires de sorte que chaque instance soit connue pour être connue. exactement le même.
Bazel met l'accent sur les caractéristiques suivantes:
- Correctness. Les builds Bazel sont conçus pour toujours produire une sortie correcte, point à la ligne. Si deux utilisateurs invoquent la même construction lors du même commit avec les mêmes indicateurs Bazel sur des machines différentes, ils obtiendront des résultats identiques. Les builds incrémentaux sont aussi fiables que les builds propres, rendant ce dernier inutile.
- Performance. Les builds sont conçus pour s'exécuter aussi rapidement que possible en fonction des ressources dont ils disposent. Les tâches sont aussi parallélisables que leurs chaînes de dépendance le permettent. Les tâches inutiles ne sont jamais exécutées (c’est-à-dire que les tâches "à jour" sont toujours ignorées). Le travail peut naturellement être confié à des exécutants distants pour dépasser les limites de la machine locale.
- Reproductibilité. Toute instance de build peut être reproduite fidèlement dans n'importe quel environnement. Par exemple, si un rapport de bogue indique que la version X du logiciel Y échoue dans un environnement de production Z, un développeur peut le recréer fidèlement sur son propre ordinateur en ayant la certitude qu’il est en train de déboguer la même chose.
Alors que les liens entre articles ont tendance à disparaître, voici un résumé de le point de vue de l'équipe de Gradle sur Bazel (la plupart sont directement extraits de l'article paru en mars 2015):
Il a été conçu pour résoudre un problème propre à Google. une base de code monolithique massive (des centaines de millions de LOC).
L'avantage actuel de Bazel en matière de parallélisation sera assorti de "notre nouveau modèle de configuration et de composants à venir" (n'oubliez pas la date de l'article ici).
Bazel ne dispose pas d'un langage de construction déclaratif de haut niveau qui facilite son utilisation par les développeurs. Chez Google, cela peut être compensé par une équipe de service spécialisée qui possède l'outil de construction.
Bazel n’est pas conçu pour l’extensibilité (bien que l’équipe de développement de Bazel ait répondu à cela en assurant qu’elle travaille sur l’extensibilité).
La vitesse est optimisée en partant du principe que toutes les dépendances transitives sont stockées dans un grand dépôt. toutes les bibliothèques et tous les outils sont archivés dans ce référentiel central. La plupart des entreprises ont davantage d'exigences en matière de gestion de la dépendance distribuée.
Bazel est * nix seulement, il ne fonctionne pas sous Windows. Cela élimine un grand nombre d'entreprises potentielles.
Aucun écosystème de plugin.