Share via


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

  1. In Team Explorer, right-click your team project, click Team Project Settings, and then click Source Control.

    The Source Control Settings dialog box appears.

  2. Click the Check-in Policy tab and then click Add.

    The Add Check-in Policy dialog box appears.

  3. In the Check-in Policy list box, select Builds, and then click OK.

  4. In the Source Control Settings dialog bog, click OK.

See Also

Tasks

Create a Basic Build Definition

Concepts

Set and Enforce Quality Gates

Define a Gated Check-In Build Process to Validate Changes

Other Resources

Walkthrough: Customizing Check-in Policies and Notes