I suggest you ...

Global variables at release management

At release management it would be great to use "globale" build varaibles. For example build path, build name, drop location. Also define variables at release template to use this for more custom tasks. Also fixed variables like, date, time and so on.

357 votes
Vote
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)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    21 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...
      • EvgenyEvgeny commented  ·   ·  Flag as inappropriate

        We need Global Variables support for "Agent based" deployments (NOT vNext)

      • Roopesh NairRoopesh Nair commented  ·   ·  Flag as inappropriate

        Roopesh Nair commented · October 27, 2014 02:10 · Flag as inappropriate

        Release Management Update 4 RC has enabled support for 'System variables' in vNext Release Templates.

        You can also define configuration variables at Global, Server, Component, in Action or using configuration file as well

        For list of new features in Update 4 RC, please refer to link

        http://www.visualstudio.com/news/vs2013-update4-rc-vs#ReleaseManagement

      • Reynaldo Zabala (RAZOREDGE)Reynaldo Zabala (RAZOREDGE) commented  ·   ·  Flag as inappropriate

        Christopher, are you able to get this to work in an agent based release template/ I've tried $(ApplicationPath) and $ApplicationPath and they are always null. I"m using Release Management Server 2013 Release 4.0 and I cannot get a value for ApplicationPath.

      • Christopher HawsChristopher Haws commented  ·   ·  Flag as inappropriate

        A handy hidden feature in Release Management is that you can use all of your TFS build variables inside of the arguments section of a component. So if you make a new component, inside of the Deployment Tool's Arguments, if you put $(TeamProject), Release Management will pick that variable up from the TFS Build. We use this to pass TFS Build parameters to scripts in release management.

      • Leon BouquietLeon Bouquiet commented  ·   ·  Flag as inappropriate

        Also, for the Standard releases, please include the release *name* as one of the build variables, so that I can create a backup directory based on that. Right now I'm using a timestamp-based name for the backup directory, but this makes it hard to roll back a release using these backups over multiple servers.

      • mylesmyles commented  ·   ·  Flag as inappropriate

        we really need this feature available for Standard releases. When will this be coming?

      • BobBob commented  ·   ·  Flag as inappropriate

        Not complete - please make system variables available to standard releases, not just vNext. The original request did not limit the feature to vNext.

      • bmycbmyc commented  ·   ·  Flag as inappropriate

        when this feature will be avaiable?
        it will help me so much!!
        do you have another suggestion how to use the environment name in configuration variables?

      • Steve FentonSteve Fenton commented  ·   ·  Flag as inappropriate

        We would love this feature at the deployment sequence level as there is a lot of repetition throughout a release at the moment, such as paths and connection strings.

      • Adam BezverkovAdam Bezverkov commented  ·   ·  Flag as inappropriate

        We were surprised at the lack of variable support, since the template is very workflow-esqe, and the variable implementation in workflow would solve all of the problems that are deal breakers for us now. We have a couple dozen servers to deploy several apps to, and without variables, it becomes unmaintainable quickly. A simple example of one website with AppPool creation and roll back requires defining the same AppPool name 4+ times.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        We need real variable support. We are having to hard code: c:\installdir\ in every step. (Creating service, changing credentials, creating website, etc etc) This will not scale out when we have multiple lower environments and a few dozen applications.

        Greg (GMO LLC)

      ← Previous 1

      Feedback and Knowledge Base