BuildMaster Documentation

Environments

Last Modified: 2018-05-29

An environment is a logical grouping of Servers, and generally describes one stage of the development process (development, testing, Q/A, production, staging, etc.). But they can also describe a physical location (NYC-DC1, Tokyo-DC1) or even a customer site.

Environments are also used in security and access controls to permit and restrict users from performing various tasks. For example, you could permit “QA Users” to deploy applications to the Testing environment, while restricting them from deploying to the Production environment.

BuildMaster comes with three, built-in environments that represent a very simple deployment pipeline: Integration, Testing, and Production. You can create, rename, and delete environments as needed.

Nested Environments

Environments may have parent environments, which you use to define a hierarchy of environments. For example, you could have Prod-Main and Prod-Backup both under the Production environment.

This not only helps with visualization, but it can simplify the access controls you define. For example, if you restricted access to Production, then Prod-Main and Prod-Backup would also be restricted unless you define a more granular access control on one of the child environments.

Configuration variables will also cascade from a parent to a child environment, which means that deployments to a child environment will have access to the parent environment’s variables if they are not defined on the child environment.

Multiple Environments per server

You can associate a server with more than one environment, though it's generally not recommended because it may create unexpected behaviors for other users in your organization.

Also, both sets of permissions and restrictions will be applied, and if they overlap (one environment grants some things, while the other denies other things), then that will yield unpredictable and ambiguous behavior.