Was sind die Unterschiede zwischen Bazel und Gradle?

Google hat gerade sein Build-Tool Bazel als Open-Source-Version bereitgestellt . Was sind die Unterschiede zwischen diesem Tool und Gradle ? Was kann Gradle nicht, was macht es besser und was macht Gradle besser?

Haftungsausschluss: Ich arbeite an Bazel und bin mit Gradle nicht vertraut. Einer meiner Mitarbeiter hat jedoch einen Vergleich der beiden Systeme geschrieben, den ich hier umschreiben werde:

Bazel und Gradle betonen verschiedene Aspekte der Build-Erfahrung. Bis zu einem gewissen Grad sind ihre Prioritäten nicht kompatibel - Gradles Wunsch nach Flexibilität und Nichtauffälligkeit schränkt die Einschränkungen ein, die der Build-Struktur auferlegt werden können, während Bazels Wunsch nach Zuverlässigkeit und Leistung notwendigerweise nicht verhandelbare Einschränkungen erzwingt.

Gradle schätzt dieselben Prinzipien wie Bazel, dh das Gradle-Team legt großen Wert auf Leistung (inkrementelle Builds, parallelisierte Konfiguration und Ausführung, Gradle-Daemon), Korrektheit (inhaltsbasierte „aktuelle“ Überprüfung) und Reproduzierbarkeit (Umfangreiche Unterstützung für deklarative Syntax, Versionsverwaltung von Abhängigkeiten, explizit deklarierte Abhängigkeiten). Und Bazel respektiert die Notwendigkeit flexibler Projektlayouts.

Die Nuance ist, dass Gradle gute Praktiken fördern will, während Bazel sie fordern will. Gradle strebt einen Mittelweg zwischen der Ant-Erfahrung (Freiheit, Ihre eigene Projektstruktur mit inkohärenten Ergebnissen zu definieren) und der Maven-Erfahrung (erzwungene Best Practices ohne Raum für unterschiedliche Projektanforderungen) an. Bazel glaubt, dass flexible Projektunterstützung möglich ist, ohne auf die starken Garantien zu verzichten, die seine leistungsstarken Workflows ermöglichen.

Keine der beiden Philosophien ist „korrekter“ - welches Tool am besten zu einem Projekt passt, hängt von den Werten des jeweiligen Projekts ab.

Gradle Übersicht

Gradle ist ein hochflexibles System, mit dem Benutzer auf einfache Weise vollständige, zuverlässige Build-Flows mit minimalen Einschränkungen bei der Organisation ihrer Projekte erstellen können. Dazu werden leistungsstarke Bausteine ​​(z. B. automatische Verfolgung und Abfrage von Abhängigkeiten, eng integrierte Plugin-Unterstützung) mit einer generischen, Turing-vollständigen Skriptschnittstelle bereitgestellt, die diese Blöcke beliebig kombinieren kann.

Gradle betont die folgenden Merkmale:

• Einfache Migration von anderen Systemen. Gradle passt problemlos jede Projektorganisation an, um beliebige Workflow-Strukturen einfach zu implementieren. Es versteht Ant-Aufgaben nativ und lässt sich nativ in Maven- und Ivy-Repositorys integrieren.
• Hoch erweiterbares Skriptmodell. Benutzer implementieren die gesamte Build-Logik, indem sie Groovy-Skripte schreiben. Ein "Build" ist einfach eine abhängigkeitssequenzierte Ausführung generischer Aufgaben, bei denen es sich im Wesentlichen um offene, überschreibbare und erweiterbare Methodendefinitionen handelt.
• Reichhaltiges Abhängigkeitsmanagement. Versionierte Abhängigkeiten können aus externen Code-Repositorys, lokalen Dateisystemen und anderen Gradle-Projekten deklariert und automatisch bereitgestellt werden. Build-Ausgaben können ebenfalls automatisch in Repositorys und anderen Speicherorten veröffentlicht werden.
• Eng integriertes Plugin-System. Plugins sind einfach Bündel von Aufgaben, die so organisiert sind, dass sie einen gewünschten Workflow ermöglichen. Viele der "Kern" -Funktionen von Gradle werden tatsächlich über Plugins (z. B. Java, Android) implementiert. Plugins interagieren (nach eigenem Ermessen) eng mit der Build-Skript-Logik. Plugins haben tiefen Zugriff auf die Kerndatenstrukturen von Gradle.

Bazel Übersicht

Bazel entstand aus der Notwendigkeit heraus, interne Google-Projekte zuverlässig und effizient zu erstellen. Da die Entwicklungsumgebung von Google ungewöhnlich groß und komplex ist, bietet Bazel ungewöhnlich hohe Garantien für die Integrität seiner Builds und einen ungewöhnlich geringen Leistungsaufwand bei deren Erreichung.

Dies bietet eine Grundlage für leistungsstarke Entwicklungsworkflows, die auf reproduzierbaren Builds basieren. Dabei wird ein „Build“ zu einer abstrakten Entität, die referenziert, wiederholt, an verschiedene Computer weitergegeben und an beliebige Programme und Dienste übergeben werden kann, sodass bekannt ist, dass jede Instanz vorhanden ist genauso.

Bazel betont die folgenden Merkmale:

• Richtigkeit. Bazel-Builds sind so konzipiert, dass sie immer die richtige Ausgabe und Periode liefern. Wenn zwei Benutzer denselben Build beim selben Commit mit denselben Bazel-Flags auf verschiedenen Computern aufrufen, werden identische Ergebnisse angezeigt. Inkrementelle Builds sind genauso zuverlässig korrekt wie saubere Builds, sodass letztere im Wesentlichen unnötig sind.
• Performance. Builds sind so konzipiert, dass sie angesichts der ihnen zur Verfügung stehenden Ressourcen so schnell wie möglich ausgeführt werden können. Aufgaben sind so parallelisierbar, wie es ihre Abhängigkeitsketten zulassen. Unnötige Arbeiten werden niemals ausgeführt (dh „aktuelle“ Aufgaben werden immer übersprungen). Die Arbeit kann natürlich an Remote-Executoren vergeben werden, um die lokalen Maschinenlimits zu überwinden.
• Reproduzierbarkeit. Jede Instanz eines Builds kann in jeder Umgebung originalgetreu reproduziert werden. Wenn beispielsweise in einem Fehlerbericht angegeben wird, dass Version X von Software Y in der Produktionsumgebung Z fehlschlägt, kann ein Entwickler sie auf seinem eigenen Computer originalgetreu neu erstellen, mit der Gewissheit, dass er dasselbe debuggt.

Da Artikel-Links tendenziell absterben, finden Sie hier eine Zusammenfassung der Ansichten des Gradle-Teams zu Bazel (die meisten stammen direkt aus dem Artikel, der im März 2015 veröffentlicht wurde):

Es wurde entwickelt, um ein Problem zu lösen, das nur bei Google auftritt. eine massive monolithische Codebasis (Hunderte Millionen LOC).

Der Parallelisierungsvorteil, den Bazel derzeit bietet, wird durch "unser bevorstehendes neues Konfigurations- und Komponentenmodell" ergänzt (beachten Sie das Artikeldatum hier).

Bazel verfügt nicht über eine deklarative Build-Sprache auf hoher Ebene, die die Verwendung des Builds für Entwickler vereinfacht. Bei Google kann dies durch ein spezialisiertes Serviceteam kompensiert werden, dem das Build-Tool gehört.

Bazel ist nicht auf Erweiterbarkeit ausgelegt (obwohl das Bazel-Entwicklungsteam dem inzwischen mit der Zusicherung begegnet ist, dass an Erweiterbarkeit gearbeitet wird).

Die Geschwindigkeit wird optimiert, um alle transitiven Abhängigkeiten in einem großen Repo zu speichern. Alle Bibliotheken und Tools werden in dieses zentrale Repository eingecheckt. Die meisten Unternehmen haben mehr Anforderungen an das verteilte Abhängigkeitsmanagement.

Bazel ist nur * nix, läuft nicht unter Windows. Dies eliminiert eine große Anzahl potenzieller Unternehmen.

Kein Plugin-Ökosystem.

Gradle wird hauptsächlich im JVM-Ökosystem verwendet (Java, Ggroovy, Scala, Kotlin ...). Wenn sich Ihr Projekt in diesem Bereich befindet und Sie die Frage stellen müssen, sind Gradle oder Maven die bessere Wahl. Um einen Gradle-Build zu beheben, müssen Sie sich nur mit dem Java- und JVM-Ökosystem auseinandersetzen.

Bazel im Herzen kann inkrementelle Änderungen (sowie den verteilten Build-Cache) erkennen und reagieren, Plugins / Regeln anwenden, um inkrementelle Builds zu erzielen. Um dies einzurichten und zu warten, waren einige Kenntnisse in CPP, Java und Python (Skylark) sowie in den Kenntnissen des Systemadministrators erforderlich. Nochmals, wenn Sie die Frage stellen müssen, denke ich, dass Gradle oder Maven eine billigere Investition wären. Mit Bazel können Sie jede Sprache erstellen, auf welche Weise Sie sie definieren, mehr Leistung, aber zu einem Preis.