The Guntlet

Buck Hodges recently posted about a problem with locks based on files types and shelving in VSTS Source Control. In the post he mentions a system called Gauntlet that is used internally in some teams at Microsoft.

The Gauntlet system is very interesting to me. I've never seen it in action and have only had snippets of conversations with Microsoft people (and I have to say mostly it is them moaning about it).

From Buck's article, Gauntlet runs by processing a queue of shelvesets. (A Shelveset is a great new feature in VSTS Source Control where you can save your code on the server but outside of the main source tree - you can think of it a bit like a temporary working branch - but see Chris Rathjen's post Is Shelving just a fancy word for branching? for more)

Anyway, each shelveset is processed, and providing the code does not break the build (i.e. compiles, passed static code analysis and unit tests) then it is added to the main source tree.

To me, this is Continuous Integration by another name. Many people are using CruiseControl (and CruiseControl.NET) to acheive the same benefits but the Gauntlet has some additional benefits:-

• The code is not committed to the main branch until it is proven by the server that it will not break the build.
• Main branch build and labels can be reserved for "integration builds" or releases - that way you can very easily provide the users of that build with a list of differences between the builds

The downsides seems to be:-

• More complicated development process, slowing down development
• Increased time before a code change appears in the main branch
• Complicated process discourages small incremental checkin-ins
• When you submit your change, there may be a queue of changes being processed and one of those might break your code, no easy way of preventing this
• Similarly, if you are relying on a change that then doesn't get passed the Gauntlet then odds are additional queued changes by you will also fail

Using an open source toolset, an equivalent process could be done by using patch files. It would be pretty painful with today's toolsets but could be simplified.

Like everything, you have to have a process that meets the needs of your organisation. Development is always a matter of control vs speed of delivery. Personally, I think CI in the traditional sense with CruiseControl strikes a nice balance in most organisations.

But if anyone in Microsoft land fancies describing Gauntlet in a but more detail and perhaps a quick pros / cons of using a similar process versus CI with CruiseControl (or MSBuild for that matter) I for one would love to read it.