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
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
In Team Explorer, click the team project in which you want the build process to function.
On the Build menu, click New Build Definition.
The New Build Definition window appears with the General tab displayed.
On the Trigger tab, click Continuous Integration.
Tip
If your developers are having to wait too long for their check-ins to build, you might want to click Rolling builds instead. This trigger causes the build system to build multiple check-ins together. For more information, see Use the Rolling builds trigger.
Click 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.
Click the Process tab. In the Items to Build parameter, specify the solutions or code projects that you want to build.
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.
Click the Build Defaults and Retention Policy tabs, and then specify appropriate settings on each tab.
For more information, see Create a Basic 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
Automated Tests:
For faster performance, set Disable Tests to True.
If your code must pass certain tests, set Disable Tests to 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 Use Your Build System to Work with Tests.
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 Using 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.
Copy Outputs to Drop Folder: For faster performance, set to False.
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.
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.
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 Use the Builds Check-In Policy to Minimize Code Churn after Breaks to Continuous 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.
Change History
Date |
History |
Reason |
|---|---|---|
|
August 2011 |
Added topic. |
Information enhancement. |