Personal overnight builds

2006-10-09 • , • Comments

Recently I wrote about personal version control — my habit of keeping personal configuration files, scripts and similar under version control. One of the scripts which I control in this way is my personal overnight build script.

What’s an overnight build?

A well organised software project typically has an overnight build which runs on a dedicated machine (or even dedicated machines) and does something like:

  1. performs a clean check out of all the source code
  2. builds everything
  3. tests everything
  4. collates and publishes test results

Typically, the overnight build is scheduled to run overnight because:

  1. it takes a while (since everything means everything — release, debug, installer, documentation …)
  2. the source repository may be in a state of flux during the day

Sometimes, in addition to this overnight build, an incremental build runs during the day — but that’s another story.

What’s a personal overnight build?

A personal overnight build does something very similar. The only essential difference between my overnight build and the scheduled one is that I update a working copy rather than perform a clean checkout.

In essence, the script I run looks like this:

my_build.sh
#!/bin/sh
# Change to working copy, capture differences, update, build.
cd /home/tag/dev && svn diff -u && svn update && make all

I then create a cronjob to run this build at 3 in the morning on weekdays:

cronjob
0 3 * * 1-5 /home/tag/bin/my_build.sh > /home/tag/build.log 2>&1

(Note, incidentally, that I redirect output to a log file, rather than have cron email me the results.)

Why bother?

Because I’m lazy. I found myself performing the same mechanical sequence of actions every morning: check what’s changed, review the changes, update, rebuild. A machine could do it for me – so now a machine does do it for me. I start every day up to date.

Of course, there’s no reason why a personal overnight build should only run overnight. Once you have the script in place, you can kick it off by hand when you go for lunch, or sit down for a planning meeting. Equally, there’s no reason why a personal build should only run on one machine. If you’re developing portable code you should port it all the time.