Minimize Code Churn after Breaks to Continuous Integration Builds

  • Article

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 Edit project-level information permission set to Allow. For more information, see Team Foundation Server Permissions.

To enable the Builds policy

  1. In Team Explorer:

    1. If you are not already connected to the team project that you want to work in, then connect to the team project.

    2. Choose Home iconHome , and then choose Settings iconSettings.

    3. On the Settings page, under Team Project, choose Source Control.

    A new build definition window appears.

    The Source Control Settings dialog box appears.

  2. On the Check-in Policy tab, choose Add.

    The Add Check-in Policy dialog box appears.

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

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

See Also

Concepts

Specify Build Triggers and Reasons

Other Resources

Define a Build Process to Support Continuous Integration