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 Boettcher commented
Any update on plans for this?
Reinhard Kuhn commented
Still considering? Since 2011?
Do you realize how painfully ironic it is to reside right in the middle of a powerfull versioning system and force the enterprise user, dealing with literally hundreds of build definitions, to maintain this important element in a fire-and-forget fashion flying blind without instruments?
Seriously? Its not even hard to implement.
Pete Holmes commented
+1 for versioning of build definitions and easy mechanism to export and import
Please add this feature. It's amazing how often this comes up.
There is a nice tool in the vs gallery, which makes possible tracking changes, merging, branching, restoring build definitions..etc:
There are a lot of companies which realy need such features.
till data, we have no alternative/method or mechanism to track changes done in build definitions. I strongly agree with Mike G.
Mike G commented
Please Microsoft, at least provide an audit trail of the changes that happen in build definitions. It's too easy for someone to break a build definition without anyone else knowing that they made a change. Sure the XAML is tracked in source control, but that’s only half the story of a build.
Seven people in my company have access to build settings/authoring. If one of them takes a peek inside some build definitions, and accidentally makes a change, and accidentally hits save, it won’t be until a build breaks that anyone notices. And then we are left with the mess of trying to find out what the settings were that got changed.
If we had a log of who/when/which build definition was changed - that would be a simple start. Then if we could see before and after changes, that would be valuable too.
Nick Williams commented
I'm going to write a small app to do this using the method outlined here: http://blogs.msdn.com/b/jpricket/archive/2011/04/14/tfs-2010-bulk-updating-build-definitions-retention-policies.aspx
Michael Paterson commented
Indeed that is what I was thinking about.
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.