A few more questions ...

Sep 29, 2009 at 5:56 PM

Even the TFS Check-in Validation system is done, the developers can still check in code in the old way, i.e. check in direct to TFS and bypass the validation tool. Is there anyway to enforce people to check in through the validation tool?

If user check in a shelveset which violates some check-in policies, e.g. doesn't contain a code reviewer, the validation system will still run a buddy build and then try to check in the code. Later on, it finds that the check in is rejected by TFS because a code reviewer is required. Is it possible for the user to catch this kind of errors early on instead of waiting a whole buddy build?

Right now, I need to change a tag in the buddybuild target file (like this: <OverridePolicyViolations>true</OverridePolicyViolations>) so that the check-in policies are satisfied. Otherwise, there is always this error:
TF10139: The following check-in policies have not been satisfied:
    The Code Analysis Policy requires files to be checked in through Visual Studio with an open solution.
However, there is no point to enable this policy if I have to always override it from the validation tool. So I wonder whether this is my own problem or a problem from everyone?


Oct 3, 2009 at 5:05 AM
Edited Oct 3, 2009 at 11:36 AM

The problem with check in policies in TFS is that they are not there to prevent check ins that are in violation, but rather to notify you of violations and help you address them. That is why you are given the option of overriding them by providing an appropriate comment. They were not designed to prevent the check in.

By default, the buddy build tool evaluates existing check in policies and any configured check in notes when scheduling a buddy build against pending changes and indicate you want the changes checked in upon buddy build success. You can override those policy violations and check in notes violations. However, since check in notes cannot be overriden, you run the risk of a failure during check in. Currently, the tool allows you to define default values for the different check in notes so that they can be set on the shelveset created by the tool. And starting with version of the tool, you can enter check in comments to associate with the shelveset as well as specify the policy override message. The next version of the tool will allow you to pick work items to associate with the shelveset, and it will also allow you to enter the mandatory check in notes from the pending changes dialog. Of course, specifying an override becomes necessary in cases where some check in policies were meant to be run on the client machine and within the context of Visual Studio as is the case in your example.

If you shelve changes outside of the tool and associate your pre-created shelveset with the buddy build, then it is your responsibility to specify the check in notes, enter check in comments, and associate any required work items with the shelveset.

You should not need to set the OverridePolicyViolations property to true in the BuddyBuildExtensions targets file since if you've shelved the changes using the tool and specified that you want to override check in pollicy violations, then that information will be written to the shelveset and be available on the build agent when the shelveset is ready for check in. The property is there as a last resort or to always force the override, especially if you think someone will forget to set that during shelveset creation.

As for your question about enforcing check ins through the check validation tool, you can actually do that by following those steps:

1) Make sure users do not have Check In privileges on the branch you want to limit access to. This means no one can check in. They can still check out.

2) Set up the TFS Buddy Build Web Service.

3) Set the Buddy Buiild VS2008 add-in so that it is configured to go through the buddy build web service.

4) Schedule gated check ins through the tool. They will be checked in by the account under which the buddy build web service app pool's identity. That account, typically the build system account, will have check in privileges to branch.

In that case, the buddy build web service will act as the facade that decouples the developer from direct check in access to the source control system.

Personally, I don't believe developers should have stripped down access to the source control system. The only exception is probably your golden branch, or Main. On feature branches, gated check ins can become more of an overhead, especially when the build time is a bit long (e.g.: they take more than 30 minutes to finish), so you should always have direct check in allowed unless you have a really good reason not to.