Bazel’s Essential Properties

In the previous section, you learned about build systems, and also uncovered popular build systems in the industry which includes Bazel. But what makes Bazel a good choice? Why should your team choose Bazel from a host of other build tools?

​

Why Choose Bazel?

This section explains why Bazel is a good choice by describing the key qualities of a reliable build system.

​

Incremental: Only rebuild what changed

Bazel is an incremental build system. When you make a change, it rebuilds only the parts of the application that were affected, instead of rebuilding the entire application from scratch. This makes development much faster. Requires: Applications structured as modular libraries without circular dependencies.

​

Correct: Trust your build results

Bazel guarantees that build outputs are always up to date by automatically rebuilding everything that needs to change. Developers don’t need to run “clean” builds to double-check results, which helps avoid slow and frustrating development cycles. Requires: Accurate build depends on the attention in setting the environment up from the beginning. Build correctness is hard to add later because it depends on having a complete and accurate dependency graph. For example, Gradle often relies on heuristic dependencies, which can’t always be trusted.

​

Cacheable: Share build results across your team

Reuse build outputs from previous builds, even those performed on a different computer. Bazel treats builds as pure functions; same inputs always produce identical outputs. Your team is able to share cached results, ultimately reducing total build time across the organization. Requires: Determinism, which means “given the same inputs, build tools write identical output” regardless of where they run. For example, the compiler should not write an absolute file path into the output. Without determinism, later build steps will always get a cache miss due to changed inputs. As a side-effect, builds are isolated - each tool runs in its own temporary environment, which prevents problems like memory leaks.

​

Parallel: Build Faster with more CPUs

With Bazel you can leverage concurrency across multiple local and remote CPUs. Bazel adds minimal overhead and avoids calling tools unnecessarily. Hence, you utilize all available computing resources for the fastest possible builds. Requires: Hermeticity, this means that dependencies are known to the build system, including tools, environment variables, and third-party libraries.

​

Reliable: Guarantee reproducible builds

Achieve bit-for-bit identical outputs every time you build. Thanks to hermeticity and determinism, all the build inputs are guaranteed to get identical outputs. As described on reproducible builds, we want an exact, bit-for-bit guarantee. This guarantees that build outputs can be verified as coming from the exact source code they claim to be built from, providing strong supply chain security. It also ensures that applying fixes to older releases produces consistent builds with no unexpected changes in behavior.

​

Composable: Reuse and extend build rules

Bazel allows you to reuse existing build rules and create new ones by combining simpler ones. This follows the Unix Philosophy of building small, focused components that work well together. Bazel models your build and test the same way, except that instead of text streams, the universal interface is files.

​

Universal: Supports any language or framework

Through plugins called rules, Bazel handles builds and tests for nearly every language and framework in your stack.

​

Scalable: Proven in Google’s massive monorepo

Bazel has proven itself under extreme software development conditions. Google’s engineers have stress-tested it across google3, a monorepo containing 2 billion source lines of code (as of 2015). Now that you understand the essential properties of Bazel, let’s look at how it actually works under the hood by familiarizing ourselves with Bazel’s mental model.