The Code Whisperer

Following on from yesterday’s blog entry, this entry looks at how to create the one-click build process.

First of all one very important point. Never, ever, ever build a component for distribution on a developer’s pc. The reason for this is simple. The developer’s pc will, more than likely, contain additional applications that could have a bearing on how the components are compiled. Shared executable libraries are all well and good, but it’s too easy for applications to update shared libraries and then your application to expect a certain version of a library, which then isn’t available on a client’s pc. When this happens the application either fails to run or behaves unexpectedly. I have seen this too many times to even consider taking a short cut.

Instead use “virtual pc” software such as Microsoft’s Virtual PC/Virtual Server or VMWare to create a clean environment to compile and produce installation files on. This clean environment should have the target operating system with current service packs and updates, and the development environment and distribution tool installed. The virtual pc need to have access to the source control system and possibly shared drives on the network or the host pc. Please consider the licence implications of the virtual pc - this is no different from installing on a physical pc.

Before you start you need to have a think about version numbers. There are a number of factors to take into account when determining version numbering policy:

• To make your life easier, every component released outside your organisation has a different version number
• If a release isn’t publicly available but has been released for internal testing consider whether to increment the version number or not. Some customers may be concerned if the version number jumps between releases, but often this is because they aren’t aware of how the software is built. We use version numbers in the format major.minor.build and increment the build number every time the development team go through the build and distribute process and release to the test team. By doing this we can be assured of the version on the test team’s test rigs
• If you release all components of a multi-component application then they should, in my view, have the same version number
• Version the database too, if your application has one. This will make it easier to know when to apply updates to the database and make sure that the application and database versions match. We make sure that the major and minor version number of the application and database match as there won’t be individual database changes on a build only on a minor or major version number change

To create the one-click build process follow these action points, but run through the process manually first and document it - you may need to build the product by hand one day and you’ll be glad you wrote it down.

• Work out directory structures required, taking into account whether you want to retain the executables and other installation files for each release (not necessarily every build, as there may be more than one build per release). You will need the following locations, which can be locally on the virtual pc, on a network or shared drive with the host pc:
  • The source code from the source control system
  • Executables and other files generated from the build process
  • Other files required for the installation, such as configuration files, database scripts and help files
  • Distribution files including release notes
• I would expect to have one master script that calls the individual elements. You could do this as a smart GUI, but a batch script is perfectly OK provided as much logging as possible is carried out, so that you can diagnose problems if something goes wrong. The script or application you create could also be used to create a nightly build process (which I’ll cover in a later post), so more batch like is beneficial. It’s useful to consider notification if a problem occurs, possibly by email or SMS. Create the shell of this to begin with and add or integrate the individual elements as you proceed.
• If you aren’t using a tool to automate the interaction with your source control system, you will need to write a script or application to extract the latest version of files, check files out and in and, if you want to label the source code, you need to be able to apply a label. Microsoft’s SourceSafe has a documented API so can be manipulated by a number of programming tools, including VBScript and various version of Microsoft’s Visual Studio. Although I’ve not tried it, you could use non-Microsoft development tools such as RealBasic and Delphi, but the chances are if you’re using SourceSafe you’re using Visual Studio in any case. Other source control systems such as Subversion also have APIs or cam be accessed via WebDAV extensions. So, first task is to create scripts or an application to perform the previously mentioned tasks on your source control system in a batch environment. At this stage in the build you will need to extract the latest version of source files, apply a build started label if you are labelling source control and check out files if applying a version number change.
• Next you need to build the components, changing the version number if your version numbering policy dictates this. How this is done is dependant on the development tool being used and applications that have more than one executable component will require a compile order. Some development tools, such as RealBasic, create one executable, so this step is much easier. If you are using a build tool it should work out component dependencies for you and compile in the correct order.
• Any files checked out need to be checked back in and if labelling a build complete label needs to be applied.
• Create a script to copy the executable files and any other files needed for the installation to the location determined earlier.
• Use the distribution tool to create the installation file(s) in the directory determined earlier.

You now have a distribution that can be tested and released. Once you have a public release I highly recommend you make some backups:

• On a CD or DVD burn the source code, build scripts, other installation files and if you have them project files from the build and distribution. Ideally keep this backup away from the office
• Depending on your licence agreement, make a backup of the virtual pc used and store away from the office

The reason for backing up is two-fold. Firstly there’s the normal disaster recovery aspect and secondly if you have to go back to a previous release, make a change and re-release that version having backups will make the job a lot easier and error prone.