The Google Build System

The high-performance engine inside Google's code construction factory

John Field

As in most large software development organizations, Google's production software is built from a pipeline of compilation, transformation, linking, and analysis operations applied to a variety of source and data artifacts. Most of Google's products and services are built from a single "continuously integrated" code repository. That is, before a Google engineer's code update is checked into the repository, the software artifacts that use the code must be built and tested with the latest ("head") versions all of the source code it transitively depends on. In addition, all "upstream" code that depends on the checked-in code is rebuilt and tested (again, from source) after checkin to ensure that the updates have no adverse effects on other code.

Google's code repository has over 100,000,000 lines of code, and over 150,000 build requests are made every day. Even builds of relatively small binary artifacts can require tens of thousands of compilation/transformation/linking/analysis actions touching hundreds of thousands of source artifacts. Given those numbers and Google's practice of continuous integration, it should be obvious that the build process requires significant computational resources and automation to ensure that build and test outputs are made available to developers in a timely manner.

In this talk, I will describe the Google's parallel and incremental code construction engine, the Google Build System. The system has three principle components: a declarative Build Language that allows users to specify how code artifacts are constructed from a myriad of different source languages and tools, a "compiler" for the Build Language that translates Build Language programs into a graph of purely functional Build Actions, and a collection of distributed services that coordinates parallel and incremental execution of build actions on servers in Google's data centers. I will explain how the three components work together synergistically, and describe some of the language design and distributed systems engineering challenges that had to be overcome to allow the system to scale and evolve as Google's code base has grown. I will also describe some opportunities for future evolution of the system.