Environments

An environment is a logical and independent entity that represents where you want to deploy a release generated from a release definition.

First, an environment in a release definition is a logical entity. It can represent any physical or real environment that you need. For example, the deployment in an environment may be to a collection of servers, a cloud, or multiple clouds.

Second, you must be able to deploy to an environment independently of other environments in the definition. For example, your definition might consist of two environments A and B, and Release Management could deploy Release 2 to A and Release 1 to B. If you make any assumptions in B about the existence of a certain release in A, the two environments are not independent.

Release

Queuing policies

In some cases, you may be generating builds more quickly than they can be deployed. Alternatively, you may configure multiple agents and, for example, be creating releases from the same release definition for deployment of different artifacts. In such cases, it's useful to be able to control how multiple releases are queued into an environment. Queuing policies give you that control.

The options you can choose for a queuing policy are:

  • Maximum number of deployments that can proceed at one time: Use this option if you dynamically provision new resources in your environment and it is physically capable of handling the deployment of multiple releases in parallel, but you want to limit the number of parallel deployments.

  • If you specify a maximum number of deployments, two more options appear:

    • Deploy all of them in order of request: Use this option if you want to deploy all the releases sequentially into the same shared physical resources. By deploying them in turn, one after the other, you ensure that two deployment jobs do not target the same physical resources concurrently, even if there are multiple build and release agents available. You also ensure that pre-deployment approval requests for the environment are sent out in sequence.

    • Deploy only the latest request and cancel the older ones: Use this option if you are producing releases faster than builds, and you only want to deploy the latest build.

Environment general options

While the most important part of defining an environment is the automation tasks, you can also configure several properties and options for an environment in a release definition. You can:

  • Edit the name of the environment here if required.

  • Designate a single user or a single group to be the environment owner. Environment owners are notified whenever a deployment of a release is completed to that environment. Environment owners are not automatically assigned any addition permissions.

  • Prevent the user who created a release or started the deployment from approving his or her own release. This is often useful to ensure compliance with corporate audit requirements.

  • Force the identity of the user to be re-evaluated before the approval is processed and accepted.

  • Delete the environment from the pipeline.

  • Save a copy of the environment as a template.

  • Manage the security settings for the environment.