|License||Apache License 2.0 v|
In software development, Bazel is a free software tool that allows for the automation of building and testing of software. The company Google uses the build tool Blaze internally and released and open-sourced part of the Blaze tool as Bazel, named as an anagram of Blaze. Bazel was first released in March 2015 and achieved beta status by September 2015.
Similar to build tools like Make, Apache Ant, or Apache Maven, Bazel builds software applications from source code using a set of rules. Rules and macros are created in the Skylark language, a subset of Python. There are built-in rules for building software written in the programming languages of Java, C, C++, Go, Python, Objective-C and Bourne shell scripts. Bazel can produce software application packages suitable for deployment for the Android and iOS operating systems.
In designing Bazel, emphasis has been placed on build speed, correctness, and reproducibility. The tools uses parallelization to speed up parts of the build process. It includes a Bazel Query language that can be used to analyze build dependencies in complex build graphs.
One of the goals of Bazel is to create a build system where build target inputs and outputs are fully specified and therefore precisely known to the build system. This allows a more accurate analysis and determination of out-of-date build artifacts in the build system's dependency graph. Making the dependency graph analysis more deterministic leads to potential improvements in build times by avoiding re-executing unnecessary build targets. Build reliability is improved by avoiding errors where build targets might depend on out-of-date input artifacts.
To achieve more accurate dependency graph analysis, Bazel uses content digests rather than file-based timestamps. File timestamps are commonly used to detect changes in tools like Make or Apache Ant. Timestamps can be problematic when builds are distributed across multiple hosts due to issues with clock synchronization. One of Bazel's goals is to enable distributed and parallel builds on a remote cloud infrastructure. Bazel is also designed to scale up to very large build repositories which may not be practical to download to an individual developer's work machine.
Bazel provides tooling which helps developers to create bit-identical reproducible build outputs. Bazel's implemented rules avoid typical pitfalls such as embedding timestamps in generated outputs to ensure content digest matches. This in turn allows the build system to reliably cache (memoize) the outputs of intermediate build steps. Furthermore, reproducible build makes it possible to share intermediate build results between teams or departments in an organization, using dedicated build servers or distributed caches. Bazel therefore is particularly well-suited for larger organizations and software projects that have significant number of build dependencies. A deterministic build and an ability to precisely analyze build input and output artifacts across the dependency graph lends itself to parallel execution of build steps.
Bazel is extensible with its custom Skylark programming language. Skylark uses a syntax which is a subset of the syntax of the Python programming language. Skylark however doesn't implement many of Python's language features, such as ability to mutate collections or access the file I/O, in order to avoid extensions that could create side-effects or create build outputs not known to the build system itself. Such side-effects could potentially lead to incorrect analysis of the build dependency graph.
Bazel was designed as a multi-language build system. Many commonly used build system are designed with a preference towards a specific programming language. Examples of such systems include Ant and Maven for Java, Leiningen for Clojure, sbt for Scala, etc. In a multi-language project, combining separate build systems and achieving the build speed and correctness benefits described above can be difficult and problematic.
Bazel also provides sand-boxed build execution. This can be used to ensure all build dependencies have been properly specified and the build does not depend, for example, on libraries installed only locally on a developer's work computer. This helps to ensure that builds remain portable and can be executed in other (remote) environments.
Build systems most similar to Bazel are Pants and Buck. Pants and Buck both aim for similar technical design goals as Bazel and were inspired by the Blaze build system used internally at Google. Blaze is also the predecessor to Bazel. Independently developed build systems with similar goals of efficient dependency graph analysis and automated build artifact tracking have been implemented in build systems such as tup.
Since Bazel's initial release the logo was a green letter "b" stylized into a stem of a basil plant with two leaves.
On July 5, 2017, the Bazel Blog announced a new logo, consisting of three green building blocks arranged to shape a heart.
- "Releases". GitHub.
- Yegulalp, Serdar (Sep 11, 2015). "Google open-sources language-agnostic, scalable software tool". InfoWorld. Retrieved 25 June 2016.
- Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard. Site Reliability Engineering: How Google Runs Production Systems. "O'Reilly Media, Inc.". p. 90. ISBN 9781491951187. Retrieved 25 June 2016.
- Bolton, David (27 April 2015). "Bazel, Google's Open Source Build System - The New Stack". thenewstack.io. The New Stack. Retrieved 25 June 2016.
- Daws, Ryan. "Google's software build tool Bazel heads into beta". www.developer-tech.com. Developer Tech. Retrieved 25 June 2016.
- "FAQ - Bazel". bazel.build. Google. Retrieved 25 June 2016.
- "What's Wrong With GNU make?".
- Nathan York (23 September 2011). "Build in the Cloud: Distributing Build Steps". Google Engineering.
- "Pants: A fast, scalable build system".
- "Buck: A high-performance build tool".
- Mike Shal (2009). "Build System Rules and Algorithms" (PDF).
- Steren Giannini (5 July 2017). "A new logo and homepage for Bazel".