I have a project which requires each environment to have 10 variables - I set these 10 variables to the environment using the scope. So if I have 7 environments which I deploy to, I would have 70 variables in total (each 10 scoped to a different environment).
Currently when I add a new environment, I have to duplicate each variable one at a time by right-clicking and selecting duplicate. This works ok, but it’s slightly cumbersome.
I’d like to know if there is a way that I can have these 10 variables as some kind of template, and when I add a new environment, I can just drop in 10 new variables and then assign the new environment to them. This would leave me to just fill in the desired values for each which would be much simpler.
Thanks for getting in touch! While there’s no built-in way to duplicate a list of variables in the UI, it is possible to script this via the API. Though, depending on the nature of your variables, I may suggest a different approach. Can you expand on what you’re using the variables for exactly?
A potential solution would be to move towards using convention based values for your variables where possible. For example, if your variable values are only differing by environment name, you could instead use one single variable to cover all environments (instead of duplicating your variables and scoping to individual environments). Say you have a variable called URL, with a value of http://Octopus.com/Development for your Development environment (and so on for each environment). Using the value http://Octopus.com/#{Octopus.Environment.Name} instead will make the value dynamic across all environments. This will negate the need to duplicate your variables, and limits your total number of variables. It will also work in the future if you add another environment without having to duplicate them each time.
Let me know what you think, and if you have any further questions.
Thanks for taking the time to reply. The variables all have exactly the same name for each environment - it is only the value which is different. Here are a few of the variables I am using:
WebInstallPath (this could be “C:\www” for one environment, and “Z:\webs\www” on another - no common pattern at all)
ConnectionStr - again, this is very different for each environment.
YearStarting - in integer which might be 2013 at one environment, and 2015 at another.
It sounds like the convention-based rules might be too rigid for our requirements. I’m keen to hear more about the API route though.
However, I would also like to suggest a potential alternative. If you’re using environments as tenants (i.e. you create a separate environment per customer), you may like to consider using multi-tenancy. This feature was added in Octopus 3.4, and there may be a couple of great advantages for your case.
Tenants would automate creating these variables.
It would limit the total number of environments, as it allows you to deploy multiple instances of your project into one environment.