Project level build/release variables
We can create variables for a build, however when we have multiple builds, it would be nice to have project level build variables which can be used in all your builds/releases.
This work is complete in VSTS and is also available in TFS 2018. You can now share variables through variable groups in build and release definitions.
Some of the users on this thread asked for additional features such as scoping the variables to specific environments in a release definition. Please open new uservoice items for that. Thanks.
sigh I still can not do this with TFS it's nice u got something working with Azure to handle the middle ground but your API does not let me fish the Variable that way either. :(
Frederico Tereso commented
Will it be possible to link the group variables to environment inside a release? Consider this scenario: clone environments to be deployed after the success of the previous ones and all we need is to pass a different variable group to each environment. The variables will be named the same so that no additional edition of the environment will be needed. Nowadays, I can link groups to a release but not to a specific environment or scope as I can with process variables (actually I don't know how groups with same variables will behave if linked to same release).
So,I think the question really is: will variable groups have scope as process variables?
Kelly Davis commented
All i want to do is ACCESS the defined variable values i have in my build solutions so I can use them in my release as part of a name or what ever the **** i want. i am finding it quite difficult to use my naming convention with out having to manage values by HAND.... as i create 0 touch solutions this not something i can deal with. this was not a problem for me to do at all in TFS2014 btw... only in VSTS 2017 has this been a major issue....
Will it be possible to share variable groups across projects within a VSTS Account? This would be really useful for us where projects are separated because there are different teams/products involved, but they ultimately rely on some common config when deployed.
Justin Holbrook commented
Good news, looks like this is already planned for the next release:
2017 Q3 Build improvements – shared variable groups, multi-phase builds TFS vNext
Build improvements – Multi-phase builds, conditional tasks, shared variables: There are some pretty important improvements here that enable you to scale out your builds across multiple agents and have “merge points” – this is one of the things “phases” gives you. Conditional tasks also allows you to reduce the number of very similar build definitions you have and use conditionals instead.
Justin Holbrook commented
Currently it says in the article posted by admin that this is currently not available in for build, only release.
"Variable groups can only be used in release definitions in TFS 2017 and Team Services at present. They cannot yet be used in build definitions."
Having this for build is a significant value add.
Clayton Reeves commented
We are a fairly small team and this would still be a great addition. We use common Major.Minor.Sprint based build numbers across projects. The ability to have this in one location would make a very big difference for us.
I'm staggered that MS haven't implemented this years ago. They must have thousands of build jobs internally themselves - and they never had a need to share variables across builds?? There's so many holes like this in the whole TFS ecosystem though, so I'm not surprised....
We need to use a user+password combination and some build path/servers which is identical in all releases. We are talking about hunderds of releases. It would be nice if we could have global variables at the higest level so we don't have to set these variables explicitly in each release. Also, when a path/server/user changes, we don't have to change all releases.
backer rosa commented
Great! We need this feature to store credencials
J. Mike Zserai commented
I can think of some situations where the last value of a build variable would be valuable in a current build.
I could see a persistent key/value store that automatically is searched by the VSTS build engine whenever a build variable cannot be found in memory and resolved if found.
I create a number of build variables in a Powershell script that would awesome if they could be persisted with say, an additional option -Persist when creating the variable in Powershell.
Many of the properties contained in the project file can be set to a build variable (e.g. $(NextVersion) ) that the script creates before the build. As long as the variable was created and has a value compatible with the property using it, MsBuild automatically resolves the variable and replaces it.
I use this method, for instance, to set the DacVersion property of SSDT projects and it works very nicely.
Jonas Stawski commented
Another example, a base version number you want to keep across all your environments.
Ole André Schistad commented
Many service-specific bits - ServiceBus queues or DNS records - will be referencing a common root component - the ServiceBus namespace, or the DNS zone.
The ability to set global or project-wide variables would be a good way of ensuring these shared components are named correctly every time.
Ole André Schistad commented
Even in a fully agile process, there tends to be some degree of shared infrastructure. Many service-specific bits - ServiceBus queues or DNS records - will be referencing a common root component - the ServiceBus namespace, or the DNS zone.
Having a project-wide and global set of variables allows you to more easily reference these shared resources, wihout having to explicitly name them in each referencing release task.
There are also all sorts of pre/post fixes that tend to be "global" or project-wide.
Would be very very useful for configuring a standard set of variables for deployment paths for applications or log files across multiple machines and where things are getting deployed or saved.
Things can become very hard to maintain/update when having multiple premise environments.
serdar turk commented
this was requested since 2014 and it will help us greatly thinking that 3 different environment and over 50 release pipe to define.
I agree this is needed...we have over 70 TFS projects with multiple application in each and will be creating many builds and releases we have a need to store environmental variables that cross all these projects on multiple machines...Our current solution is looking at using Credential Manager on a central server to store some of these key/values and using a powershell script to retrieve them...but downside is we now have another server to jump to for these scripts...Hope you can address this sooner rather than later
TFS 2015 Update 2: We need to be able to declare global variables that can be used across all release definitions. Today we have to define them at release definition level.
Below are the issues:
- With tight security policies, it is not acceptable to give username and passwords to developers who create these definitions.
- Password could change every few months due to security policies. In that case it would be very difficult to update them manually in all release definitions.
It would be very helpful if we can declare them once at global level and just ask developers to use variables.
Peter Groenewegen commented
As example: a password that you need in multiple builds/release pipelines
This is more of a "Must have" taking into context a company that has hundreds of product applications to release in RM to have to manage credentials in *each* release template would make this unsupportable for multiple server environments where you need to restrict the credential access (IE: Credential access to dev should never be able to access prod).
TAG: TFS 2015