Common Uses for Variables

When used in different ways, BuildMaster variables can be an extremely powerful tool in creating an automated, repeatable deployment process. The following are some common uses for variables.

Setting a global constant for use anywhere in BuildMaster

Yes, a "constant variable" is an oxymoron, but you can use System variables to create a key/value pair that can be replaced throughout the whole system.

Pulling code from different branches

There are two fundamental branching strategies that can be used to develop software: branch by exception (e.g. a new release/feature branch and merge into trunk for deployment) and branch by rule (e.g. deployed branch becomes the new trunk).

To support these patterns within BuildMaster, a Release variable can be used to determine which branch to build from. For example, in your Get Latest from source control action, you can use variables in the source path to pull from a branch. When building BuildMaster extensions, we use the following: Get latest from "bmx-%APPNAMELOWER%|%BUILD-SOURCE%:", where BUILD-SOURCE is a release variable that points to the branch on GitHub to build.

Optional behavior during a particular execution

There are times during deployment scenarios where a certain group of actions only needs to be run sometimes. This can be accomplished with really any scope of variable, but must commonly either a Build variable or a Promotion variable. Combined with a "Variable Value" predicate on an action group, that group will only execute its actions if the variable is set for your particular build, promotion, release, or whatever scope the variable happens to be.

Note that running certain action groups during an execution can also be accomplished with a combination multiple deployables and predicates, but deployables should represent individual components of your application and not "optional" behavior such as the examples listed below.

Typical examples of this scenario include:

  • rebuilding the integration database from scratch on a build to integration
  • restoring a database from production when building to integration
  • determining whether the code was pulled from a branch
  • whether to run unit tests or not

Setting the build configuration for your project for each build

With a Build variable for example, you could change the behavior of MSBuild to set the build configuration to the variable %BUILD-CONFIG%, whose value is selected from a dropdown at build time to either "Debug" or "Release", which in turn would build that configuration in the Integration environment. Combined with a "Variable Value" promotion requirement, you could block promotion beyond Testing for example, unless that value is set to "Release" to ensure that Debug builds never make it out of your testing environment.

Changing a path for a particular server in a server group

When deploying to server groups, it's possible that one of the servers is a "one-off" with a different deployment path or configuration. By setting a Server variable, you could control the path on that single server by overriding the default value of that variable just for that server.

Auto-deployment to the next environment

With the Auto-Promote Build trigger, BuildMaster can promote a build to the next environment automatically by checking the value of a variable to determine if it should do so.

… anything!

Variable types and editors are extensible and can be created custom to fulfill whatever variable deployment scenario you can imagine.