17 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Jeff Schwandt commented  ·  June 10, 2013 5:17 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  @Michael.Peterson - You're thinking of the Build Template. That is a XAML file. The Build Definition is not exposed as a file.

• David commented  ·  May 7, 2013 7:25 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I want to see changesets, who modified it, and its relations to other files.!

• Nick Laycock commented  ·  February 20, 2013 5:47 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This would be a fantastic addition. It would certainly make diagnosing issues much easier.

• Sam Smith commented  ·  February 20, 2013 5:13 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This is definitely a feature our development group would use - especially after recently having build issues. We currently store our definitions in text files within the solution - not ideal at all.

• Anonymous commented  ·  December 3, 2012 11:49 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  At least provide a simple history mechanism. Also check for concurrent editings and warn user when defintion was changed by someone else.

• Anonymous commented  ·  November 26, 2012 1:45 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  The VS team really needs to get this into the project.

• gary commented  ·  October 19, 2012 4:26 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Anything regarding to tfs build are versioning but except build definition. We really want this.

• Jim Roth commented  ·  October 12, 2012 2:50 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I cannot comprehend why Microsoft doesn't see the problems for an administrator with respect to managing build definitions. I have a set of build definitions for my vNext branch. When I create a release branch, I have to clone a set of build definitions, then edit each of them to point to the new release path (workspace, drop folders, solution path, tests, etc.). This is a REAL pain in the ***. Why in heaven's name can't you provide a mechanism for managing and editing build DEFINITIONS. I understand that build templates can be source controlled, but the build definitions are nothing but parameters stored in the database. Any monkey can come along and edit the build definition, and I can't roll back to the previous version! Why is that SO HARD FOR YOU TO UNDERSTAND?

• Chris commented  ·  July 31, 2012 9:00 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  We call a .proj file and that file is checked into source...

• Lin Li commented  ·  June 28, 2012 12:53 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  there is no way to tell who, when and what has been modified for a teambuild definition, which makes very hard to manage teambuilds.

• Christian Harlass commented  ·  April 24, 2012 7:28 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  +1 for versioning build definitions

  Same reasons as Doug de la Torre already explained.

  Basically, as soon as a Build Definition has been changed, you cannot guarantee that rebuilding an old version produces the same output.

  Currently we create (clone) a new build definition per branch. But even that is no way to proof to an auditor that the build definition has never been changed.

• John Sewell commented  ·  January 9, 2012 2:45 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Agree. I'd like each definition to have a pointer into a user-specified place in the Source Control hierarchy, where the bulk of the definition would live. I would not want to have to explicitly copy and check in each time I changed any of our build definitions. Currently we have ninety definitions.

  Jason Stangroome: I think this item addresses your suggestion: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2502399-make-it-easier-to-replicate-a-set-of-build-definit

• Michael Paterson commented  ·  December 15, 2011 3:32 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  @stavn it is just a xaml file. If I need to change the build definition then I update the file and check it in.

• stavn commented  ·  December 15, 2011 1:15 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  @Michael Paterson: How can you "store the build definition file in source control"? I beleive it is stored in TFS 2010 database.

• Doug de la Torre commented  ·  September 6, 2011 2:00 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  This is a feature our team desperately needs, for these reasons:
  1) Audit trail. We need to be able to show what changes are made to a build, including the definition that supplies all the inputs
  2) History. Need to see what has changed over time
  3) Repeatability. Making build definition a file saved in the source tree would allow the entire build process to be merged/branched - updated with a single gated check in.

  As a workaround, we ended up writing a custom tool, that checks every 1 minute, serializes the build definitions to XML, checks for differences, if found, then checks the serialized XML into the source tree in a location where we can go to view the history. At least this allows us to see changes with a 1-minute granularity, since we hit some nasty bugs that come up when 2 or more people open the build definition (or leave it open for days or weeks in the IDE), then both hit save, since whoever saves last overwrites the changes made by the other user. With this tool, we’ve been able to track down a few more of these. Note that permissions DO NOT solve this scenario, since we have multiple build admins who can potentially all make edits to the same definition at the same time, and all have permissions to do so.

  Making the build definitions first-class items saved in the source tree would be ideal, much like is done with the build template XAML file, since it becomes a trackable, and mergeable entity, allowing the entire build to be ‘changed’ in an atomic operation (shelveset).

  Any idea how to elevate the priority of this in the backlog? This is a pretty important scenario (a big gap), especially when it comes to audit history.

• Jason Stangroome commented  ·  August 8, 2011 6:23 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  It would also be great to link a build definition with a Branch folder so that creating a new branch from an old version could also enable easily creating new build definitions for the new branch using the version of the build definition associated with the version of source that was branched.

• Michael Paterson commented  ·  August 8, 2011 9:01 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  You can always store the build definition file in source control. This is what I do.