Fast, Automatic Builds: the Agile Heartbeat

for builds is: quot; Make Your Build Self-Testing .quot; This implies that the automatic build also includes an automatic test. He asks that all code have a set of automatic tests that can check a large part of the code base for bugs. Many developers are, in fact, already writing such test suites through the Extreme Programming focus on unit testing, or by performing test-driven development (where developers write the tests before the code).
With this test suite in place, Fowler asks that the automated build test itself by running the test suite and reporting the results. Results would typically be reported on screen or by email, if the build and test was run remotely.
Fowler's next two practices have a profound affect on build management: quot; Everyone Commits Every Day quot; and quot; Every Commit Should Build the Mainline on an Integration Machine .quot; The implication is that every developer will be committing code once per day (at least) and that every commit will cause a build and test on some build resource (the quot;integration machinequot;) managed by the build manager. To put that in perspective, for a team of 20 engineers committing once per day during an eight hour work day, that's a build and test every 24 minutes! For large teams that number increases, and the time between builds is greatly shortened.
The reason agile developers want these per-commit builds is to ensure that integration between developers is faultless and that the software being built works and is testable at all times. The idea that the software should run at all times is central to agile development, and the health of the per-commit build and test becomes an important sign of health for the entire project. If per-commit builds are done quickly and frequently enough, the build will reflect changes made by a single check-in by a single developer, offering an unparalleled opportunity to narrow down the cause of a breakage.
In fact, this build is so important that it is essentially the Agile Heartbeat . Agile teams can install monitoring devices (such as red and green lava lamps) to make the status of the heartbeat build visible to all. Fowler states that no developer should quot;go home until the mainline build has passed with any commitsquot; they've added. This means that all of engineering looks every day to the heartbeat to measure their own progress.
Another important practice mentioned in Fowler's paper is quot; Keep the Build Fast .quot; This seems like an obvious prerequisite to the previous practices, since a team that requires a build every few minutes and every time the code changes will necessarily need very fast builds. In fact, Extreme Programming outlines the goal of ten-minute builds, and I've dubbed them quot;espresso buildsquot; -- builds that only take as long as a coffee break.
Fast builds are also important because developers are looking to the status of the build as a measure of their progress. Every minute that is shaved off the build is a minute saved for all developers who have committed code to that build. With many developers, and many builds, that time saved adds up quickly and fast builds improve the productivity of the entire team.
Conclusion
Agile development puts fast, automatic builds center stage and requires a new approach to software production tasks. Teams can realize some of the benefits of agile development with a strategic approach to continuous integration. Careful planning is required by all parts of the engineering team with a special focus on the build resources. The build team will come under enormous pressure once