通过

Creating a team build definition : Why should one NOT use the default workspace

  • 项目

(中文版)

In Team Explorer 2008, the team build definition wizard offers a default workspace which uses “$/ <team_project_name>” as the source control folder. This is not appropriate for most of the time. One should customize the workspace mapping, make the “Source Control Folder” to include only the folders necessary for the build. Overlooking this requirement would bring some bad effect to the builds, include but not limited to the following:

1. CoreGet target (by default) gets source files at the workspace level. If the workspace is mapped to a bigger scope than “just enough” for the build, in this step more files than necessary are downloaded from the TFS server to the build machine. This is especially true when one just want to build a very small portion of the source files—a default workspace mapping will download the entire team project source which means a waste in both time and disk space.

2. CoreLabel target (by default) labels at the workspace level. Typically people wish a build to label just those files involved in that build. A improper bigger scope will cause more files than expected to be labeled.

3. GenCheckinNotesUpdateWorkitem target compares two labels—the one from this time and the one from last successful build --to get the changesets & workitems that are associated to this build. If CoreLabel works at the entire team project scope, so would this target. As a result, the build report may contain changesets\workitems that are not at all related to the build.

A sample comes from one of my customers. They wanted to build a branch of their product, but found the build reports to contain changsets & workitems for the mainline and other branches. This caused trouble because they wanted to trace that data in each branch separately. The solution was to change the workspace mapping source control folder from the default “$/team_project_name” to the interested branch only.

Although one can avoid the 3 problems above by overriding properties of CoreGet / CoreLabel, this is not recommended as this may cause the build to stop working in future updates.

Jim and Buck from the product group helped to clarify this. Thank you guys!

Comments