Fog Creek Software
Discussion Board

Multiple Build Machines or Just One?

Am I supposed to have one build machine for each version of Windows that an application is targetted at?

Right now, whoever changes a program last builds it, as we don't have nightly builds (trying to change that).

Most applications are written in VB6, if it makes a difference.

If I could just get away with using Windows 2000 that would be great.

Tuesday, August 31, 2004

Get VMWare or Virtual PC (if you have MSDN it is included with it). This will let you simulate a complete PC with whatever OS you wish on a single PC. You can even run a virtual PC with Windows 2000 Server and connect to it with a virtual PC running Windows XP.

It isn't quite as nice as a real PC (it can be somewhat slow) but if you are simply testing for compatibility (as opposed to speed/performance) then they work great.

Tuesday, August 31, 2004

We have VMWare and MSDN and I am planning on making the build machine virtual for many reasons.

I'm not concerned about speed at all, I'm more concerned about doing it right. Currently we just compile them on whatever OS whoever compiles it has (Win2K or WinXP).

I want to eventually have automated builds, packaging, and testing.

Test machines are another story. I use VMWare to test the applications on all the Windows versions.

Tuesday, August 31, 2004

You should only have one build machine. It shouldn't matter which OS you have installed on there, as long as whatever build tools you have will run on it. Whether or not you do regular nightly builds, every "official" build should be done on  the same machine.

This helps to ensure consistency, which is the #1 goal of any rational build process.


Mark Bessey
Tuesday, August 31, 2004

> Am I supposed to have one build machine for each version of Windows that an application is targetted at?

Our ambition was to have a single build that would *run* on any O/S, so needed a separate *test* machine (not a separate build machine) for each O/S.

Christopher Wells
Tuesday, August 31, 2004

I have to agree with Mark, especially if you're only shipping 1 set of executables.  We have 1 official build machine.  Our build is actually 2 steps:
1.  Get proper version
2.  Build.
If anything breaks, it indicates that someone didn't check sonething in properly and broke the build.  It really helps that we have only 1 build machine.  This helps keep things consistent.

Wednesday, September 1, 2004

You need one build config, and as many test configs as you care to support.
Are you shipping source to the clients? Do you support several customer building configurations? In that case you'd want to test al these build configs. If you are not shipping source, or not supporting compilation by the customer, then stick to one build setup.

Just me (Sir to you)
Wednesday, September 1, 2004

Killer, you guys are the best.

Wednesday, September 1, 2004

One build machine may not work; it all depends on what components your software links into and if these components run (or not) across multiple os versions.

There are instances where you end up in a versioning problem which forces you to use multiple build machines.

Wednesday, September 1, 2004

*  Recent Topics

*  Fog Creek Home