Ten-minute build

It's worth developing an automated, reliable and reproducible build for your project that builds the system and runs all the tests. It should be run many times a day, initiated by a schedule or in response to some asynchronous event such as checking source code into the repository. You should also be able to initiate the build on demand, e.g. from the command line or from within an IDE. The build needs to be fast if it's going to run frequently. Therefore, you need to invest in continual improvement and optimisation to maintain a ten-minute build cycle. Any longer than ten minutes and the build won't be used as often and won't provide as much feedback.

Continuous integration

Traditional integration is a big-bang affair, highly unpredictable and typically fraught with problems. A build that runs frequently allows developers to integrate and test their changes often, perhaps every 2 to 3 hours. There's no rule of thumb here; it depends on your code and how you've broken the functionality down into chunks to be developed, but the longer you wait to integrate, the more risky and unpredictable integration becomes. By integrating often, integration is broken down into many small integrations that are performed as part of the cycle: test-code-refactor~~integrate . The integration nightmare goes away and the number of integration problems are reduced.

A continuous integration tool like Cruisecontrol can be configured to start the build asynchronously, triggered by a check-in of source code to the repository. If problems are encountered during the build, which includes running all the tests, the developers are automatically notified by email, RSS, or a text message (also take a look at some alternative extreme feedback devices ). The rule here is to react immediately and fix the build. A broken build should not be tolerated.

Developer rhythm

A ten-minute build automated with continuous integration helps developers establish a rhythm as they develop software. This rhythm reminds developers to integrate regularly. Integration should happen at least once a day and only working tested code should be checked-in. Source code should not be checked-out for days on end, and broken code should never be checked-in. The following diagram shows the steps a developer performs in the test-code-refactor~~integrate cycle.


developerrhythm
Originally uploaded by sjb140470

I always do a local clean build before I commit any changes to the repository. With a ten-minute build I don't have to wait long before I know whether I can proceed with the check-in. This time gives me a chance to come up for air , grab a drink, or reflect with my pair-programming partner on the work we just completed. If you don't do a local build you'll know about any integration errors as soon as the continuous integration build runs. You can then assess the problem and decide whether a quick fix can be found or whether the changes need to be backed-out of the repository, so that the builds works once again.

Continuous integration tools:
Cruisecontrol , Beetlejuice , Continuum