TFS 2008 ignores team project check-in settings

0
votes

I'm trying to set up our TFS 2008 instance to require that projects build before they can be checked in.

I have created a check-in policy using the out of the box "Builds" policy, but I'm still able to check broken projects in after mangling the code and attempting to build the project.

We're a small shop, and TFS was originally set up with our team's Active Directory group listed as TFS admins. Is this the problem? Do check-in policies apply to TFS admins?

Any other suggestions?

2
tfs

2 Answers

1
votes

Check-in policies are a client-side check only. If the client does not have the check-in policy available, the check will not run. Instead, they will get a generic policy failure saying that not all policies were run. Additionally, any user (there's no special permission for it) can override a check-in policy failure with a comment.

The "Builds" check-in policy does the following:

  1. Request from the server a list of build definitions affected by this check in
  2. For each build definition returned where the last build was not "good," create a checkin policy error message containing the build definition's name and the user that triggered the build.
  3. If the policy detects a broken CI build, show an error when you attempt to check in. "The last build failed.."

It sounds like you're trying to make sure that people don't break the build with their check-ins. TFS2010 includes a new feature called Gated Check-In that validates changes before they are committed to source control.

If you are using TFS2008 and can't upgrade, you'll need to look at something like OpenGauntlet - however the user experience is much improved with TFS2010.

TFS was originally set up with our team's Active Directory group listed as TFS admins. Is this the problem?

This is probably not the best idea. Team Foundation Server Administrators can do destructive things like destroy files+history and delete projects. If there's any chance that somebody might become disgruntled, you might want to reduce the number of admins or ensure that you have good backups.

As a middle-ground, you could have 1 or 2 people as TFS Admins, and everybody else as a Team Project Administrator. Most people only need Contributor access though.

In TFS2010, there is a new concept called "Project Collections". Typically, organizations have 1 or 2 people as "Project Collection Administrators" so they can add new projects and build controllers.

0
votes

Check-in policies apply to everyone. Did you verify that your deployment of the policy is active on all machines?