Migrating to Bazel from Maven or Gradle? 5 crucial questions you should ask yourself
Migrating to a new build tool can be tricky, especially if it entails a paradigm shift. But with careful thought and planning it can bring great results.
As Wix Backend grew exponentially with more than 800 micro-services, it became obvious our previous build tool for jvm/scala code (Maven) has been slowing us down.
We decided to switch to the Bazel build tool and Google Cloud Build CI platform.
Bazel is an open source build tool designed for speed and accuracy with a sand-boxed build environment which allows for truly incremental builds and a high degree of test parallelism. Google Cloud Build allows Bazel to flourish in the cloud using remote build execution and tailor-made build results UI.
We have seen about 5 times faster clean builds when running with bazel remote execution which utilizes bazel’s great build/test parallelism capabilities when it dispatches build/test actions to a worker farm.
Average build times are more than 10 times faster due to the utilization of bazel’s aggressive caching mechanism
The migration journey at Wix had its ups and downs. We’ve learned a lot during this process, and at the same time Bazel and Google Cloud Build have also improved considerably to meet our needs.
I have identified 5 important decisions and points to consider when migrating to Bazel from Maven or Gradle. These include
- How to choose the right build unit granularity
- How to Decide on CI Server and remote execution / caching
- How to optimize local dev experience on MacOs, Windows and Linux
- How to decide on amount of source control repositories
- How to optimize 3rd party version management
I will share each of these in their own separate post.
The latest one is How to Decide on CI Server and remote execution / caching