Get a Build Server and Keep it Clean

The importance of a clean build server was reinforced for me this morning.  We’re getting ready to wrap up our first demonstration of our executable for users in a different timezone in London.  Everything is wonderful on our developer workstations, but not so good on a clean box.  It’s the normal culprit, a 3rd party control library needs some licensing info embedded into an assembly or has to be installed or something else.  We found the problem easy enough before it hit the end users because we run the client on our build box that doesn’t have Visual Studio or the control libraries installed into the GAC.  A clean build server finds these problems for you fast so the customer or testers don’t.  Whatever you do, don’t put Visual Studio on your build box because it can fool you into thinking your installation script is complete when it only really works because of the assemblies that VS GAC’s for you.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Continuous Integration. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://archlever.blogspot.com/ Jeff Dickey

    Jeremy,
    I think you’re absolutely right with both the “so much advantage” and “anywhere but a developer workstation” comments. Microsoft have been very, very good to me all through my career, but even when I’m hired by folks who run all- or nearly all-Windows shops, I find myself using Microsoft tools less and less, for exactly these reasons. (Having shifted to about 80% Web development helps, too.)

    Microsoft have just completely lost sight of what it’s like to develop anything better than bare-minimum-mediocre software in an environment where the end users (and testers, and etc.) are running significantly different (cleaner) systems than the developers. If all the developers have all the Office and (Microsoft) business apps on their systems, and all the end users have full VS-and-kitchen-sink stacks on theirs, this problem goes away (and Microsoft gets more money, of course).

    But sooner or later Microsoft are going to have to get past the Jerry Michalski model of customers-as-consumers. As developers, we should have a reflexive impulse to eliminate dependencies EXCEPT where the gain from including a dependency decisively outweighs the pain of managing the dependency AND at the same time is greater than what could be accomplished in the given situation without that dependency.

    We’ve still got a long, long way to go before the development process resembles engineering more than (honest) craftwork.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Mary,

    One way or another, you want the “official, to be deployed into production” builds done anywhere but a developer workstation, preferably by checking out the correct version from source control and building on the spot. If you build directly in Visual Studio you’re effectively compromising your source control management and opening the door for a host of problems because it’s very easy to miss code on a developer workstation that isn’t checked in yet.

    The teams I’ve worked on for the last 4 years have used Continuous Integration systems with CruiseControl.Net & NAnt or MSBuild. When it’s time to ship or deploy to a testing server, I just take the latest build on the build server.

  • Mary

    do you build on a visual studio 2005 and then rebuild it using msbuild on a build machine or what is the recommended process?
    THank you

  • http://flimflan.com/blog Joshua Flanagan

    Absolutely. The reason my blog post on how to get around it is “half finished” is that I eventually decided all the hassle wasn’t worth it, and reverted to the open source tools. I’d rather encourage others to do the same, rather than tell people how to keep fighting Microsoft’s tools.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Josh,

    That whole paragraph is an awfully good argument for me on keeping the NAnt stack alive and kicking. There’s just so much advantage in having tools that were written by the developers who use them versus having tool developers write tools that they don’t use themselves.

  • http://flimflan.com/blog Joshua Flanagan

    No, unfortunately, he is not kidding. In order to run MSTest, you need Visual Studio on the build server. In order to run Code Analysis (formerly FxCop), you need Visual Studio on the build server. In order to check code out of TFS, you need Visual Studio on the build server. Its mind boggling, really. They come out with MSBuild with the great pitch “you can now compile your projects without Visual Studio”, and in the same release they throw in all this extra stuff that DOES require Visual Studio.

    Now, to be completely honest, none of this is REALLY true. You can hack around with the default MSBuild targets files, find the correct EXEs (MSTest, FxCop) and assemblies (TFS client) on a machine where VS is installed, and include them in a tools folder of you source code repository, just as you would with nunit.exe. You can then run all that stuff on your build server, without VS. But that is completely undocumented (though, I have a half-finished blog post on it), and probably illegal (license violation).

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Ralf,

    You’re kidding, right? I thought there was an executable as part of MSBuild for MSTest. It’s not the end of the world, but you’re right that it’s one more little reason to stick to the OSS stack.

  • http://rkse.blogspot.com/ ralfkret

    Yes you are right. One more reason one shall not use MSTest for unit testing. An installation of VS is required on the build box – eehhh and maybe a licence as well.

  • http://community.hdri.net/blogs/chads_blog cmyers

    Jeremy, you’ve done several “Thou shalt…” posts like this. You should compile them into some type of permanent artifact (can you do that on codebetter.com?) and call it something like ‘Jeremy’s Umpteen Commandments’.

    Here’s today’s addition:
    IV. Thou shalt remember the Build Server, and keep it holy.

  • http://jayflowers.com Jay Flowers

    Ahh I did not think about the Third Party stuff that comes bundled with VS. I have never installed any of that stuff as I have never needed it.

    I was concerned that VS, not the installer, was going and putting stuff in the GAC.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Jay,

    The immediate example that came to my mind is Crystal reports that gets installed with VS. Think about 3rd party control libraries that you install that put stuff in the GAC. The code will work on your own box just fine, but simply doing an XCopy from the bin/debug or bin/release folder isn’t good enough anymore because the build server won’t necessarily have those assemblies in its GAC.

    It basically points out the places where you need to add things to your build and deployment scripts on clean boxes.

    Does that help?

  • http://jayflowers.com Jay Flowers

    So I don’t follow you.
    When does, Which ones does, Why does: VS put assemblies into the GAC for me?