Coding Horror has a good post on what the low bar is for build processes, here. I just wanted to add an experience I am in the middle of.

I have been a big fan of build automation for a long time. The past few years, this has meant cruisecontrol.net, nant/msbuild, etc. I know from experience this is not the norm in corporate environments, and I think I know why.

For all the goodness you get from a process like this, it usually ends up being pretty fragile. You get some mystery build breakage and your day is shot. This is tough to work through in a corporate environment where the business perceives no value from what you are doing.

I used to feel bad about it, but there are times when I leave the build broken for quite a while - usually when I am the only developer on a project. There I said it. I broke the build.

• Maybe cruise control isn't configured right, and isn't getting a clean working copy.
• Maybe the cheap little VM running under someone's desk the hosts the build server is out of disk space.
• Maybe the xslt that turns the xml output from mbunit doesn't support some new attribute that mbunit is outputting.
• Maybe the reports we are looking at are actually from stale artifacts.
• Maybe a unit test runner is hung, holding a connection to a database the build process wants to drop and recreate...

These are all things that have happened at various times to break my builds. They were all a PIA to find too, when I don't have time for this. It's worse when you see someone else wanting to start down this road, and you think, "I want to help this person...but am I going to have time to answer their questions when the above things happen? Am I making work for myself?" Maintaining a build is a job, and when you're a corporate developer, it's usually not yours, even though we all see that it's important and somebody has to do it. It's the equivalent of making mo' when you kill the joe. But when you're not a barista, you're not going to be competing with Starbucks. That's the analogy: We don't have a Starbuck's build process and it's foolish to shoot for one. We're not starbucks, let's just shoot for having joe in the pot.

So...now that that's out of the way, I had to do some build maintenance a few weeks ago. My build is broken. It's not expected. I don't know why. Builds on my machine. I'll have to dig around and figure it out. I wasn't looking forward to it, so I thought I'd liven things up by checking out a tool I heard a good review of recently: CI Factory. So far, I am duly impressed. The only tough thing for a person like me is sticking to my stated goal (to my co-workers) going into using this tool: "I am tired of maintaing this crap. I just want to let someone else do it..."

CI Factory has strong opinions about where files should go, how the build should work, and how things in general should be organized. I had to change the way I worked in order to accommodate it, but it was worth it. I only had to make the easiest possible changes - basically it amounted to a couple of svn renames. In exchange, I got a very slick out of the version control system build experience. It's really nice. Checkout, and Bam! You've got a build server. Literally, "svn co svn://server/trunk/ProjectName C:\Projects\ProjectName\Current; C:\Projects\ProjectName\Current\Build\CCNetServer.bat". Two commands, and I am integrating. All the reports in ccnet worked out of the box. It found all my unit tests. I had coverage reports out of the box. All dependencies are in the VCS - even the CC Net server and config! That was something I hadn't tried before, but like I said, this software has an opinion.

The fine line is, when it doesn't quite do what I want, resisting the urge to change things. Everything you change, you have to maintain. I don't want to live like that anymore. I end up changing things as little as possible, and living with what CI Factory does for me.

I have wanted to write about this for a while, but have been waiting until I can say for sure that this has ended most of my build maintenance time sink. I think it's kind of safe to say that at this point. The only thing left I still have to deal with is a massive WiX script - this is for a web app that installs hundreds of files, which all need to be called out in the wxs.

The web app is actually a great example of where I went with the flow instead of creating more maintenance. This project has (had) an ASP.NET web site. I still kind of prefer web-site projects for various reasons, but I was having trouble getting the asp.net compiler + aspnet merge + the build + wix to work together, I was 5 minutes into editing a nant file, after half an hour prototyping the aspnet_* commands I wanted on the command line, when I realized I was swimming upstream. Why not just change to a web project. This was actually easier, took about 15 minutes, and I was done, no new maintenance work.

Anyway, if you are looking at setting up a build process, this seems like the best way to do it. You can't really go wrong, because it's just going to create a bunch of nant files for you and ask you to move your code around slightly. If you don't like it, you can leave at any time. It's not going to change your code, your project files, or anything like that. Give it a try!