Agile SCM – Build Management for an Agile Team

and time again, providing many of the same benefits of keeping automated test scripts current. A common practice is to use utilities and compiler-flags to automate the process of updating build dependencies (often making them another form of build-target, e.g., "depend").

Build Architecture : The Build system "architecture" (e.g. what aspects of the directory tree structure are the way they are, and how things get split up across multiple Make/ANT files) should support reproducibility, testability of smaller units, and faster builds (and/or parallelism). The structure of the source directory tree needs to meet several sets of needs. Sometimes build-time performance dominates certain source-tree structuring decisions about the location of frequently accessed interfaces and definitions (e.g., "header files"). Symbolic links or "short cuts" can help minimize the impact upon the perceived "closeness" of related files that are often modified together.

Multiple Build Types, Single Build Mechanism : Even though there may be several different types of build, it is usually easiest to employ the same or similar mechanism to initiate each kind of build. The same set of files and scripts can be used to define (and parameterize) the different types of build and a simple change in the invocation or environment can specify which kind of build is to be produced using the same basic build scripts and infrastructure.

Improving Build Performance

The "agile" slant on this column is really about trying to accomplish SCM standards while actually improving developer productivity and software quality.  With this in mind, one of the key benefits of automating a build is to create a baseline from which to improve build performance.  Too often, build times take too long - sometimes more than one hour.  Developers get around this in sometimes unhealthy ways to decrease the impact on "their" development times.  Through automation, there are some of the ways to improve build times on projects that are large and/or have long build times.

• Storing intermediate targets in the repository to improve incremental build times;
• Appropriately breaking projects into independently buildable modules that create run-time dependencies (project architecture);
• Throw more hardware at it - we can again show how 10 minutes saved on a build process can save, for a single developer doing 6 builds per day, one hour of productive development time each day. It doesn't take many days to pay for a faster build machine;
• Different build utilities can produce very different response times. Consider compile and link times when considering your compiler and linker for your project. There are often several alternatives.

Building Values

Earlier we discussed some values for Agile SCM. Here is a brief review of how using good build patterns fits in with the "agile" values of the Agile Manifesto:

Individuals and Interactions over Processes and Tools: SCM processes and tools should support the way that you work, not the other way around. Pick tools that fit into the environment so that developers will use them. There are many tools that have good qualities that do not help the quality of your codeline because no one uses them. A favorite example: tools that are so expensive that you can only have a few people doing builds. Everyone on the development team should be able to build (at least a Private System Build) at will.

Working Software over Comprehensive Documentation: SCM can automate development policies and processes with executable knowledge rather than have the team rely on documented knowledge. Describe your build processes using scripts rather than procedures. This is especially important if you find yourself working late.

Customer Collaboration over Contract Negotiation: SCM can facilitate communication and interaction among