BuildMaster Documentation


  • Last Modified: 2019-02-14

Applications represent the components and services that you release in BuildMaster, and contain the pipelines, templates, variables, and plans used to perform releases. You can also use applications for security access control by granting and denying tasks to different users across applications.

Creating a New Application

You can open the Create New Application page from the application selector drop down or the applications overview page.

Cloning and Template Applications

There are times you may want to copy or "clone" an application, for example:

  • Templating – using an application with a common set of variables and other configuration that can serve as a template for creating new applications
  • Refactoring – instead of doing a major refactor on an existing application, you can clone it to a new application and modify the new application instead

You can use the application import and export feature for this. When performing a one-time application clone (such as of a refactor), there is little value in publishing the exported package to a ProGet feed. However, for template applications, maintaining these in a ProGet feed is considered a best practice.

Legacy Application Clone Feature

Prior to BuildMaster v6, the only way to clone applications was through the feature now called legacy application cloning. Importing applications is strongly preferred, but if you need to copy legacy features or configuration such as legacy deployment plans, you can use this feature from Admin > Legacy Features.

Deactivating and Purging Applications

You can deactivate or purge applications from Admin > Deactivate and Purge Applications.

Deactivating an application will cancel all of its releases, deactivate automatic builds, and remove it from navigation and other menus throughout BuildMaster, while keeping historical data for the application. You can still access a deactivated application by URL directly.

If you do not wish to keep any data or history for these applications, you may purge them from the system completely.

Application Groups

Applications may be placed in an application group, which serves a few purposes:

  • Visually grouping related applications in the user interface
  • Common set of variables across applications
  • Permissions that are shared across all applications in the group

Application groups are created from the application settings page, by typing in the name of a group that doesn’t exist. Empty application groups are automatically deleted.

Once an application group has been created in this manner, you can use that group name when scoping variables (Admin > Variables) or access controls (Admin > Tasks).


Deployables are an advanced feature, and with the introduction of OtterScript and the Inedo Execution Engine in BuildMaster v5, they offer significantly less benefits than in previous versions.

A deployable is intended to represent a "deployable component" of an application. For example, if you had a multi-tier application called HDARS, it might have an HDARS-Web, HDARS-Service, and HDARS-API deployable to represent each of the corresponding tiers.

You can add deployables to your application from the application settings tab, and once you create a deployable for your application, you will be able to select it for use in some contexts, including:

  • In the Visual Plan Editor, you will be given the option to specify a deployable name
  • When creating a release, you will select which deployables are to be included
  • You can specify a deployable for database connections and change scripts
  • You can filter and search for releases based on the deployables they include

If you add an "imported deployable" from another application, you will select a specific release of the other application when creating a release.

Deployables and OtterScript

In deployment plans, a deployable is used in a general block as follows:

for deployable HDARS-Web
    ... operations ...

This will set the "current deployable in context" to HDARS-Web, which means that if HDARS-Web is not included in the release, then the block is skipped.

You can also add variable key/value pairs to a deployable. When a deployable in context (as the case above), that variable will be evaluated.

If HDARS-Web was an "imported deployable", then $ReleaseNumber would resolve to that application's number instead of the current release number.

Best Practices: While we don’t consider them a legacy feature, they are mostly a "vestigial" feature that allowed previous versions of BuildMaster to perform "partial deployments" and cross-application orchestration (dependencies, artifacts, etc.).

However, you can also accomplish those goals through the use of configuration variables, release templates, and the "source" tab of the artifact operations. This may be more- or less-intuitive, depending on your familiarity with BuildMaster.

For monolithic applications, deployables are still quite useful, in that they are easier to visualize and work with than variables.

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.