In a multi-stage pipeline, it is not possible to define approvers as it is in a classic release pipeline. The reason for this is that the pipeline – the build and deployment process – is viewed as code. Code is worked on by developers and operators only. Approvals are worked on by, for example, product owners. However, this does not mean that it is not possible to implement approval flows for the progression of a pipeline to the next stage.

To control whether a pipeline is allowed to proceed to a certain stage, the concept of environments needs to be introduced. An environment is defined when we give it a name and a description. One or more approvers can be attached to these environments. Once this is done, jobs can be configured to target such an environment. If there is at least one job in a stage that targets an environment, then that environment is said to be used by the stage. If an approval has been configured on that environment, the deployment to that stage will not continue until the approver has given permission.

To start working with environments, you'll need to access the list of environments. This list be found in the Pipelines menu, as shown in the following screenshot:

To add a new environment, perform the following steps:

1. Open the Pipelines menu and choose Environments.
2. Select New environment from the top right.
3. Specify a name and description.
4. Click Create.

It is possible to associate resources with an environment. Resources that are coupled with an environment can be used in a pipeline if, and only if, that pipeline is also targeting that environment. To protect the resources of an environment, the owner of that environment can add one or more approvers. An example of a configured approver can be seen in the following screenshot:

Approvers can be added to an environment as follows:

1. Navigate to the Environments overview pane.
2. Open an environment by clicking on it.

3. Click the top-right menu marked with the three dots, and and choose Approvals and Checks.
4. Click the Create button.
5. Pick a user or group from the list and add extra instructions if needed.
6. Click the Create button again.

Approvals make it possible for you to control the progression of a pipeline to the next stage if that pipeline targets the correct environment. Targeting an environment is done by specifying a specific type of job: the deployment job. The following YAML shows how to do this:

jobs:
- deployment: deplyoymentJobName
  displayName: Friendly name
  strategy:
  runOnce:
    deploy:
      steps:
      …

Deployment jobs do not directly contain the steps to execute like an agent job does. Instead, they first have to specify an execution strategy for the tasks outlined under the steps keyword. At the time of writing, the only strategy supported is runOnce. Other strategies are expected to be announced in the future.

At the time of writing, only Kubernetes clusters are supported as environment resources, but more types of resources have been announced for the future.

Now that we know about the technical means for creating release definitions and writing multi-stage YAML pipelines, it is time to take a look at the different strategies we can use to apply this in practice. These continuous deployment strategies are designed to minimize the risk of deploying new versions of an application automatically.