Skip to main content
A new application always begins small, usually with a specific language or framework. Setting up and running a small project is seemingly straightforward because you are provided with a getting started guide with quickstart tools to help you get your code running immediately: A typical quickstart tool creates a ready-to-run application by generating a standard folder structure, installing the required tools, and wiring everything together so you can start writing code immediately with minimal setup. But quickstart tools have a caveat; they are generally:
  • Tied to a specific programming language
  • Designed for small to medium sized applications
  • Integrated with a single tool chain for simplicity
But what happens when your codebase grows due to full stack requirements? Now, developing the application requires more than one programming language, multiple teams, a complex folder structure, and more tests to be run. Eventually, the quickstart tools are no longer enough to run your application. One solution teams opt for is writing bash scripts to install tools, prepare the development environment, build components in order, and selectively run tests, but these scripts become hard to maintain as the complexity of the application increases. Over time, this makeshift approach of running large applications with scripting can only do so much and only buys a limited amount of time. Applications like these need to have a general purpose build system to solve these limitations and improve developer workflows, while scaling into really large codebases in many languages. Let’s briefly explore some of the popular general purpose build systems that have improved development workflows over the years.
  • Bazel is an open-source build and test tool designed to deliver fast, consistent builds for multi-language applications, especially at large scale. This course will explore Bazel in more detail.
  • Make is a long-established build automation tool with some similarities to Bazel. However, its lack of separation between the project structure and build commands, makes it brittle and hard to maintain over time.
  • Buck2 is Meta’s internal clone of Bazel, it uses the same concepts and syntax as Bazel, but lacks compatibility with Bazel’s ecosystem and has minimal adoption outside of Meta.
  • Pants a now obsolete Bazel clone developed by Twitter now called X. It lost its momentum after its commercial backing (toolchain.com) folded.
  • MSBuild is a build automation tool from Microsoft, primarily used within the Visual Studio ecosystem. It hasn’t seen widespread adoption as a standalone build tool outside of Visual Studio users.
  • Gradle Build Tool a standard build tool for Java and Kotlin projects. It’s often paired with Develocity (formerly Gradle Enterprise).
  • Nx is typically used in managing frontend monorepo projects, and is expanding support to include additional programming languages.
You can learn much more from this Research paper: Build Systems a la carte

​
Continuous Integration (CI) tools vs build systems: what’s the difference?

You may think of a CI tool like Jenkins as a build system, but in fact these are separate layers. A CI tool is responsible for scheduling when to kick off a build and displaying the results, they do not have the ability to understand the orchestration of dozens of compilers, code generators, and testing tools as build tools do.
If you write scripts for your CI tool, you’re essentially writing your own build system. Use a dedicated build tool instead.
Next, you’ll learn about the core properties of Bazel and what makes it different from other build tools.