Daily Build

By Rik Heywood
11 January, 2002

Recently I have been working on new tool to automate my daily build procedure. I am a firm believer that it is important to build every aspect of a product that is being developed, every single day. A daily build quickly draws your attention to problems, such as missing files, broken source code and bad installers. 

Another important benefit is that as you approach that critical gold master CD that is sent off for mass duplication, you are on familiar ground. You compile all the source code, just like every day for the last 18 months. You gather all the data files from where ever they live on the network, package them together and build the installer, just like you did every day for the last 18 months. If you don't have a regular daily build procedure then you will have to remember 100's of little steps to create your product correctly. Maybe you need to define FINAL_RELEASE when you compile the program. Perhaps you have to make sure Dave has run the tool that converts all the sound files to the correct format. If all this isn't automated, it is easy to make mistakes and get yourself in trouble.

I remember one project I worked on that didn't have a daily build procedure. Instead, one of the developers was the man that made the master CD's. He knew about the important defines when compiling, he knew where to find all the data files, he knew who to hassle when things were missing. Sadly he was on holiday the day we finished and no one else knew how to build the game. It was almost a week before he was back in the office, and when he did get back, he was not too sure he could remember if he had done everything right (he hadn't built everything for a couple of weeks after all). The publisher was furious.

One of my current projects (Crazy Car Championship) has many small steps that need to be performed to get an installer for the game that can be burnt onto a CD. It goes roughly like this...

• Update the build number, so we know which version testers are finding problems in and can go back to the source code for this version at a later date. This involves checking files out of the source control database, changing them and checking them back in again.
• Building Cipher, the game engine that CCC is built on.
• Building all the game code as DLLs and bytecode (the bytecode versions are cross platform and are run on Ciphers virtual machine).
• Build the games pak file. This file contains all the resources for the game (models, textures, sounds, music etc), so I must collect these files up from where ever they live and compress them into the pak file.
• Copy the appropriate files to somewhere the installer expects them to be.
• Build the installer
• Create the CD image from the installer files.

Daily Build to the Rescue

This is where the tool I have been writing comes into play. Its purpose is to condense all the knowledge about how to build a product and automatically build it every day, without human intervention, and it is currently called Daily Build.

Daily Build is almost finished now. All of its core functionality is in place and working fine and I am using it every day. There is something strangely satisfying about starting work in the morning and reading the "CCC daily build completed OK" e-mail message waiting for me.

When I have finished off the documentation and added a couple of extra minor features, I will probably release this tool. I suspect too many developers depend on just remembering all the steps to create their company's products.

[Update: Daily Build has now been released. Learn all about it and download a version to play with.]