Too busy to read?

Continuous integration was designed to solve this problem by making merging into trunk a part of everyone's daily work.

Our countermeasure to large batch size merges is to institute continuous integration and trunk-based development practices, where all developers check in their code to trunk at least once per day. Checking code in this frequently reduces our batch size to the work performed by our entire developer team in a single day. The more frequently developers check in their code to trunk, the smaller the batch size and the closer we are to the theoretical ideal of single-piece flow.

"Without automated testing, continuous integration is the fastest way to get a big pile of junk that never compiles or runs correctly."

Gruver and his team created a goal of increasing the time spent on innovation and new functionality by a factor of ten. The team hoped this goal could be achieved through: Continuous integration and trunk-based development Significant investment in test automation Creation of a hardware simulator so tests could be run on a virtual platform The reproduction of test failures on developer workstations A new architecture to support running all printers off a common build and release