Use the Builds Check-In Policy to Minimize Code Churn after Breaks to Continuous Builds
When you configure a build to use either the Continuous Integration or Rolling builds trigger, every check-in operation starts a build. When one of these continuous integration builds breaks, it is important for your team to first fix the problem that broke the build before making additional unrelated changes to the codebase. You can use the Builds check-in policy as a tool to limit additional changes to your codebase until the build break is fixed.
When you enable the Builds policy, it blocks team members from adding new files to any source control folder that is a working folder in a build definition which is triggered by either the Continuous Integration or the Rolling builds trigger. When this event occurs, the team member who is attempting to perform the check-in operation receives the following message:
The last build of definition <build definition name>, triggered by user <user name>, failed.
Required Permissions
To complete this procedure, you must have the Manipulate security settings permission set to Allow. For more information, see Team Foundation Server Permissions.
To enable the Builds policy
In Team Explorer, right-click your team project, click Team Project Settings, and then click Source Control.
The Source Control Settings dialog box appears.
Click the Check-in Policy tab and then click Add.
The Add Check-in Policy dialog box appears.
In the Check-in Policy list box, select Builds, and then click OK.
In the Source Control Settings dialog bog, click OK.
See Also
Tasks
Create a Basic Build Definition
Concepts
Define a Gated Check-In Build Process to Validate Changes