Jeff Atwood picked up on my recent thoughts on central build machines…
I’m certainly complemented that he took the time to post a rebuttal. And, I don’t necessarily disagree with him. Jeff sounds like a smart guy, and I’m certain that he will make certain that his builds are done properly. However, not everyone is as smart as Jeff. Let me outline a few very common problems that build machines solve:
1. Reproducible builds.
As we build prototypes, and then move from prototype to development, a common scenario is for a developer to download an SDK to enable development of a particular feature or component. Often, this SDK will have particular installation options or settings. If the settings are different on different developers workstations, the software may build correctly, but functionality may be quite different. I’ve personally experienced this on several projects.
2. COM interface definitions.
A) This was a common problem, and manifests differently depending on what language you are using. For example, in Visual Basic 6, the previous COM binary was required for COM compatibility purposes. If you didn’t have the same binary, then you would get different GUIDs for the Interface definitions. This was very big problems on large VB6 COM projects, and one that is easily solved with a combination of source control and build machine(s).
3. Circular build dependencies.
These are very common in large, non-trivial C++ projects. They are often not noticed on developer workstations, as devs rarely do a “from-scratch” build from source control, and are more likely to perform partial builds in an iterative code-compile-debug process. Build machines quickly catch this problem.
There are many more arguments for Build Machines, and few of them have reference to sacrificing chickens, as Jeff suggests in his mildly compelling dissertation. Instead of droning on, however, instead I’ll directly rebut a few of Jeff’s points:
* Every developer on the team should understand how to produce a reliable build from their own machine
I agree wholeheartedly. In fact, I go further, to point out in my original statement that “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 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.
I’m trying to remove the “voodoo” aspect by documenting and scripting a reproducible build. I’d make the counter-argument that builds performed on a developer’s workstation are more likely to be a voodoo byproduct… Sprinkle a little eye of newt, some make && make install, and you’ve got everything you need!
* Using a magical build machine perpetuates the idea that building and deployment is risky and incredibly sensitive to the exact client configuration
In large, non-trivial projects, this is likely still true, even in the days of .NET. Xcopy is for the naïve.
It’s fun to have someone to disagree with – Thanks, Jeff!