- Bazel est un système de build open source développé par Google pour construire efficacement de grands monorepos
- Il permet de builder des projets complexes de façon précise et rapide, particulièrement lorsqu’il s’agit de vastes bases de code et de dépendances multilingues
- Concepts clés de Bazel
- La vitesse fondée sur la précision : Bazel considère les builds comme des fonctions pures et garantit que les mêmes entrées produisent les mêmes sorties
- Mise en cache efficace : dans l’environnement à grande échelle de Google, le caching est indispensable, et la précision le rend possible
- Builds sans nettoyage : après une modification du code source, il est possible d’obtenir des builds stables sans faire de "clean build"
- Quand utiliser Bazel
- Recommandé
- Grands monorepos : lorsque le code atteint plusieurs millions de lignes et utilise plusieurs langages
- Gestion des dépendances entre langages variés : par exemple, entraînement de modèles en Python, traitement de données en Scala, etc.
- Exigences CI/CD rapides et fiables : pour accélérer le développement et éviter les conflits
- Déconseillé
- Petits projets : lorsque la base de code reste sous les 100 000 lignes et n’utilise qu’un seul langage
- Bibliothèques open source : Bazel convient pour produire des artefacts distribuables, mais reste moins adapté à la distribution de bibliothèques réutilisables
- Points à considérer avant d’adopter Bazel
- La courbe d’apprentissage initiale est élevée, et la rédaction ainsi que la maintenance des fichiers de build demandent des ressources supplémentaires
- La mise en place de l’infrastructure, comme un serveur de cache et la configuration de l’exécution à distance, est indispensable
- Exemples de réussite avec Bazel
- Netflix
- Problème : sur un dépôt contenant 250 000 à 300 000 lignes de code, le CI prenait entre 45 minutes et 1 heure
- Solution : après adoption de Bazel, le temps de build est passé de 20 minutes à 6 minutes
- Effet : réduction des conflits de fusion et amélioration de la vitesse de traitement des PR
- Open Systems
- Problème : temps de build lents et flux de travail inefficace
- Solution : après le passage à Bazel, la boucle de feedback a été réduite de 20 minutes à 5 minutes
- Leçon : la formation des développeurs et la communication sont essentielles
- Avantages et inconvénients de l’adoption de Bazel
- Avantages
- Temps de build rapides : amélioration des performances grâce au caching et aux builds incrémentaux
- Précision et reproductibilité : représentation précise de graphes de dépendances complexes
- Intégration multilingue : prise en charge de nombreux langages comme Haskell, TypeScript et Python
- Inconvénients
- Coût d’adoption élevé : configuration initiale et courbe d’apprentissage abruptes
- Gestion nécessaire des fichiers de build : il faut déclarer explicitement les entrées/sorties, avec souvent l’aide d’outils d’automatisation
- Tooling JavaScript et front-end : compatibilité difficile avec les workflows existants, comme le hot reloading
- Conseils pour une migration vers Bazel
- Constituer une équipe cœur : disposer d’experts capables de comprendre et configurer Bazel
- Formation et communication : au début de l’adoption, la formation des développeurs et la définition des attentes sont indispensables
- Complexité selon les langages : chaque langage impose des exigences différentes en matière de configuration de build
- Automatisation des fichiers de build : utiliser des outils comme Gazelle
- Conclusion
- Bazel excelle pour gérer de grands monorepos et des dépendances complexes, mais son coût d’adoption est élevé
- Il convient aux organisations qui gèrent des millions de lignes de code et plusieurs langages
- Pour les petits projets ou en cas de transition progressive, il peut être préférable d’envisager des alternatives comme Earthly plutôt que Bazel
3 commentaires
Il serait intéressant de mentionner aussi des cas d’échec dans l’adoption de Bazel.
Dans le cas d’AOSP, plusieurs présentations ont été faites ces dernières années à BazelCon sur certains aspects de la migration du système de build existant (Soong) vers Bazel.
https://developers.googleblog.com/en/…
Cependant, lors de la BazelCon de cette année, il n’y a pas eu de partage autour d’AOSP et, dans les documents récents liés au build d’AOSP, une note indique que la migration vers Bazel a été interrompue.
Même si l’on peut penser que l’équipe AOSP aurait pu bénéficier d’un soutien important pour la migration vers Bazel, le fait qu’elle ait renoncé à son adoption semble offrir de nombreux enseignements.
Probablement… votre logiciel n’a pas besoin de Bazel.
Haha, Earthly fait de la pub pour Earthly.
Bazel met l’accent sur la rapidité des builds et des « tests ». Il n’y a pas beaucoup de discussion sur les tests ici.