Fog Creek Software
Discussion Board

Making a Build in One Step

Making a build in one step is part of the 'Joel Test', but there is one little thing that bugs me about this.

Won't the build script be under version control?  Therefore the build process really involves 2 steps:

1) checkout the latest build script
2) run the build script

OK, so why not combine those 2 steps into a simple 2 line script you say?  Well, what happens when some subtle details change meaning you have to change your 'simple 2 line script'?  Oops, before you know it you have 10 different versions of a 20 line perl maintenance nightmare :-)

Obviously there are solutions which can make it a single step, such as automatically distributing new versions of the build script whenever they are checked into version control.  Is this sort of thing common?

The situation becomes a more complicated when you are maintaining multiple versions of a product, for example one version per customer :-).

Interested in hearing what approaches are being used.


Peter McKenzie
Monday, October 7, 2002

You can use a small bootstrap script that does the checkout and launches the main script. The small bootstrap script never changes.

Joel Spolsky
Monday, October 7, 2002


One step: Check in your source.

Monday, October 7, 2002

On second thought, I was a bit quick to post. CruiseControl is really handy, but it doesn't eliminate the bootstrapping issue because you really ought to do a build on your local machine before you check it in. CruiseControl uses ant to build, so if you play your cards right, you'll have a nice portable build process. You could use this alongside Joel's bootstrap script too.

Monday, October 7, 2002

Thanks for the replies.
Joel's bootstrap idea is basically my 'combine those 2 steps into a simple 2 line script', but I think I was being excessively paranoid assuming the bootstrap script would need to be maintained beyond an absolutely basic level (eg. you change version control systems).

Peter McKenzie
Monday, October 7, 2002

I've seen one-step builds done via a web interface, which was kind of neat. You had the opportunity to customise the build (e.g. compile a specific stream, or compile against a checkpoint label from the past), but you could just click the button to compile from the latest base stream version. The web app checked out the appropriate source code and compiled on a big fast server.

We also do nightly builds via a cron job, and weekly builds that are a bit more formalised but run against an automated test suite.

Darren Collins
Monday, October 7, 2002

I'm currently working to address this very problem on an existing build system that uses 4 different compilers on two different operating systems to build one software product (yeah, I know - but that's going to be a lot harder to fix).

The solution we've settled on is a relatively simple Perl script that checks out the "real" build script and runs it. Of course, this'd be easier to do if we didn't have an already working system in place.

We have to be compatible with the "old" and "new" versions of the build script, which evolved pretty significantly over time. I'm hoping that we can manage to build the last couple of released versions, at least.


Mark Bessey
Tuesday, October 8, 2002

Perhaps I'm being a bit naiive, but how often does the build script need to change?

Why not allow a read-only copy of the build script to "live" on the build server. The build script is still in Source Safe, but this would prevent having to do a Get on the build script to execute it. If and when the build script needs to change, simply update the copy on the build server.

This is what we do and it works great.

Monday, October 28, 2002

*  Recent Topics

*  Fog Creek Home