TeamCity build steps are not the way forward

I have a lot of love for TeamCity, and one of the many things that makes it easy to get a build configuration up and running is its concept of “build steps“.

Recently, however, I’ve started to worry about our use (or abuse) of them. My main concern is the fact that it can make it very hard to reproduce a failing build (works on my machine!).

There’s always going to be some differences between the build running on the CI server, and my local build (hardware, installed software, timing, etc). But I’d like to reduce them to the bare minimum. It’s bad enough that I’m running a sh*tty laptop with XP, while the build agent is on 64 bit Server 2008, without having a completely different build process.

I was never a fan of MSBuild, but at least having a build script in with the sauce meant that you could run a local build before checking in.

Some of our build configs now have up to 8 build steps (StyleCop, NuGet install & update, build, test, source index, NuGet pack & publish, etc), any of which could cause a build to fail without being easily reproduced locally. Which encourages people to just check in, and hope for the best. And the slow feedback cycle when trying to fix an issue is a real gumption trap.

So, what’s the alternative? I couldn’t face going back to an xml based build tool (e.g. NAnt or MSBuild), but a scripting language like Ruby (Rake) or Powershell is ideal. In our case, I’d like to replace the steps with a build.ps1 (and some shared modules for common tasks).

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s