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.
Carl Walsh commented
@Raul Daly maybe that should be a different feedback item?
Paul Daly commented
As others have already commented, please also do this for release definitions too. I think it is a bit different for release definitions though.
I'd like to be able to see diffs between environments not just release definitions. I'd like to be able to incorporate changes from one definition into another. The release definition could be like an ARM template, but the environments could be like ARM template parameter files.
Leaf level environments (dev, ect) could deviate, but higher environments (prod) would consolidate those changes via the standard merging/PR process.
real source control with diff
Joe Rykowski commented
This feature appears to be available in TFS 2017 Update 2 and current Team Services?
Naveen Mangtani commented
Also, please add task groups to be source controlled just like build and release definitions.
Taylor Mansfield commented
If you look at Jenkins' Pipeline builds, I think that's an excellent model to emulate. That way the build definition is set in the same SCM as the code that it builds.
Rene Kroll commented
Currently I use a script to extract the release definition and put it into a GIT Repo. It would be great if I can create a snapshot from build and release definitions and a functionallity to automated restore.
Gary Davidson commented
Please provide a way to save and retrieve Build Definitions and Release Definitions to TFS source control. It makes no sense to block users from doing so and this particular shortcoming does lead your customers to look for alternatives. Of course that leads to lost customers. We have experienced corrupted release definitions that required us to seek out other 3rd party software to assist in rebuilding our build definition and we are using the Enterprise TFS at US Bank.
Putting build and release definitions in source control would be great.
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