Define a Build Process to Support Continuous Integration

Your team can minimize errors in its codebase by integrating various features into a shared repository as frequently as possible and then building and testing the result. You can implement this strategy, known as continuous integration, by defining a build process that ensures that you and your team can determine as quickly as possible that a check-in from a feature team has broken the build or caused a test to fail.

In this topic

• Define a Build Process to Support Continuous Integration

• Guidelines to Improve Function and Performance of Your Build Process

• Next Steps

Define a Build Process to Support Continuous Integration

Required Permissions

To perform this procedure, your Edit Build Definition permission must be set to Allow. For more information, see Team Foundation Server Permissions.

To define a build process to support continuous integration

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, and then choose Builds.

   3. On the Builds page, choose New Build Definition.

   A new build definition window appears.

2. On the Trigger tab, choose Continuous Integration.

   Tip

   If your developers have to wait too long for their check-ins to build, you might want to choose Rolling builds instead. This trigger causes the build system to build multiple check-ins together. For more information, see Use the Rolling builds trigger.

3. On the Workspace tab, in the Working folders table, specify the version-control folders that this build definition should monitor.

   Tip

   To ensure that your build process functions correctly and to improve performance, include all folders (and only these folders) that contain files that your build process requires. For more information about how to specify these folders, see Work with Build Workspaces.

4. On the Build Defaults tab, to improve performance, choose This build does not copy output files to a drop folder.

5. On the Process tab, under Build process template, the Default Template is selected by default. In the Items to Build parameter, specify the solutions or code projects that you want to build.

6. On the Process tab, set the build process parameters to ensure that check-ins meet the specific standards of code quality for your team without delaying your developers unnecessarily.

   For more information, see Guidelines to Improve Build Process Function and Performance later in this topic.

7. Specify build process options on the other tabs. For more information, see Create a Build Definition.

Guidelines to Improve Build Process Function and Performance

To ensure that the build process meets your team’s needs and performs as quickly as possible, you should consider the following guidelines when you specify values on the Process tab.

Required node

• Items to Build, Configurations to Build: If you leave this parameter empty, the default platform and configuration is used for each solution and project. To optimize performance, adhere to the following guidelines:

  • If a platform-configuration pair builds more quickly than other pairs, specify it in this parameter.

  • Specify as few platform-configuration pairs as possible.

Basic node

• Clean Workspace: For faster performance, set this value to None (recommended) or Outputs. However, your team is more likely to miss some types of defects (such as those introduced during refactoring) if the workspace is not cleaned. For more information, see Define a Build Process that is Based on the Default Template.

• Perform Code Analysis: For faster performance, set this value to Never.

• Source and Symbol Server Settings, Index Sources: For faster performance, set this value to False.

Advanced node

• Agent Settings

  • Name Filter or Tags Filter: Use either a build agent name or a tag to bind this build definition to a build agent that is designed specifically for running this build. The build agent should run on hardware that is sufficiently powerful to process this build quickly enough to meet your team's performance expectations.

  • Maximum Execution Time: Set this value to a reasonably small number. For example, 15 minutes might work for your team, but eight hours is probably too long.

• Create Work Item on Failure: Set to True if you want the build process to assign a bug to the developer whose check-in caused the build to fail.

• Disable Tests:

  • For faster performance, select True.

  • If your code must pass certain tests, select False, and then define a set of tests to run in the build. You can improve performance by running only the tests that you require. To designate those tests, filter them by either category or priority. For more information, see Run Tests in Your Build Process.

• Label Sources: Set to True if you want to label the code with the name of the completed build. Such a label can be useful to your team. For example, the label can help your team identify the “last known good” version of your code. Otherwise, set to False to maximize performance.

For more information about Default Template build process parameters, see Define a Build Process that is Based on the Default Template.

Next Steps

When a bug breaks the build, it is important for your team to first fix that bug before checking in additional unrelated changes. By using the Builds check-in policy, you can limit check-ins until the build break is fixed. For more information, see Minimize Code Churn after Breaks to Continuous Integration Builds.

You can identify problems such as build breaks or failed core unit tests sooner if you use the Continuous Integration trigger. However, you can block these kinds of problems from being introduced into your codebase if you use the Gated Check-in trigger. For more information, see Define a Gated Check-In Build Process to Validate Changes.

Related Topics

For more information about how to integrate and deploy complex software projects more efficiently and reliably, see Build and Deploy Continuously.