CM: THE NEXT GENERATION of Build Management

so that the build is self-identifying.It must also be used for identifying the target of verification test sessions.And it must be possible, at all times with the CM tool, to select by build name a viewing context which exactly matches the build contents.

Ideally, the build identifier would be attached to any problem report raised against the product.The build identifier is a central component of traceability, because each build, and the set of operations performed with it, encapsulate a huge amount of information:what tests have been run against it? what problems have been fixed? where is the build deployed?what source revisions are used to create it?what new features are incorporated into it?

Builds as the Key Point of Comparison
In some cases, these questions are really questions of comparison: What problems have been fixed since the previous build? or What problems have been fixed since the build that we're currently using at our site?Except, perhaps for source deltas, which are generally performed at an Update/Change Package level, or sometimes at a file level, builds are one of the most natural points of comparison.One reason is that when a build breaks, you want to compare it to what went into the last (successful) build.Another is that a customer always wants to know what new features/fixes they receive by moving to a new release (i.e. at a specific build level).Another is that the comparison is usually at a more macro and meaningful level than, say, source code or file revisions, although there should be no reason why you can't do a source delta between two builds. More often though one is concerned with the list of changes, problems, features, test results, etc.

Build comparison helps to focus initial integration testing on the problems fixed and features introduced.It helps to trace down build problems by allowing a quick look at the newly introduced changes, hopefully with a drill down capability so that suspicious changes can be directly inspected.It helps to generate release notes.But all of this assumes there is appropriate traceability between the builds and changes, and the changes and their driving requests.

Build Automation
I've seen companies that perform system builds every weekend.I've seen others that perform hundreds of builds every night.In both cases automation is important, not only because it reduces effort, but even moreso because it helps to eliminate human error.Build automation requires a number of components to be in place:the build tools, the build platforms, the build dependencies and the build definiition.

One aspect of build automation deals with retrieving and executing Make files or other Build Scripts.However, some tools support the generation of these Make files and Build Scripts. In this case, both the developer and build manager have their workload simplified as they don't have to manually maintain these scripts. In some cases, build automation must deal with distributing the build function across multiple machines and differing platforms.Normally, it is the build tools themselves which help to contol this distribution function, and so from the CM/ALM tool perspective, the question becomes more one of integration with build tools.

Deployment
When we talk about Deployment there are many different aspects that can apply to any given environment.These include:

• Deploying software to the build machine(s) for the build operations

• Deploying web pages to a web server, and potentially multiple versions of the web pages

• Deploying built software on the set of machines machines (e.g. for in-house operations)

• Automatically allowing uploading of new software from a central site (pulling)

• Deploying files for building packages that are to be used for downloading software

• Delivering download packages