Late last year I uploaded my first VS Gallery contribution – Colin’s ALM Corner Checkin Policies. One of the policies in this pack is a Code Review Checkin Policy. I blogged about it in this post.
I had a customer who mailed me about their builds failing. The error message was
I’ve often had the question from my customers – “I’ve got a bunch of Requirements. Some of them are Active, but all their Child Tasks are Closed. Can TFS automatically close the Parent items? Or can I at least query these Requirements out?”
In Test Case Manager, you can open a test run that has failed and set the Failure and Resolution types for the failure.
The logical next step after you start unit testing your code is to analyse code coverage. You can do this easily in TFS by enabling Code Coverage in the test settings of the default build template. But what about failing builds (or checkins) based on low code coverage?
Update 2013-07-24 : This activity is now part of Community TFS Build Extensions.
On January 11, Brian Harry blogged about some bugs in the TFS 2012 upgrade process (as well as the link to the KB patch for fixing the bugs). I was upgrading a customer in December last year and we hit one of the “symptoms” that was fixed with the patch.
TFS’s Work Item Tracking system is amazing – the flexibility and customizability of the system is fantastic. It also allows your tool to enforce your processes – which is always a good thing for efficiency in any team!
Over the last couple of months, I’ve been doing a lot of VS / TFS 2012 demos, as well as installing / configuring / customizing TFS at customers. Everyone loves the Code Review Workflow, but inevitably the question gets asked, “Can I enforce code review on check-in”? Out of the box you can’t, but I created a custom policy for this.