Environments and Queueing Policies

In this step, we will cover the factors that you will encounter when you define and manage environments in the context of Continuous Integration and Continuous Delivery.

A release definition is essentially a collection of environments. To understand what you can control from your release definition, it is important to understand environments. Let’s start by taking a look at what an environment is, how environments are set up and what your approval options are in environments.

Environments

An environment is a logical entity that represents where you want to deploy a release. Physically, the deployment in an environment might happen to a collection of servers, a cloud, multiple clouds, or an app store.

When you deploy a release, the deployment steps in your environment are described by using tasks.

Here is an illustration of a release definition for pre-production and production environments

Note: If you are familiar with earlier versions of Visual Studio Release Management, the notion of environments is similar to that of stages in those earlier versions.

Creating Environments

Within your release definition, you can add, clone and use templates to create environments. These templates prepopulate the environment with the appropriate tasks and settings, which can considerably reduce the time and effort required to create a release definition.

Alternatively, you can choose to start with an empty release definition that contains only a single default empty environment, or an empty environment that contains no tasks.

You can also create your own custom environment templates from an environment that you have populated and configured.

Environment Approvals

You can define approvers for each environment in a release definition. When a release is created from a release definition that contains approvers, the deployment stops at each point where approval is required until the specified approver grants approval or rejects the release (or reassigns the approval to another user).

For more details, see Approve a release.

Queueing Policies

In some cases, you might be generating builds more quickly than they can be deployed. Alternatively, multiple users might be creating releases from the same release definition for the deployment of different artefacts.

It may be useful to control how multiple releases are queued into an environment. Queuing policies give you the control you need to queue multiple releases in an environment.

The options you can choose for a queuing policy are:

• Allowing multiple releases to be deployed at the same 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. Because the artefacts are deployed to independent physical resources, there is no conflict for these resources. This is typically the case in test environments.

• Allowing only one active deployment at a time. If you select this option, two more options appear:

  • Deploying all of them one after another. 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 deployment agents available. You also ensure that pre-deployment approval requests for the environment are sent out in sequence.

  • Deploying only the latest release. Use this option if you are producing releases faster than builds, and you only want to deploy the latest build.

Every release runs within a pipeline, and by default only one pipeline is available. This means that only a single release can be deployed at any one time. You can obtain and run additional pipelines for Team Services concurrently if you want to execute multiple deployments at the same time.

To understand how these options work, consider a scenario where releases R1, R2, …, R5 of a single release definition are created in quick succession due to new builds being produced rapidly.

Assume that the first environment in this definition is named QA and has both pre-deployment and post-deployment approvers defined.

• If you select Allow multiple releases to be deployed at the same time, all five approval requests will be sent out as soon as the releases are created. If the approvers approve all of the releases, they all will be deployed to the QA environment in parallel. (If the QA environment did not have any predeployment approvers defined, all the five releases will automatically be deployed in parallel to this environment.)

• If you select Allow only one active deployment at a time and Deploy all of them one after another, the predeployment approval for release R1 will be sent out first. After this approval is completed, the deployment of release R1 to the QA environment begins. Next, a request for post-deployment approval is sent out for release R1. It is only after this post-deployment approval is completed that execution of release R2 begins and its pre-deployment approval is sent out. The process continues like this for all of the releases in turn.

• The only other option, Allow only one active deployment at a time and Deploy only the latest release, is similar to the previous option. However, releases R2, R3, and R4 will be skipped, and the pre-deployment approval for R5 in the QA environment will be sent out immediately after the post-deployment approval for release R1 is completed.

Users with permission to edit release definitions can also configure the deployment queuing policies in the Triggers tab of a release definition.

In the next step, we will explore deployment triggers, variables and security.