Build Machines, Redux...

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!

 

4 Comments

  • Here here to dedicated build machines!

  • It's true that we agree on some central points.



    What I object to is the implicit assertion that it's somehow OK to have a complicated build process. It's not.



    > Xcopy is for the naïve.



    Xcopy is the gold standard for correctly architected .NET software projects. We should always be working toward that goal, not putting in processes that make it easy for us to backslide into the bad old days. That's the whole point of Microsoft abandoning the registry, COM+, and all the other associated meta-dependencies that made our life hell for so many years.



    If it's broken, take the time to FIX THE PROCESS. Don't just treat the symptoms of the disease, as MS did for so many years prior to the giant .NET rearchitecture.



    Maybe the best compromise is to have a Virtual PC "build machine" that developers can get to from a network share. But I still think that's too much rope to hang ourselves with.

  • I have had so much trouble with XCopy installations that I never use them any more.



    The problem is, it takes too much thought to decide what to xcopy. Far to often I have seen files on severs that just should not be there. For example aspx.cs files, pdb files and the like.



    XCopy also does not create file associations, uninstall, repair install, registry settings, Windows Service registration or any of the other nice things that set-up projects give you.



    Given that set-up projects are so easy to create I don't get why people don't use them.



    Martin

  • Forgot something about XCopy.



    Have you ever tried telling a post room clark how to install something from the other end of the phone?



    Saying "Stick the CD in the drive and run Setup.exe" might get you somewhere.



    Saying "Create a directory under the program files directory. Now copy all the files from the CD to this directory. Now go to the start menu and create a short cut." wont get you far.

Comments have been disabled for this content.