provide a way to version-control build definitions
Currently, there is no way to revert back to an old version of a Build definition once you've made changes to it.
This suggestion is on our product backlog for consideration in a future release of TFS.
Jeff Schwandt commented
@Michael.Peterson - You're thinking of the Build Template. That is a XAML file. The Build Definition is not exposed as a file.
I want to see changesets, who modified it, and its relations to other files.!
Nick Laycock commented
This would be a fantastic addition. It would certainly make diagnosing issues much easier.
Sam Smith commented
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.
At least provide a simple history mechanism. Also check for concurrent editings and warn user when defintion was changed by someone else.
The VS team really needs to get this into the project.
Anything regarding to tfs build are versioning but except build definition. We really want this.
Jim Roth commented
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?
We call a .proj file and that file is checked into source...
Lin Li commented
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
+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
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
@stavn it is just a xaml file. If I need to change the build definition then I update the file and check it in.
@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
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
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
You can always store the build definition file in source control. This is what I do.