TRIFORK
INFOQ
<<< Previous speaker next speaker >>>

Mark Striebeck, Google

Mark Striebeck Mark Striebeck is an engineering manager at Google where he is responsible for developer testing infrastructure, tools and adoption. In his 20% time he works in an internal user group which tries to further the adoption of agile practices. He has been working for more than 10 years in the software industry in a variety of engineering and management positions. Since discovering XP and agile development methodologies 5 years ago, he has become actively engaged in the agile community. He constantly tries to put new ideas and agile approaches to work. The great variety of projects and individuals at Google give plenty of opportunity for this. Striebeck is a frequent speaker at Agile and other conferences. He holds two master's degrees in mathematics and computer science from the University of Hannover and Brunel University, London.

Presentation: "Mother of All Builds for Google"

Time: Friday 16:15 - 17:15

Location: Stanford

Abstract:

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.