For large organisations like Google, the approach of project-centric continuous builds has severe limitations. Either teams only test their code in isolation (and are sometimes surprised that changes from other teams can break their application), or they fight with an overload of changes from all teams around them.

Furthermore, at Google, all code resides in one code repository - all teams build from head. Some teams spent an enormous amount of time to deal with all the changes from other teams. Other teams learned to live with red builds. Some teams setup many continuous builds to test their code on multiple levels. All this created a lot of overhead - first, to simply maintain all these continuous build servers, and second to analyze all the different signals and quickly trying to identify which change broke a build and how to fix it as fast as possible.

This lead to the idea of a company-wide continuous build! Using Google's vast production clusters, it was possible not only to create such a system but also run all affected tests at each code change - and give feedback within a few minutes. This talk focuses on the functional aspects of such a system. While similar to a project-centric continuous build, it turned out that it needed a very different UI, notifications and API's.