Martin Woodward brought a new community project to my attention today.  The project is based on the concept of an internal tool we have here at Microsoft called “Gauntlet”.  Gauntlet was orginally created by the IE team in the 1996-1997 timeframe and has gone through many interations and is now widely used internally (although there are many variations of it – a popular one of them is now called SNAP). The basic idea is that if you have a big team, you can’t afford to have anyone break the system (build break, key test failures, etc).  The cost is too high because it affects too many people.  Continuous integration is a step in this direction that has been pushed by the agile community.  It helps address the problem by bringing issues to the teams attention as soon after the checkin as possible.  Gauntlet goes one step further by verifying the changes before the checkin occurs and rejecting them if something fails. Internally, this has really helped stabilize the builds and reduced the amount of time spent trying to debug problems that mysteriously show up when you get the latest source code.  Of course, there is a trade off.  There is some amount of time spent debugging why changes failed on the gauntlet server but worked on my machine. Anyway this community project has been published at: http://www.opengauntlet.org/.  I haven’t tried this out myself but I’ve used our internal Gauntlet system and it sounds like the goal is to be similar.  We are working on a similar feature in our Rosario product called “Gated Checkin”.  It would be great to hear your feedback early to make sure we are headed in the right direction. Try it out and let us know if there’s anything you think we should learn from your experience with it. Please note, this is not a Microsoft project and we haven’t used it ourselves so I can’t give you a testamonial.  I can only say we think it’s an interesting feature and are glad someone is experimenting with it.  We’d love to hear what you think.

Brian