How can we improve Visual Studio Team Services (VSTS)?

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.

106 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Peter GroenewegenPeter Groenewegen shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    Variable groups have been introduced in TFS/VSTS to address this need.
    https://www.visualstudio.com/en-us/docs/build/concepts/library/variable-groups

    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.

    18 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • SrhSloanSrhSloan commented  ·   ·  Flag as inappropriate

        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 HolbrookJustin Holbrook commented  ·   ·  Flag as inappropriate

        Good news, looks like this is already planned for the next release:

        https://www.visualstudio.com/en-us/articles/news/features-timeline

        2017 Q3 Build improvements – shared variable groups, multi-phase builds TFS vNext

        https://blogs.msdn.microsoft.com/bharry/2017/03/06/team-servicestfs-roadmap-update/

        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 HolbrookJustin Holbrook commented  ·   ·  Flag as inappropriate

        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 ReevesClayton Reeves commented  ·   ·  Flag as inappropriate

        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.

      • ZiloniZiloni commented  ·   ·  Flag as inappropriate

        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....

      • HBHB commented  ·   ·  Flag as inappropriate

        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.

      • J. Mike ZseraiJ. Mike Zserai commented  ·   ·  Flag as inappropriate

        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 StawskiJonas Stawski commented  ·   ·  Flag as inappropriate

        Another example, a base version number you want to keep across all your environments.

        $(Global.NextBaseVersion) //1.4.0
        $(Global.CurrentBaseVersion) //1.3.1

      • Ole André SchistadOle André Schistad commented  ·   ·  Flag as inappropriate

        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é SchistadOle André Schistad commented  ·   ·  Flag as inappropriate

        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.

      • ChristofflerouxChristoffleroux commented  ·   ·  Flag as inappropriate

        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 turkserdar turk commented  ·   ·  Flag as inappropriate

        this was requested since 2014 and it will help us greatly thinking that 3 different environment and over 50 release pipe to define.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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

      • AjayAjay commented  ·   ·  Flag as inappropriate

        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.

      • SeanSean commented  ·   ·  Flag as inappropriate

        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

      • RyanRyan commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base