Is your Build resilient?

The Story

Today I walked in the client’s office (just like any other normal day) not suspecting there’s anything wrong. After 5 min one of the managers approached me and started asking questions about the new TFS Build server that I added two days ago. So here’s what happened:

The client is a pretty big house, and they use on-premises TFS. To my surprise they had only one build agent installed and that one was alongside the TFS server on the same box. If you wonder how long was the build queue: well, LONG!

So two days ago I decided to end this nightmare. I was about to configure Continuous Delivery using TFS and Octopus and since my build was sitting in the queue for over 45 min I asked for another server where I installed 4 new build agents and plugged this server into the TFS Controller.

A day after there was an external team that started to complain about their build being busted and how they’ve lost hours trying to fix it with no luck. The thing is that I didn’t give them a notice that I’m adding a new build and if for some reason they don’t want to use it, they should’ve changed their build definition and keep using the old agent. Fair enough….but this raised my temperature, hence this blog post.

The Problem

I don’t want to rant over one team because I see this very often with the clients I work for. They all make the same mistakes, because that’s the easy way out. What they do is they’re coding their solutions against an idea that some extra software will be installed on the build server so that build will work properly. This is so wrong and unless you have a very good reason for it, you should avoid it by any means.

Here are some of the reasons why:

Scalability

While it’s nice to have “it works on my machine” certificate, this very likely means it won’t work on any other. Your TFS master will add (or remove) build agents according to the needs and when that happens you may be rerouted to another box. Unless the new box is the exact copy of the existing build agent, your build will fail.

F5 Experience

There are pretty big chances that when someone new joins the team, he will have to spend a day installing software on his machine to make it working. Is it really worth it? What every team should strive towards is “Get Latest” press “F5” and you’re good to go.

The Solution

NuGet

NuGet has been around for years and it’s a shame to see that some teams are still not using it. It gives you the flexibility you need to ensure no extra software is required on the build server (or any other dev box).

Reference Folder

If for any reason you can’t use NuGet then you should at least add a reference folder to your source control and put in all DLLs that are needed for your solution to build. I know it’s not ideal, but it’s a workaround and it works for everyone and your build server.

Configure your Buid Definition 

I know that there will always be cases when you will really need something installed on the build agent. And it’s OK if this happens, but…then use Tags to filter the servers that can actually build your code or use name filter.

TFS Build Agent Setting
Figure: Build Agent setting for TFS Build Definition

More about name tags here:

http://nakedalm.com/why-you-need-to-tag-your-build-servers-in-tfs/

Share this:

Leave A Reply

Your email address will not be published. Required fields are marked *