Variables allow for extreme flexibility when modeling your deployment plans. There are a lot of uses for variables, some of the most common are:
Like configuration variables, which are essentially values that you can assign to a server, application, environment, release, etc., runtime variables are used by the execution engine while running a plan.
There are three types of runtime variables, and each is denoted by a prefix.
|$||String||a single value|
|@||List||an enumerable set of either Lists or Strings|
|%||Map||a set of key/value pairs with values being a String, List, or Map|
String variables are the most common, and are used about anywhere. Whenever you reference a string variable within another
block or statement, it is automatically replaced with the value. You can escape this with the grave apostrophe
Loop variables are used much less frequently, primarily as the source of a Loop Block.
Map variables are pretty rare, and are only used in operations needing an arbitrary list of key/value pairs
HTTP::Post) or in other really advanced scenarios.
When you create a runtime variable with the Set Variable Value statement, that variable will be accessible in the current and nested blocks. For example:
While setting both runtime and Configuration Variables may lead to confusion if over used it does allow for greater re-use of plans and templates by allowing the same plan or template to used at different development environments where things like certificates, keys, and data might need to be different for testing.
When a string variable is referenced in your plan, the execution engine first checks to see if there is a runtime variable with that name in the current scope. If not, then a configuration variable with that name is retrieved. We generally don't recommend doing this, as it may get quite confusing if others are trying to understand your plan.
You may have seen expressions like
$PathCombine($RootPath,Accounts) used in the examples; these are
variable functions, which take in a number of parameters and return a value.
All of the "built-in variables" like
@AllServers are implemented as variable functions.
You can create configuration or runtime variables with the same name of a variable function, but we don't recommend
it because it can get quite confusing if others are trying to understand your plan. If there is a variable of
the same name, that value will be used instead, unless you explicitly reference the
parameter list (such as
Variable functions are extensible, so you can write your own with a BuildMaster Extension.