Agile SCM: Build Management for an Agile Team

suffer from subtle errors because of a slight difference in the developer’s toolset, or because the developer chose to do an incremental rather than a full build. But if the choice is between doing an incremental build (at a price of a small risk of failure) and only making one change a day (because the build takes too long), some organizations might choose speed.

Since each type of build requires a greater level of discipline and precision, it can catch anything that slips through in the earlier steps. The integration build can start with a clean workspace and be a full build that is done using “approved” configurations. Finally the release build will add finishing details that are not likely to cause errors, but which are time-consuming. This is not “sloppiness” or “laziness” but a realization that there is always a tradeoff between speed and stability.

These levels of scale are similar to the relationship between pre-checkin testing. A Smoke test may be adequate for many purposes even though it may not catch every problem that a long-running regression test does.

Having said all of that, the levels of scale are not a reason to defer having a process for all of your steps at the beginning of a cycle. Do not wait until the end of the product cycle to do a Release Build, or to address other deployment issues.

Of course, building the application is only part of the story. You need to do appropriate tests (Unit, smoke and regression) to achieve a good system.

Continuous Building

The various types of builds are related to the idea of “Continuous Integration.” By taking the build and deployment process seriously throughout the development process you are helping to ensure that the product makes steady steps forward. If one of the builds breaks, you at least have an early warning of problems in the codeline. Building early and often also helps to ensure that you don’t waste time on mechanical processes. Building early and often means that you can ensure build reproducibility (the build scripts work consistently, so you know how long a build will take, and the results of the build are useful for testing).

Building often (at all levels) helps you to ensure the integrity of your codelines. And the state of the codeline is a key to facilitating communication among stakeholders.

Building Agility

The value in leveraging these build patterns is that they are easy to do and repeatable. Where possible, use tools that fit into the development environment, and limit manual procedures. Even the best intentioned, most detail-oriented developers are susceptible to skipping a step if the processes are not automated. The agile community also values documented processes – not “double documented” processes, but documented processes. If you have an automated build process that produces an installable release, you have documented the process. Any developer/build manager can pick up the build script and determine the steps to building the application. “Double documented” processes are manual processes that contain written documentation, that oftentimes is out of date. In the case of having a process with outdated written documentation, it’s difficult if not impossible for a developer or build manager to execute the build process without having some other knowledge of the application before starting.

There are some tools and issues to consider when implementing these build patterns:

Build Dependencies: It’s very important to manage build dependencies by keeping them up-to-date (e.g. in Make or in ANT), and minimizing them for better recompile-times and fewer "conflicts." Keeping these dependencies clean and up-to-date pays back time and time again, providing