Legacy Configuration and Release Variables

KB#1128: Last Updated Aug 02, 2016

In BuildMaster 5.3, we introduced two new features that expanded-on and replaced existing features:

  • Release Templates – a template for an entire release definition (including variables, among other things), these replace “template variables”, which instead applied to every new release, package, or deployment created within an application
  • Configuration Variables – effectively a redux of the existing feature, but allowing for multiple scopes as well as list and dictionary variables

Because variables are a key component of many deployment plans, we decided to minimize the risk of change by implementing the new release templates and configuration variables in a "side-by-side" manner.

All Configuration Variables you set-up prior to 5.3 will work the same, but will be called Legacy Configuration and Legacy Release Variables in the web application.

You can migrate the legacy configuration variables using a tool in the administration section, and we may introduce a tool to create release templates from legacy release variables in a future version.

Evaluation and Precedence

The scoping rules for both legacy and non-legacy variables are the same (although, non-legacy variables may be multi-scoped), but a non-legacy variable will always override a legacy variable.

For example, if you have a both a system- and application-level legacy variable named AppPath, then the application-level legacy variable value will take precedence. However, if you add a non-legacy system variable named AppPath, then that will always take precedence over the application-level legacy variable.

Migrating away from Legacy Variables

Legacy variables will be supported indefinitely, so there's no rush to convert everything. However, having two sets of variables to maintain in your BuildMaster instance will be confusing, especially to new users who won't read this article. Moreover, most upcoming features (such as the ability to export a system configuration as code), will not take into consideration legacy variables.

The legacy configuration migration tool has two options (Copy Legacy Variables and Delete Legacy Variables), as well as a simulation mode.

Unless you have a tremendous number of complex variables set-up, you should be fine running a migration with both the Copy and Delete options. This will ensure a clean migration, and all of the variables deleted (as well as values) will be logged.