IMPORTANT: The Bazel docs have moved! Please update your bookmark to https://bazel.build/start/bazel-vision

You can read about the migration, and let us know what you think.

Bazel Vision

Any software developer can efficiently build, test, and package any project, of any size or complexity, with tooling that's easy to adopt and extend.

  • Engineers can take build fundamentals for granted. Software developers focus on the creative process of authoring code because the mechanical process of build and test is solved. When customizing the build system to support new languages or unique organizational needs, users focus on the aspects of extensibility that are unique to their use case, without having to reinvent the basic plumbing.

  • Engineers can easily contribute to any project. A developer who wants to start working on a new project can simply clone the project and run the build. There’s no need for local configuration - it just works. With cross-platform remote execution, they can work on any machine anywhere and fully test their changes against all platforms the project targets. Engineers can quickly configure the build for a new project or incrementally migrate an existing build.

  • Projects can scale to any size codebase, any size team. Fast, incremental testing allows teams to fully validate every change before it is committed. This remains true even as repos grow, projects span multiple repos, and multiple languages are introduced. Infrastructure does not force developers to trade test coverage for build speed.

We believe Bazel has the potential to fulfill this vision.

Bazel was built from the ground up to enable builds that are reproducible (a given set of inputs will always produce the same outputs) and portable (a build can be run on any machine without affecting the output).

These characteristics support safe incrementality (rebuilding only changed inputs doesn’t introduce the risk of corruption) and distributability (build actions are isolated and can be offloaded). By minimizing the work needed to do a correct build and parallelizing that work across multiple cores and remote systems, Bazel can make any build fast.

Bazel’s abstraction layer — instructions specific to languages, platforms, and toolchains implemented in a simple extensibility language — allows it to be easily applied to any context.

Bazel core competencies

  1. Bazel supports multi-language, multi-platform builds and tests. You can run a single command to build and test your entire source tree, no matter which combination of languages and platforms you target.
  2. Bazel builds are fast and correct. Every build and test run is incremental, on your developers’ machines and on CI.
  3. Bazel provides a uniform, extensible language to define builds for any language or platform.
  4. Bazel allows your builds to scale by connecting to remote execution and caching services.
  5. Bazel works across all major development platforms (Linux, MacOS, and Windows).
  6. We accept that adopting Bazel requires effort, but gradual adoption is possible. Bazel interfaces with de-facto standard tools for a given language/platform.

Serving language communities

Software engineering evolves in the context of language communities — typically, self-organizing groups of people who use common tools and practices.

To be of use to members of a language community, high-quality Bazel rules must be available that integrate with the workflows and conventions of that community.

Bazel is committed to be extensible and open, and to support good rulesets for any language.

Requirements of a good ruleset

  1. The rules need to support efficient building and testing for the language, including code coverage.
  2. The rules need to interface with a widely-used “package manager” for the language (such as Maven for Java), and support incremental migration paths from other widely-used build systems.
  3. The rules need to be extensible and interoperable, following “Bazel sandwich” principles.
  4. The rules need to be remote-execution ready. In practice, this means configurable using the toolchains mechanism.
  5. The rules (and Bazel) need to interface with a widely-used IDE for the language, if there is one.
  6. The rules need to have thorough, usable documentation, with introductory material for new users, comprehensive docs for expert users.

Each of these items is essential and only together do they deliver on Bazel’s competencies for their particular ecosystem.

They are also, by and large, sufficient - once all are fulfilled, Bazel fully delivers its value to members of that language community.