Avertissement: je travaille sur Bazel et je ne connais pas intimement Gradle. Cependant, un de mes collègues a rédigé une comparaison des deux systèmes, que je paraphraserai 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 flexibilité et de non-intrusion de Gradle limite les restrictions qu'il peut imposer à la structure de construction, tandis que le désir de fiabilité et de performance de Bazel 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 (builds incrémentiels, configuration et exécution parallélisées, le démon Gradle), à l'exactitude (vérification «à jour» basée sur le contenu) et à la reproductibilité (prise en charge riche de la syntaxe déclarative, du contrôle de version des dépendances, des dépendances explicitement déclarées). Et Bazel respecte le besoin de dispositions de projet flexibles.
La nuance est que Gradle veut promouvoir les bonnes pratiques tandis que Bazel veut l'exiger. Gradle vise un terrain d'entente 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 faire varier les besoins du projet). Bazel pense qu'une prise en charge flexible des projets est possible sans sacrifier les solides garanties qui permettent ses puissants flux de travail.
Aucune des deux philosophies n'est plus «correcte» - l'outil qui convient le mieux à un projet dépend des valeurs de ce projet particulier.
Présentation de Gradle
Gradle est un système hautement flexible qui permet aux utilisateurs de créer facilement des flux de construction complets et fiables avec des contraintes minimales sur la façon dont ils organisent leurs projets. Il le fait en fournissant des blocs de construction puissants (par exemple, le suivi et la récupération automatiques des dépendances, la prise en charge des plugins étroitement intégrés) avec une interface de script générique, Turing-complète, qui peut combiner ces blocs comme les utilisateurs le souhaitent.
Gradle met l'accent sur les caractéristiques suivantes:
- Migration facile depuis d'autres systèmes. Gradle s'adapte facilement à toute organisation de projet pour implémenter 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 de dépendances de tâches génériques, qui sont essentiellement des définitions de méthodes ouvertes, remplaçables et extensibles.
- Gestion des dépendances riche. Les dépendances versionnées peuvent être déclarées et automatiquement préparées à 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 les référentiels et autres emplacements.
- Système de plugins étroitement intégré. Les plugins sont simplement des ensembles de tâches organisées pour faciliter le flux de travail souhaité. De nombreuses fonctionnalités "de base" de Gradle sont en fait implémentées via des plugins (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 profond aux structures de données de base de Gradle.
Présentation de Bazel
Bazel est né de la nécessité de créer des projets Google internes de manière fiable et efficace. Étant donné que l'environnement de développement de Google est inhabituellement vaste et complexe, Bazel offre des garanties exceptionnellement solides sur l'intégrité de ses versions et une surcharge de performances inhabituellement faible pour les atteindre.
Cela fournit une base pour des workflows de développement puissants construits autour de builds reproductibles, où une "build" devient une entité abstraite qui peut ê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 exactement le même.
Bazel met l'accent sur les caractéristiques suivantes:
- Exactitude. Les builds Bazel sont conçus pour toujours produire une sortie correcte, point final. Si deux utilisateurs invoquent la même compilation au même commit avec les mêmes indicateurs Bazel sur des machines différentes, ils verront des résultats identiques. Les builds incrémentiels sont aussi fiables que les builds propres, ce qui rend ces derniers pratiquement inutiles.
- Performance. Les builds sont conçus pour s'exécuter aussi rapidement que possible, compte tenu des ressources dont ils disposent. Les tâches sont aussi parallélisables que le permettent leurs chaînes de dépendances. Le travail inutile n'est jamais exécuté (c'est-à-dire que les tâches «à jour» sont toujours ignorées). Le travail peut naturellement être confié à des exécuteurs distants pour surmonter les limites des machines locales.
- Reproductibilité. Toute instance d'une construction peut être fidèlement reproduite dans n'importe quel environnement. Par exemple, si un rapport de bogue indique que la version X du logiciel Y échoue dans l'environnement de production Z, un développeur peut le recréer fidèlement sur sa propre machine en sachant qu'il débogue la même chose.
Alors que les liens d'articles ont tendance à mourir, voici un résumé des opinions de l'équipe Gradle sur Bazel (la plupart sont directement tirées de l'article, qui a été publié 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 de parallélisation que Bazel offre actuellement sera égalé par "notre nouvelle configuration et modèle de composants à venir" (gardez à l'esprit la date de l'article ici).
Bazel n'a pas de langage de construction déclaratif de haut niveau qui rend la construction facile à utiliser pour les développeurs. Chez Google, cela peut être compensé par une équipe de service spécialisée qui possède l'outil de création.
Bazel n'est pas conçu pour l'extensibilité (bien que l'équipe de développement de Bazel ait depuis contré cela en garantissant qu'elle travaille sur l'extensibilité).
La vitesse est optimisée autour de l'idée que toutes les dépendances transitives sont stockées dans un seul 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 des exigences de gestion des dépendances plus distribuées.
Bazel est uniquement * nix, il ne fonctionne pas sous Windows. Cela élimine un grand nombre d'entreprises potentielles.
Pas d'écosystème de plugins.
la source
Gradle est principalement utilisé dans l'écosystème JVM (Java, Ggroovy, Scala, Kotlin ...). Si votre projet est dans ce domaine et que vous devez poser la question, Gradle ou Maven serait un meilleur choix. Pour dépanner une build Gradle, vous vous disputerez uniquement avec l'écosystème Java et JVM.
Bazel au cœur a la capacité de détecter les modifications incrémentielles (ainsi que le cache de build distribué) et vous permet de réagir, d'appliquer des plugins / règles pour réaliser des builds incrémentiels. Pour configurer et maintenir cela, il fallait un peu de connaissances en CPP, Java et Python (Skylark) et les connaissances de l'administrateur système également. Encore une fois, si vous devez poser la question, je pense que Gradle ou Maven serait un investissement moins cher. Avec Bazel, vous pouvez créer toutes les langues, de la manière que vous définissez, plus de puissance, mais à un coût.
la source