Skip to content
← Product Feedback

What problem could Octopus Deploy solve for you?

Product Feedback: Deployments

Categories

(thinking…)

Associate variables with a Release when creating one

When creating a release, allow variable values to be set that will then flow through to all deployments of the release. See: https://github.com/OctopusDeploy/Issues/issues/1149#issuecomment-52598811

82 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Nicholas Blumhardt shared this idea  ·   ·  Report…  ·  Admin →

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Brian commented  ·   ·  Report

    I need to be able to pass variables from team city when creating the Octopus release. I want those variables to be remembered for every environment the release is deployed to. It seems like this is such a simple request and fundamental to deployment process. I am not sure why this feature does not exist currently. Smile. Have a nice day!

  • Will commented  ·   ·  Report

    Still no progress on this? I guess you might be able to make a direct API call to do the same? But then what's the point in octo.exe?

  • Tonni Hult commented  ·   ·  Report

    I agree that this is a much needed feature. And it should not matter if the variable originates from the project or a shared variable set.

  • Guillaume commented  ·   ·  Report

    I have an application where a single binary can be deployed for multiple tenants. When we deploy we need to be able to specify to which tenants it should be deploy, we are currenlty using a simple variable where we change the value before creating each release.

    It would be great to have the ability to mark this variable as prompt on release creation avoiding the change on the variable value at each release.

    Another option would be to keep the value of the prompted variables from the previous environment when promoting a release.

  • D Lemos commented  ·   ·  Report

    This would be fantastic. At the moment we have to modify our scripts to adapt to our QA which includes the branches in their bindings. We basically have to set variables in a previous step in order to be available in the next step. It is too cumbersome.

    We should be able to set variables and access them throughout the deployment.

  • James Nail commented  ·   ·  Report

    +1 on this... otherwise, the thing I'd like to do is for a set of config variables to be able to have an affinity to a version of my application.
    The idea here is that as you develop your applicatioh, your configs will evolve (sometimes adding, renaming, or removing config keys), so a deployment that works on version "n" of your app might not really be compatible with version "n+1" (or "n-1").

    I'm currently exploring this concept right now in my own work, so I don't yet have a real recommendation on HOW this needs to work, but the concepts are discussed in Chapter 2 of Continuous Delivery.