The Code Whisperer

When creating a software product much of the focus is on the design/code/test part of the lifecycle. But having created a product there needs to be a method for distributing it and providing updates. There are a number of products that will help you create installation routines, specific for the platform being deployed to and to an extent the development tool being used, from a simple self-extracting zip file to Windows MSI. This post isn’t about these products, but the management of the build and distribution process.

One vital ingredient to the build process is the source control system used. I’m making no assumption about the source control system used, except for the ability to somehow isolate the code being built. This could be by having a branch for the release version or by labelling the source code with the release version (consider also labelling the source twice, once when the build starts and then when the build is complete in case code has to be changed and to accommodate an update in version numbers). Employing both practises of branching and labelling is OK too, and essential if you have just one release branch, rather than only one release in a branch. For the purposes of this post it doesn’t matter how this is achieved, just that it’s possible to identify the code that went into a release at a certain date.

My ideal scenario with builds is to start a program or script that retrieves the latest version of the source code, including database scripts if they are being used, label or branch to suit your source control set up (this may have to be a manual job), build the components in the correct order, update version numbers for the components, updating the source control system with the new version numbers and manipulating the distribution tool to create the installation file or files. I call this the “one-click” build process.

The reason for this ideal is simple. Building a release is a time consuming, error prone, boring task that is best automated. In most cases the person creating the release is simply following a list of tasks, hopefully written down not in his or her head, so why not automate it? There will come a time when it’s late and you need to get a release out of the door and the last thing you want to do is manually create a build and risk introducing an error you may not discover until the process is finished, when you could simply launch a script and have a well earned cup of coffee.

Getting to a state where you can build a product with one-click won’t happen overnight, but some planning as early on in the project will make setting up one-click builds nice and smooth. I’ve assumed the following:

• Your development tools have the facility to compile from the command line or can use a tool to do this. Some build tools will handle the source control integration and version number updates for you.
• Your source control system is scriptable in some way, so that the latest version of files can be extracted, files checked out and checked back in and, if you want to label the source code, you need to be able to apply a label. As mentioned in the previous point, build tools can sometimes do these steps for you.
• The tool or method used for distribution can be scripted.
• Your bug tracking system can produce a list of fixes for a specific release (or the “next” release). This isn’t vital, but is one manual step removed from the process.

In the next post we’ll look at the one-click build process in some detail.