I was delivering a training course on TFS 2012 this week and one of the delegates came across some unexpected behaviour that I hadn’t noticed before.

We had added the Work Items Check-in Policy to version control earlier in the day and were looking at automated builds.

With TFS you can perform a private build (or buddy build) to ensure that your proposed changes integrate successfully before you check them in.  You can also select the option to Check in changes after successful build which turns it into a kind of voluntary Gated Check-in.

This is what my delegate did and as his build completed successfully, his shelveset was committed to version control.  Somebody then pointed out that as the changes were not associated with a Work Item there should have been a policy warning like the one below.

I can’t say I have ever noticed this behaviour before and it took me a minute to realise the reason behind it.  Check-in policies are evaluated on the client side so for example if you use the Code Analysis Policy then it is your responsibility to run the code analysis rules against your code before check-in.  The server will not evaluate the policy for you, it will simply check to see if you have passed the rules locally.  The check in that happens as part of the private build happens server side so it did not have to pass the client side check-in policies.

You can of course control permissions on builds or ensure that the build also runs a suite of unit tests but it’s one to be aware of.

Richard