- Bazel ist ein von Google entwickeltes Open-Source-Build-System, um große Monorepos effizient zu bauen
- Es baut komplexe Projekte präzise und schnell und ist besonders effektiv beim Umgang mit großen Codebasen und sprachübergreifenden Abhängigkeiten
- Die Kernkonzepte von Bazel
- Geschwindigkeit durch Korrektheit: Bazel betrachtet Builds als reine Funktionen und stellt sicher, dass dieselben Eingaben dieselben Ausgaben erzeugen
- Effizientes Caching: In Googles großskaliger Umgebung ist Caching unverzichtbar, und Korrektheit macht dies möglich
- Builds ohne Bereinigung: Nach Änderungen am Quellcode sind stabile Builds auch ohne "clean build" möglich
- Wann man Bazel einsetzen sollte
- Empfohlene Verwendung
- Große Monorepos: Wenn der Code mehrere Millionen Zeilen umfasst und mehrere Sprachen verwendet werden
- Verwaltung sprachübergreifender Abhängigkeiten: Zum Beispiel Modelltraining in Python, Datenverarbeitung in Scala usw.
- Anforderungen an schnelles und präzises CI/CD: Erhöht die Entwicklungsgeschwindigkeit und verhindert Konflikte
- Nicht empfohlen
- Kleine Projekte: Wenn der Code weniger als 100.000 Zeilen umfasst und nur eine Sprache verwendet wird
- Open-Source-Bibliotheken: Bazel eignet sich für die Erstellung verteilter Artefakte, ist aber weniger geeignet für die Veröffentlichung wiederverwendbarer Bibliotheken
- Was bei der Einführung von Bazel zu beachten ist
- Die anfängliche Lernkurve ist steil, und für das Schreiben und Warten von Build-Dateien werden zusätzliche Ressourcen benötigt
- Der Aufbau von Infrastruktur wie Cache-Servern und Remote Execution ist unverzichtbar
- Erfolgreiche Beispiele für Bazel
- Netflix
- Problem: In einem Repository mit 250.000 bis 300.000 Zeilen Code dauerte CI 45 Minuten bis 1 Stunde
- Lösung: Nach der Einführung von Bazel sank die Build-Zeit von 20 Minuten auf 6 Minuten
- Wirkung: Weniger Merge-Konflikte, schnellere Bearbeitung von PRs
- Open Systems
- Problem: Langsame Build-Zeiten und ineffiziente Arbeitsabläufe
- Lösung: Nach dem Wechsel zu Bazel wurde die Feedback-Schleife von 20 Minuten auf 5 Minuten verkürzt
- Erkenntnis: Schulung und Kommunikation der Entwickler sind wichtig
- Vor- und Nachteile der Einführung von Bazel
- Vorteile
- Schnelle Build-Zeiten: Geschwindigkeitsverbesserung durch Caching und inkrementelle Builds
- Korrektheit und Reproduzierbarkeit: Komplexe Abhängigkeitsgraphen lassen sich präzise ausdrücken
- Integration mehrerer Sprachen: Unterstützung für verschiedene Sprachen wie Haskell, TypeScript und Python
- Nachteile
- Hohe Einführungskosten: Die anfängliche Einrichtung und die Lernkurve sind anspruchsvoll
- Pflege von Build-Dateien erforderlich: Eingaben/Ausgaben müssen explizit angegeben werden, und der Einsatz von Automatisierungstools ist nötig
- JavaScript- und Frontend-Tooling: Schwierig mit bestehenden Workflows wie Hot Reloading kompatibel zu machen
- Tipps für die Migration zu Bazel
- Aufbau eines Kernteams: Experten sichern, die Bazel verstehen und konfigurieren können
- Schulung und Kommunikation: In der Anfangsphase sind Entwicklertraining und klare Erwartungssetzung unverzichtbar
- Sprachspezifische Komplexität: Jede Sprache erfordert unterschiedliche Build-Konfigurationen
- Automatisierung von Build-Dateien: Einsatz von Tools wie Gazelle
- Fazit
- Bazel ist hervorragend für große Monorepos und komplexe Abhängigkeiten geeignet, aber die Einführungskosten sind hoch
- Es passt zu Organisationen, die mit mehreren Millionen Zeilen Code und mehreren Sprachen arbeiten
- Für kleine Projekte oder wenn eine schrittweise Umstellung gewünscht ist, sollten Alternativen wie Earthly statt Bazel geprüft werden
3 Kommentare
Es wäre gut, wenn auch Beispiele für gescheiterte Bazel-Einführungen erwähnt würden.
Im Fall von AOSP gab es in den letzten Jahren auf der BazelCon mehrere Vorträge über die Migration vom bestehenden Build-System (Soong) zu Bazel.
https://developers.googleblog.com/en/…
Allerdings fehlt auf der diesjährigen BazelCon ein Austausch zu AOSP, und in den aktuellen AOSP-Dokumenten zum Build findet sich der Hinweis, dass die Bazel-Migration gestoppt wurde.
Gerade das AOSP-Team dürfte bei einer Bazel-Migration viel Unterstützung erhalten können; dass es die Einführung dennoch aufgegeben hat, scheint viele wichtige Implikationen zu zeigen.
Wahrscheinlich … braucht Ihre Software Bazel nicht.
Haha, Earthly macht hier Werbung für Earthly.
Bei Bazel liegt der Schwerpunkt auf schnellen Builds und schnellen „Tests“. Über Tests wird hier nicht besonders viel gesprochen.