Google startete Bazel vor vier Jahren. Der Grund? Die Google-Entwickler selbst hatten Bedarf an hochgradig skalierbaren Builds. Wer schon öfter an größeren Projekten gearbeitet hat, kennt das vielleicht: Zwischen Unit-Test und neuem Feature werden in jedem Sprint typischerweise mehrere neue Dateien zu einem Projekt hinzugefügt, bis das Ganze irgendwann derart aufgeblasen ist, dass die Skalierung der Builds, gerade in größeren Projekten, manchmal mehrere Sekunden dauert.

Der „Build“ ist der Prozess, in dem Dateien und andere Assets eurer Anwendung in ihre finale, vom Endnutzer verwendete Form konvertiert werden. In der Build-Phase, werden zum Beispiel eure Source-Files kompiliert, kompilierte Dateien zu komprimierten Formaten (zum Beispiel .jar oder .zip) verpackt, Installationsdateien erstellt und Datenbank-Schemata erstellt und aktualisiert. Automatisierte Builds sind dann möglich, wenn diese Schritte wiederholbar sind, Entwickler an keiner Stelle eingreifen müssen und zur Ausführung keine anderen Informationen nötig sind als die, die euer Repo beinhaltet.

Inkrementelle Builds sind sowas wie der Schlüsselfaktor für eine bessere Build-Performance. Code ändert sich meistens in kleinen Inkrementen. Daher ist es wenig sinnvoll, die gesamte Anwendung bei jeder kleinen Änderung neu zu erstellen. Besser: Nur das neu erstellen, was sich wirklich ändert. Von den Änderungen betroffene Teile eurer Codebase natürlich auch.

An dieser Stelle kommt Bazel ins Spiel. Mit Bazel könnt ihr eure Applikation in verschiedene Build-Units unterteilen. In Angular zum Beispiel sind die Build-Units auf der Ebene der NgModules definiert. Der Umfang eines Builds kann also theoretisch so granular sein wie ein einzelnes NgModul. Wenn jetzt eine Änderung in einem NgModul erfolgt, die nur dieses Modul betrifft, muss folglich auch nur dieses Modul neu erstellt werden. Ändert ihr die öffentliche API von irgendeinem Teil innerhalb eures NgModules, muss natürlich jedes andere, das darauf referenziert, ebenfalls neu gebaut werden.

Wie auch immer – die Build-Time eurer Anwendung ist auf jeden Fall deutlich kürzer als sonst – einfach weil pro Build deutlich weniger Code durchgepflügt werden muss. Damit ihr auch was davon habt, entschieden sich die Bazel-Entwickler für die Veröffentlichung unter einer Open-Source-Lizenz. Die wachsenden Nutzerzahlen scheinen Google rechtzugeben: skalierbare, reproduzierbare, multilinguale Builds sind gefragt. Viele der hauseigenen offen lizenzierten Projekte, wie Tensorflow oder Angular, verwenden Bazel.

• Die Builds in Bazel sind schnell. Das Tool ermöglicht inkrementelle Builds und Testdurchläufe – lokal und in Continuous-Integration-Test-Systemen.
• Bazel bietet Unterstützung für Builds und Tests in multiplen Sprachen und Plattformen. Über einen einzelnen Command sollt ihr euren gesamten Source Tree erstellen und testen können – unabhängig der in euren Projekten verwendeten Kombinationen aus Programmiersprache und Plattform.
• Der Spaß funktioniert auf Linux, macOS und Windows gleichermaßen.
• Das Tool kommt mit einer einheitlichen Erweiterungssprache – nämlich Starlark –, über die ihr eure Builds definieren könnt – unabhängig von den Sprachen und Plattformen, die ihr verwendet.
• Bazel verbindet sich mit verteilten Remote-Execution- und Caching-Services – und eure Builds können skalieren.

Der 1.0-GA-Release kommt mit Semantic Versioning – Rückwärtskompatibilität von Folgeversionen zu Version 1.0 ist also auf jeden Fall schon mal sicher. Zwischen allen Major-Version-Releases sollen mindestens drei Monate liegen, Minor-Updates wird es monatlich auf GitHub geben.

Außerdem kommt Version 1.0 mit Long-Term-Support. So könnt ihr als Nutzer sicher sein, dass etwaige Bugs und Schwachstellen in der Software zuverlässig gefixed werden. Außerdem nannte der Blog-Post „well-rounded features for Angular, Android, Java und C++“, wie etwa End-to-End-Support für Remote Execution und Caching sowie Support für Dependencies von Drittanbietern und die Standard-Packaging-Manager.

Wer Bazel bisher noch nicht kannte, aber Verwendung dafür finden würde: Hier findet ihr Tutorials für eure Lieblingsprogrammiersprache. Außerdem gibt’s eine Mailing-List, einen Slack-Channel und einen Issue-Tracker auf GitHub – ihr seid herzlich willkommen, Bugs zu reporten oder Wünsche nach weiteren Features zu äußern.