In this talk I will compare two approaches for continuously integrating large codebases in Java.
One approach is to split the code to small repositories, and define versioned modules (of services, but also of libraries), maven style in each one. Here the dependencies between the modules are on specific jar versions. This allows for great autonomy of teams and espouses greater code decoupling. on the other hand It make cross company changes much more difficult, higher risk of accumulating debt and greater insensitive to duplicate code over and over again.
Another approach (represented by Bazel and other build tools) is to keep all dependencies as source code dependencies on floating jar outputs. This approach allows to gather the code into a small set of repositories (or even one big repository) and so share more code between different products, It enables to perform cross-company changes much more easily and keep the code up-to-date and not stagnate. The downside to this approach is the challenge of the scale of code that needs to be continuously re-built (as opposed to versioned jars). Bazel solves the scale issue by using aggressive accurate caching and a high degree of build and test parallelism.
At Wix backend we have always supported the latter approach of depending on floating jar outputs to help keep us on the fast CI track. We used to build are code with Maven using "Snapshot" jars feature, but this had a lot of performance issues. Switching to bazel allowed us to
Building a large JVM codebase with Bazel
Full Talk (40 Minutes)
Food & Swag Sponsors
Learn more about each of our Event Sponsors.