How well can you recreate a specific build?

"Hey, Richard! You know that special build we created for Joe Jackson a few months back?"

I knew it well. Joe's business was mostly conducted online and required a special scenario that would cost him thousands of dollars if our software didn't recognize and handle it properly. He was also one of our most loyal customers. As a result, a co-worker had postponed his retirement to work on it.

"Well Joe's web host went up in flames last night, and nobody had an off-site copy of the CD. For some reason it's not in the release archives either. Do you have a copy of it somewhere?"

For some teams, a scenario like that would be a complete nightmare - especially if the outgoing developer had chosen not to use a reproducible build process. Even worse, the now departed developer may not even have used source code control, and the IT department may have reformatted the disk and given the computer to someone else.

So how good is your process? If this was one of your projects could you recreate the special build on demand to help your customer? If you couldn't, do you think the customer would be as willing to do business with you again in the future?

For the Agile Toolsmith, this type of request holds no major horrors. In an ideal scenario, not only is the product source code available from version control, but also the applicable unit tests, dependent libraries, build and publication scripts, and sometimes even the build tools themselves. Recreating a specific product becomes as simple as retrieving the right revision from source code control, and triggering the build process. No additional interaction should be needed until the process completes, at which time you are left with a CD image, ready to be converted into a physical CD, or a setup file which can be sent to the customer.

For a reproducible process, the following will typically be true:

• After it has been launched, the process requires no user interaction.

• The process verifies any prerequisite which is not available from source control.

• The process does not change any source controlled files.

• The process does not depend on any machine specific settings. (It should be possible to perform the build on any machine, even a completely new one, as long as the prerequisites are met.)

• The process is complete. (There should be no additional manual steps which always need to be performed).

• If a part of the process fails, that failure is clearly indicated. (Ideally, the process also halts as soon as possible after such a failure has been detected.)

Of course, not all of these goals will be possible for all projects. In particular, automated testing (especially of a user interface) can be very difficult and/or costly. As a toolsmith, especially an agile one, you must always remember that a tool's purpose it to help do your job. It should never get in the way of getting the job done. A tool will also not do your job for you, no matter how good it is.