You can define configuration variables at different scopes (release, server, environment, global, etc), and then reference those variables in your plan when using Operations, If/Else Blocks, Loop Blocks, etc. You can also create a runtime variable in a plan itself.
Configuration Variables cascade, which means that you can define a variable of the same name in multiple places,
and the correct value will be resolved at runtime. For example, if you define a variable named
Testing environment, when a plan runs against a server in the
Testing environment, that variable will resolve at runtime.
If you also defined
$HDarsPath on a single server in the
Testing environment, than that
value would be used instead.
This allows for reusing Plans and Templates without having to change local variables. There are times when it may be appropriate for variables to have different values when they are used different places, and BuildMaster allows for this.
The variable definition that's the "closest" match to the current context is used. This is determined as follows.
You can also assign multiple scopes to a configuration variable; for example, you could define a variable that's associated
with both the
Testing environment and the
hdars-web role. A multi-scope variable simply
adds precedence to the highest-scope (Promotion is still "closer" than a Environment + Application).
However, this get can get a bit tricky as the resolution rules are simply not intuitive, so we generally discourage this use. You can create multi-scoped variables from only the Administration section, and they are visible (but not editable) on servers, server roles, etc., they are associated with.
If you used configuration variables prior to BuildMaster 5.2 and earlier, see KB#1129: Legacy Configuration and Release Variables for more information on how legacy and non-legacy variables interact.