3 ms·
For me, the main advantage of Bazel is speed, when properly structured and configured, a Bazel build can: * Perform incremental build a magnitude faster than M
by dikei 6y ago
For me, the main advantage of Bazel is speed, when properly structured and configured, a Bazel build can:
* Perform incremental build a magnitude faster than Maven, zero changes build finishes immediately.
* Can have global caches for all builds across organization, so that a workstation build can automatically build incrementally upon a standard build, massively reduces build speed for big monorepo.
* Very fast, incremental tests execution: test results are cached, so only tests affected by the changed code are run. Test executions are parallel by default.
Some other things:
* Pull in dependencies directly from a git repository, without having to publishing it first like in maven, this can be a plus or a minus.
* Cross-languages build: you can have each of your module programmed in a different language, declare dependencies between them and use Bazel to perform incrementally build quickly and reliably.
That said, maintaining a Bazel build system is also a magnitude more complex than a Maven one, especially if you're not using one of Google main language: Java/C++. Plugins for other languages are of varying quality.
- jhgb 6y agoGiven that Google has a Common Lisp codebase, I wonder...do they also have Bazel plugins for Common Lisp?
- bruckie 6y agoYes
- sverhagen 6y ago...and a lot of those arguments seem geared toward big codebases. Small micro-services, such as Spring Boot, with the bulk of the test execution going to @SpringBootTest tests, where parallelization has its drawbacks, may not profit from most of those "benefits". Fun fact, it seems like Maven was also meant to service a variety of languages. There's even some support for polyglot POM files. Aside from the niche C++ or JavaScript ("frontend") plugin, that never did much.
- jzoch 6y agoActually we have seen a ton of success using it for spring boot microservices - each microservice has its own BUILD file within the monorepo. Test execution in spring can be parallelized as needed (and not used if not needed!) but i find our tests run a lot faster under bazel due to the caching anyway
- sverhagen 6y agoCan we agree that "it depends"? If I have a resource-starved build runner (looking at you, there, Bitbucket Pipelines), and I have a good handful of parallel integration tests, each spinning up a few Docker containers worth of dependencies, I will end up troubleshooting out of memory situations. I also don't think you get to leverage application context caching, for parallel test execution, and if you did, I'd be concerned about unpredictable conflicting state between those integration tests. If I can already run my tests for a single microservice in about two minutes, the parallelization just isn't worth it to me (in CI). And, oh, I'm not in a monorepo.
- nomercy400 6y agoIs test result caching only possible due to a fundamental design of Bazel, or could you modify for example the maven surefire plugin to achieve the same?
- krzyk 6y ago> Perform incremental build a magnitude faster than Maven, zero changes build finishes immediately. I see benefits of that in projects that build hours, but in every one of my maven projects (non-hobby) I always do clean before package/verify just to make sure the project builds. ``` mvn clean verify ``` And I'm certain it will work in CI also.
- deleted 6y ago[deleted]
- dikei 6y agoPeople tend to run ```mvn clean verify``` because Maven caching is unreliable, and lead to build failures. However, Bazel cache is a lot more robust, so you almost never do clean build. The only time I had to perform a clean build was when I accidentally upgraded my C++ compiler and broke the cache.