Variables in BuildMaster may be used in your deployment
plans as direct value substitutions in text fields or to
control which Action Groups execute. They are defined ahead of time (either at the System-level
or Application-level), and their values are set as needed.
A variable's scope determines where it's values will be defined. While there can
only be a single value for a System-scoped variable, a Release-scoped variable
can have a different value defined for each release. The available variable scopes are as follows.
- Application Group
This scoping makes it not only easier to set up relevant variables (one
application may need a "Branch Name" variable, while a server may need a "Root
Application Path" variable), but allows for values to be overriden at a lower
Creating a Variable
To create an Application-level variable, first click on "Settings" in the navigation menu, then "Manage Variables".
A System-level variable may be created by clicking on "Admin" (for system administration) then going to "Manage Variables".
Clicking the "Create New Variable" page will allow you to select a variable type from a list of defined variable types.
Variable Types are extensible, and a custom variable type may be added by inheriting VariableBase in the BuildMaster SDK.
Variable that represents a server or server group.
Constrained to a set of predefined values. (Example: value may be "yes" or "no")
Any text may be supplied.
Any numeric value may be supplied.
Any text that validates against a supplied .NET-style regular
Selecting the type of variable will display a page used for configuring the
variable's scope, default values, and any other configuration required for that
type of variable. For Dropdown List variables, the following settings may be
used to create a simple Yes/No variable at the Application Build level:
Default and Required Values
With the exception of build- and promotion-scoped variables, all variables must have a default value.
The default value is used when a value was not defined on a specific scope; for example, if a release-scoped
variable named "Emergency Release" was created with a default value of "No", then all Releases that don't define
a value for this variable will use "No".
Instead of specifying a default value, build- and promotion-scoped variable definitions may require that
a value is entered before creating or promoting a build.
Action Groups and Variables
See Predicates for information
on how to use variables to control Action Group execution.
Actions and Variables
Variables may be used in any BuildMaster Action that accepts text input. For
example, a Create File Action may be used to write the current Release Number to
a text file as part of a deployment plan:
Any variable may be used in this manner, whether it is a system-defined
variable like RELNO or any user-defined application variable. Simply use the
%VARIABLENAME% notation to have BuildMaster make the replacement.
Variable Server Names
A Variable Name may be used in place of a server name. When this is done, the server name will be resolved
at execution time based on the cascaded values. Note that this may pose as a security risk, as a developer
without production privileges could create an action that executes on a production server using a variable.
Escaping % Characters in Configuration Files and Actions
Since BuildMaster recognizes the percent sign as the start of the variable name in a line, it is necessary to escape its
literal use in actions and configuration files with another % in front of it: %% . This will be replaced
with a single % sign by the variables engine.
For example, if you have a configuration file that contains a URL
You'll need to escape the %
signs to prevent issues with the variable system:
For your convenience, BuildMaster has a number of built-in variables which
may be used in any deployment plan:
|RELNO||The release number of the current build.|
|BLDNO||The current build number.|
|REFAPPID||If there is a referenced deployable for this application, the numeric ID of that deployable's host application.|
|REFAPPNAME||If there is a referenced deployable for this application, the name of that deployable's host application.|
|REFRELNO||If there is a referenced deployable for this application, its release number.|
If there is a referenced deployable for this application, its build number. If you have set "UseFurthestBuild" to "True" in the advanced configuration,
this will use the build number from the furthest environment (as opposed to the largest build number).
|PREVRELNO||The release number of the most recently deployed release.|
|PREVBLDNO||The build number of the most recently deployed release.|
|LASTBLDNO||The most recent build number for the current release that was created before the current build number.|
|DATE1||A timestamp in the format of YYYYMMDD.|
|DATE2||A timestamp in the format of YYYYMMDDHHMMSS.|
A timestamp in a custom format, where d is a valid .NET date/time format string.
|APPID||The numeric ID of the current application in BuildMaster.|
|APPNAME||The name of the current application.|
|APPDESC||The description of the current application.|
|RELNAME||The name of the release of the current build.|
|ENVID||The environment ID of the currently executing build.|
|ENVNAME||The environment name of the currently executing build.|
|DEPID||The ID of the deployable associated with the currently executing action group.|
|DEPNAME||The name of the deployable associated with the currently executing action group.|
|EXECUSER||The name of the user that initiated the execution.|
|SRCDIR||The path to the current source directory for a remote action.|
|TRGTDIR||The path to the current target directory for a remote action.|
|APPDIR||The path to the "Application Home Directory" (represented in paths by a ~\).|
|LASTEXITCODE||The exit code of the last process launched by an action.|
|LASTEXITCODEHEX||The exit code (in hexadecimal) of the last process launched by an action.|
|YOUR_VARIABLE_NAME||The value of the variable with the name YOUR_VARIABLE_NAME.|
This content has the following tags: