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.
Variable groups have been introduced in TFS/VSTS to address this need.
These are shared variables at the team project level, and can be used in build or release definitions. The ability to refer to variable groups from release definitions is complete and is now available in TFS 2017 and VSTS. The ability to refer to variables groups from build definitions is planned in the next 3 months.
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
For example we have an F5 username and password that we need to use across all of our releases to manage load balancing. It would be great to only have to define that in one place and reuse it everywhere.