The Magical Build Machine

Jeff Atwood

06 Dec 2004 — 2 min read — Comments

Evidently, Jerry Dennany is a member of the build machine cult:

One of the golden rules of modern software development is that one should build all software on a dedicated build machine.

A build machine should:

1. Be well documented. This includes Version of the Operating System, Service Pack level, HotFixes installed, Tools installed, along with any special installation instructions.

2. Be easily reproducible. Anyone on your development team should be able to take the documentation, the build machine, and any required installation media, and recreate that build machine on demand. If you can’t, then you don’t know what exactly is in your product.

3. Not contain a single piece of software not related to the build. For example, just because your project uses crystal reports does not mean that you need crystal reports on the build machine.

4. Be in an area that is controlled in its access, if at all possible. If this is not possible, then you should control who may log onto the computer.

5. Be under change control. No change to the build machine should take place unless that change is documented and approved.

A few things not to do:

1. Never make the build computer a developer’s workstation!

2. Never do anything with the build computer except build that version of software. I strongly suggest using a disk image tool such as Ghost to re-image after every build. You don’t get much more of a ‘known state’ than this. This was actually very important in the VB6 / COM world.

While I am all for daily and even hourly builds, I strongly disagree with the perpetuation of the Magical Build Machine concept. It’s a bad idea.

The magical build machine reinforces the disconnect between developers and users – “us” and “them.” It runs on my box! Every developer on the team should understand how to produce a reliable build from their own machine. A build that runs on the webserver. A build that runs on the end users’ PC. And if it doesn’t run, they should know how to troubleshoot it. It is every developer’s responsibility to write responsible code, code that doesn’t cause a lot of deployment problems. If you isolate developers from this process, you do so at your own risk.
If you use a magical build machine, you’re implying that your project is so complicated to build that it takes special voodoo to get it to run. Sacrifice a chicken, sprinkle salt over your shoulder, then re-image the build machine when the stars are perfectly aligned. That’s the only way to get a “clean” build! A project that is this difficult to build does not inspire confidence. It also smacks of voodoo programming or programming by coincidence.
Using a magical build machine perpetuates the idea that building and deployment is risky and incredibly sensitive to the exact client configuration. Jerry correctly points out that deployment was a big deal in the bad old days of VB6 and COM – aka “dll hell.” On a correctly architected .NET project, this absolutely should not be true! One of the major selling points for .NET is ease of deployment:

Is the .NET runtime installed?
Xcopy files to a folder.
Run your app!

There are absolutely valid reasons to have a controlled build process. I’m not proposing that every developer build the project and deploy it at will. Use a build machine if it makes sense for your project, but be careful that you aren’t injecting any accidental “magic” into your development process along the way.

What does Stack Overflow want to be when it grows up?

I sometimes get asked by regular people in the actual real world what it is that I do for a living, and here’s my 15 second answer: We built a sort of Wikipedia website for computer programmers to post questions and answers. It’s called Stack Overflow. As of

Civilized Discourse Construction Kit

Occasionally, startups will ask me for advice. That's a shame, because I am a terrible person to ask for advice. The conversation usually goes something like this: We'd love to get your expert advice on our thing. I probably don't use your thing. Even

How to Stop Sucking and Be Awesome Instead

I've been fortunate to have some measure of success in my life, primarily through this very blog over the last eight years, and in creating Stack Overflow and Stack Exchange over the last four years. With the birth of our twin girls, I've had a few

Books: Bits vs. Atoms

I adore words, but let's face it: books suck. More specifically, so many beautiful ideas have been helplessly trapped in physical made-of-atoms books for the last few centuries. How do books suck? Let me count the ways: * They are heavy. * They take up too much space. * They have