Wednesday, 31 October 2012

Hyperbuilds

As an extension, spin-off, and plain old "Can I do this?", I extended the work I'd done recently on the Distributed Tests project to see if the same principals would yield any benefit to the compilation of our platform.

The short answers is, ohhh-yeah!

Bit of background first

Our platform consists of 40+ visual studio solutions with 80 or so build configurations. These build configurations have an exact build order that must be strictly adhered too. 

This was always going to be the fun part, working out a parallel execution plan and then distributing it!

The remotely executed jobs go looking for the solutions over a UNC path which leads them right back to my computer. In production, this could be a NAS drive or any low-powered server, it just needs to be good at working with files.

Hows it gone?

So far its all been very good. The parallel execution plan we'd already solved some time ago, so the key problems to solve have been:
  • Getting MSBuild to work over a UNC path
  • Setting up the other servers to play nicely
The first set of results weren't all too amazing, in fact I'd say disappointing,  the platform built but no quicker than on a single build agent. This however was hardly a fair or scientific test, the build agents were in active service and my host computer was busy performing a platform deployment. So, perhaps given the level of ambient activity, these results were in fact very promising, but its too early to tell.

Whats next?

The are some as-of-yet unresolved issues with two of the solutions that can't be built over UNC paths. We're using some component such as code contracts which don't seem to like the UNC pathways.

It may well be that we can never use remote builds, but even so, I think it would be worth pushing this approach to its limits and see where it eventually breaks.

I'll do another post later in the week/month to complete the story, and journal the steps more precisely with some script samples. 

Until then...