Build and Release – a match made in heaven?

So I’ve taken to digging a bit deeper into the build side of things, so please don’t be upset if this turns into more of a build automation blog… It’s just where I’m spending a lot of my time lately.

I’ve started to see Release Management as a bit closer to the business side of things, and looking at what I do as more “build and deployment automation”. At my previous job (where I was when I started this blog), I did pretty much everything form managing SVN, to automating builds and deployments, to managing a bunch of servers. Since getting out of Academia and into the “real world” of business, I’ve noticed that these roles tend to be a little more separated.

Now that I’m consulting, I even made a little online resume thingie for your enjoyment – check it out!

I am available for consulting too! Wouldn’t it be neat to be able to say you hired the guy who “wrote the blog” on release management? šŸ™‚

Right now, I’m working on helping a small software company in Silicon Valley automate the heck out of their build. We’ve got a desktop app written in C#, and we didn’t really have any automated builds at all. It’s pretty cool walking into a place that has a clean slate, and being able to completely build out a system from scratch.

I can’t really say I love working with MSFT products anymore, I think I’ve gotten spoiled with the explicit and transparent nature of working with Linux/Java stuff. It seems like MSTF is trying to do everything for you, which is cool until things start breaking and you need to troubleshoot. OK, that’s my mini MSFT-bashing rant, I’ll stop now, I promise.

So Bill G and the Gang have some pretty interesting little tools together, most notably MSBuild in conjunction with Team Foundation Services. I can’t say I love it, but it does (sort of) work. I pretty much eschewed their whole solution, and just wrapped a call to MSBuild inside my ANT scripts, and then wrapped that in CruiseControl.NET for scheduling of builds and for email notifications on builds events. It all seems to work pretty well, the only real hiccup was getting ANT to play nicely with Team Foundation’s source control.

I just use the tf.exe command line client form an exec inside my ANT script, but it’s not pretty. Mostly cuz doing a “get” makes everything read-only (kinda like vss), and that doesn’t really work for me cuz the build actually produces some artifacts/shuffles around some files. Since I don’t really know what MSBuild is up to behind the scenes, I ended up just making them writable after “get”ing them using hte old “attrib” command. Weak sauce.

Other than that, CruiseControl.NET seems to be pretty happy. We’ve now got nightly builds popping, and all is good in the world. Now if I could only get my hands on a decent GUI based testing tool for WinForms, then I could run a handful of smoke/regression tests after the build happens, so we know we didn’t break anything…

4 Responses to “Build and Release – a match made in heaven?”

  1. Julian Simpson Says:

    I’d agree. Build and Release should dovetail together very simply. Quite often they don’t, and I think this can be because project build are often implemented with the goal of ‘just building this thing’, not ‘making a release candidate’.

  2. Nilesh Says:


    I am a .net developer and being senior most in my project i landed up in a similar job like yours. I enjoy the thingie and planning to mold my career in the field.
    Looking forward to read your blog šŸ™‚

    • theReleaseGuy Says:

      Hi Nilesh,

      Ahh yes, that’s how it happens sometimes. I also came from a development background and got asked to take on this role. I’ve actually grown to like this kind of stuff better than coding features and fixing bugs – I hope you do too!

      Best of luck, and please feel free to use this blog as a resource. If you like, I could even add you to the authors list in case you’d like to post here from time to time. Just let me know.

  3. Pradyp Says:


    The whole mighty purpose of setting up an “automated” build is to get to Release Candidates as robustly as possible and avoid human errors. Though I agree with you to some extent that Automated Build just builds the app but one needs to remember there are so many things that you can build into autmated (nightly. weekly or OnDemand) build to reduce testing efforts, avoid human errros, and have component based tested as part of testing life cycle, which reduces time and overall cost of reaching a solid release candidate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: