Octopus Deploy variables are often times difficult to get right in complex deployment scenarios. If the incorrect pattern is applied at the start of setting up your first project then it can become difficult to change or undo later on especially as you move into multi-project or multi-tenant deployment environments.
The purpose of variables in Octopus Deploy is to provide values and/or data to the steps in your deployment process.
Octopus Deploy provides two types of vars:
1) Variables (Static)
2) Templates (Dynamic)
Most likely you will work with these. They can be thought of as hard coded, static, and unchanging. If the values are changed then you will need to create a new release of your project(s) that reference them.
Variables can also have scope applied to them. Scope allows you to have multiple values for a single variable and those values will be applied when the appropriate scope is achieved. For example you can have a variable ConnectionString with a unique value for each of your environments (environment scope).
Other scopes exist and multiple scopes can be combined to make unique settings. So its possible to have a variable value scoped to the Web Application target of a Stage environment for a tenant tagged as legacy as an example.
Templates are reserved for multi-tenant deployment environments. A tenant can be thought of as a customer. Octopus allows you to create “customers” and then provide unique values to each of those customers (Template Variables). Unique patterns emerge from having this ability which will be discussed in another post.
One important thing to note about Templates is that they DO NOT have scope. I repeat Templates DO NOT have scope. This is a common mistake and one of the gotchas of working with Octopus Deploy Variables (Note: keep reading. I will provide some more insight in just a bit).
So not so bad right? There are static variables and dynamic templates. That’s not difficult at all. Well that’s just the start. Octopus also provides two different places where you can set your variables and templates:
- In a library variable set
- For each specific project
Library Variable Set
Variable sets are collections of variables and templates that can be attached to multiple projects. This allows you to reuse variables by defining them in one place and then reusing them with different projects. In this sense you can think of variable sets as being global variables.
Project Specific Vars
These are variables and templates that live with a specific project. Because they belong to a specific project they are not accessible by other projects. These can be thought of as local vars and they most definitely are not global in nature.
Remember earlier when I adamantly told you that Template variables don’t have scope? I lied. Templates that live in library sets do not have scope. However, Templates defined at the project level do have scope. In fact it’s actually forced upon you. With Project level templates you have to fill in values for each environment. For example, if you had a Project level template called MyTemplateVar you would have to enter a value for that variable for each environment:
One additional thing to point out here is that environment is the ONLY scope you can get and only if its a project level template.
Which variable should I choose?
Below is a flowchart that will assist in helping you to choose the appropriate variable for your needs.
No…. No, no no! I need Library Templates to have scope!
I know how you feel. You are angry. You are in a unique situation and you must absolutely have scoped library variable templates. You need unique tenant variables for every environment. If this is the case then it is advised that a really deep look is taken at the variables used in your project(s). There are options that involve variable substitution and naming conventions that 9 out of 10 times can work to get the desired effect without the need for globally available tenant variables scoped to different environments. Now, with that being said you have an option. I will outline the details of that option in another blog post coming soon.