1
votes

How can one persist or version-control a detailed history of build modifications (not just template modifications)?

In Visual Studio 2013 using a TFS build server, we know of two places where you can edit a TFS build configuration (screenshots below):

  • In the build template xaml file, using the Workflow Designer:
  • In the build definition directly, using the build editor:

I know you can version control the xaml build template, edit it, check it in, and refresh the build definition from that. The question is, how can someone go the other way—edit the build template using the same editor that the build definition uses? The actual build editor exposes myriad properties that the Workflow Designer conceals or abstracts away in undefined variables.

How can you modify build settings—like run settings, code coverage, and code analysis—across a very large number of solutions? The Workflow Designer doesn't appear to expose these, and build modifications are absent from the server-side xaml that the Download link yields (I've edited and saved builds, and diffed the new vs. old xaml; they're identical).

Build definition changes aren't completely inaccessible as code, are they?

Editor screenshots:

  • Editing the build template xaml file, using the Workflow Designer: Build template xaml in Workflow Editor

  • Editing the build definition directly, using the Team Build editor: Team Build editor

Note: Microsoft's guide to customizing your build process template doesn't address this. It describes template editing & deployment, but doesn't speak to the difference in properties exposed by the build editor vs. the template editor (a.k.a. workflow designer).

1

1 Answers

2
votes

Conceptually a template is the workflow that drives the build, a template exposes Arguments that can be populated by the Build definition. A single template can be consumed by multiple build definitions, with the differences being the arguments that are passed from the build definition to the template. Changing the build definition DOES NOT in any way alter the template

Standard arguments that are passed in are the workspace, the solution to build and any arguments that need to passed to the test runner, such as a run settings file.

I have a standard template that i use for 95% of my builds, this is customised to update assembly versions, run stylecop, display a warning if code coverage falls below a threshold and other little tweeks.

if you want to apply something accross multiple builds then you need to customise the template, for arguments that are exposed to the build definition you can supply default values. This then means that all of your builds will follow the same process.

when you then create a build definition you can use the same template and just supply information specific to that build such as solution file and run settings, you can override the default settings that you created for an argument in the template with specific values for that particular build.

As an example, in my template i have an Argument of TargetCodeCoverage, this has a default value of 70, so all definitions will have a default value of 70, if for a specific build i want 80 i can just change that value in the build definition.

Build definitions have been hard to track as they exist in the database and are not as such source controlled, if you install Community TFS Build Manager, you can right click on a build definition and export it. you can then save this exported file in Source control.

Another way to 'standardise' your definitions is to create a definition you are happy with and then just clone it, repeatedly, this will then give you all of the same setting that you created on the first and you can then just update the workspace and the solution file