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.
With TFS 2017 and VSTS, you can see a history of changes for a build definition. You can select a previous version from that history and restore the definition to that version.
We are now beginning to look at how we can manage definitions entirely in source control so that you can use the same branching and policies for definitions as for the rest of your code.
Nils Andrey Telleria Martinez commented
There are some sort of access to the definitions, as can be seen on the changes history, appearing as json. Make total sense, you can see it on the very same corefx repo on the "buildpipeline" folder at https://github.com/dotnet/corefx.git.
Daniel Cazzulino commented
Would love an AppVeyor.yml-like feature!
Fernando Tirolo Gomes commented
It's out! Thanks guys!
More details at:
Michael Barry commented
Any update on this? It didn't make tfs 15 RC 2
It's build be great if you could merge different build definition. Currently, you could only "branch" (clone) a build definition. And it would be a hassle to apply changes across all of the build definition.
Glen Appleton commented
I would also like to note that we need these features for the vNext Release definitions as well as the Build definitions in TFS and VSTS. Since they both use the same queues and agents, I would hope it would be a simple task to port it to both functions.
Jon Vaughan commented
For me its all about selecting a historic changeset that I get both the source and build process at the same point in time. At the moment I get source only and have to inspect the build definition history (in VSTS) to see if my build artifacts will be different.
Rob Cannon commented
I wanted to note that the ability to rollback a change is not the primary use case for source control. We have hundreds of projects and close to a thousand build definitions (most still in XAML). Most of these are similar and having all of those in one source control project would make it much easier to manage across so many projects. I have considered writing a build task that could manage looking for changes and pushing the builds through the REST api.
Elliott Edwards commented
Premise 1: We are using the VSTS (visual studio online) Build
Premise 2: We _could_ commit a build definition-like thing (.ps1/msbuild/etc) along side our source, but want to be able to have first class build progress / logging support in the VSTS Build website
Premise 3: We operate off the intuition that a build definition is source code
Premise 4: We see that a given build has a strict, versioned dependency on both the source code commit and the build definition in effect at a given time
Premise 5: We operate off the semantics of source control, where you can a) branch, b) time travel, c) blame, d) revert and want our build definitions to be able to "follow" these features
Premise 5: We see this sort of feature to be valuable at both the VSTS Build and VSTS Release Management levels.
In terms of requirements, we need a way to:
1. strongly version the build definition
2. see who has changed the build definition, for what reason, and when (this exists today)
3. revert build changes (this is the piece that appears to be coming soon)
I can totally see the reasoning of the folks who say they just "check in the build definition" and get all of this for free (other than the fact that it is not so simple for the VSTS Build/RM case). That would give the build definition all the source control features because it would simply be in source control, right along side the code being built.
While this is a good strategy, it works less well for VSTS Build definitiosn. Although I believe there is a way to GET and PUT a build definition via the APIs, there is no way to _automatically associate a file in the source repo with that definition_ and there is no way to _update that file as a result of changes in the VSTS Build/RM UI_.
My (unfairly git-centric) proposal would be to:
1. Have VSTS create a git repository for each build and commit the .JSON build definition representation on each gui "save" (if it doesn't already do this). Voila, audit, revert, blame. Say it names this repository TriggerRepo_BuildDefinition.
2. Have VSTS mirror the branching structure seen in the repo being built. If it sees a v1_0 branch in source, then TriggerRepo_BuildDefinition branches as well
3. Have VSTS have a branch switcher on the build definition editor to target what branch to change
4. (optionally) Associate a versioned build definition with the source via a regular old git submodule. On getting the source, the build engine would, if a submodule reference to TriggerRepo_BuildDefinition exists, grab and validate that json build definition and then execute it! This would afford strongly-versioned historically friendly builds.
5. Saving a change to a build definition in the gui, then, could be in one of two modes:
5a. AUTOMATIC submodule update: If a suitable submodule is detected, a commit to the TriggerRepo is automatically made (similar to VSTS direct file editing) that updates the submodule reference to the newly saved build definition commit (making that build definition automatically the new build definition moving forward).
5b. Manual submodule update: same as above, but on save the operator is given a choice of whether to commit to the source branch (updating the build definition submodule reference) or not.
5c. There may also need to be an option to skip triggering of a new build via 5a or 5b. Probably depends on the use case and the artifact versioning requirements.
Anyway...seems plausible to me from the git side, not sure if tfs would need a different approach. Perhaps a "faux" .submodule file support that is only honored by vsts would suffice...
Patrick Samy commented
+1 for versioning capabilities, but ultimately, it would be great to have a file that you can even use with a script to run your build pipeline locally.
A script wrapping the Xplat agent and sending the commands to it would be a good starting point if we have the build definition file.
Patrick Samy | Software Engineer | Microsoft
@ChrisPatterson: I don't think rollback to earlier version of a build definition is enough. Use case is that it should be possible to rerun any build at any time. Of course this could be done with manually rollback (as it is already now by manually editing the build definition to its old values), but this approach fails if I need to go back to the newest definition afterwards or need different version of the build definition for different branches (eg, release and develop).
IMHO the only possible solution to solve this properly is to have the build definition itself under version-control
This is really important from Build Engineer's point of view. Thanks for taking this up.
Abhishek Verma commented
this feature is very much required. keep going..
Jeff Boettcher commented
To close the loop on my comment, I received confirmation by email from a Microsoft representative that this is only in Build vNext build definitions. There is no source control or history for traditional build definitions from the pre-2015 XAML-based build system, and there probably never will be.
Jeff Boettcher commented
To be clear, does TFS 2015 add change history to existing build definitions? Or is change history only available for vNext build definitions?
I agree with Yan, having it based on a file means that file can be changed easily.
I like this feature! A good start, keep going on!
It's a good start! I can already see history on build defs using the Community TFS Build Manager, but this is a good add. Thanks.
Ralf Karle commented
Would be great if configuration of the build controllers and build agents would also be under version control (Tags,...)
Robert Osborne commented
What does it mean that it is archived? Other things that you say you will work on go to Planned, not Archived. Does archived mean it's just on the backlog for the distant future?