Define your multi-stage continuous deployment (CD) process

Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) provide a highly configurable and manageable pipeline for releases to multiple environments such as development, staging, QA, and production environments; including requiring approvals at specific stages.

In this tutorial, you learn about:

  • Configuring triggers within the release pipeline
  • Extending a release definition by adding environments
  • Configuring the environments as a multi-stage release pipeline
  • Adding approvals to your release pipeline
  • Creating a release and monitoring the deployment to each environment


You'll need:

  • A release definition that contains at least one environment. If you don't already have one, you can create it by working through any of the following quickstarts and tutorials:

    or see How to: Work with release definitions.

  • Two separate targets where you will deploy the app. These could be virtual machines, web servers, on-premises physical deployment groups, or other types of deployment target. In this example, we are using Azure App Services website instances. If you decide to do the same, you will have to choose names that are unique, but it's a good idea to include "QA" in the name of one, and "Production" in the name of the other so that you can easily identify them. If you need help, follow the steps in this example.

Configure the triggers in your release definition

In this section, you will check that the triggers you need for continuous deployment are configured in your release definition.

  1. In the Build & Release hub, open the Releases tab. Select your release definition and, in the right pane, choose Edit.

    Opening the release definition for editing

  2. Choose the Continuous deployment trigger icon in the Artifacts section to open the trigger panel. Make sure this is enabled so that a new release is created after every new successful build is completed.

    Viewing the continuous integration trigger setting

    For more information, see Release triggers in the Release Management documentation.

  3. Choose the Pre-deployment conditions icon in the Environments section to open the conditions panel. Make sure that the trigger for deployment to this environment is set to Release. This means that a deployment will be initiated automatically when a new release is created from this release definition.

    Viewing the environment trigger setting

    Notice that you can also define artifact filters that determine a condition for the release to proceed, and set up a schedule for deployments. You can use can features to, for example, specify a branch from which the build artifacts must have been created, or a specific time of day when you know the app will not be heavily used. For more information, see Environment triggers in the Release Management documentation.

Extend a release definition by adding environments

In this section, you will add a new environment to the release definition. The two environments will deploy your app to the "QA" and the "Production" targets (in our example, two Azure App Services websites). This is a typical scenario where you deploy initially to a test or staging server, and then to a live or production server. Each environment represents one deployment target, though that target could be a physical or virtual server, a groups of servers, or any other legitimate physical or virtual deployment target.

  1. In the Pipeline tab of your release definition, select the existing environment and rename it to Production.

    Renaming the existing environment

  2. Open the + Add drop-down list and choose Clone environment (the clone option is available only when an existing environment is selected).

    Cloning the existing environment

    Typically, you want to use the same deployment methods with a test and a production environment so that you can be sure the deployed apps will behave in exactly the same way. Therefore, cloning an existing environment is a good way to ensure you have the same settings for both. Then you just need to change the deployment targets (the websites where each copy of the app will be deployed).

  3. The clone of the environment appears after the existing environment in the pipeline, and has the name Copy of Production. Select this environment and, in the Environment panel, change the name to QA.

    Renaming the clone environment

  4. To reorganize the environments in the pipeline, choose the Pre-deployment conditions icon for the QA environment and set the trigger to After release. The pipeline diagram changes to show that the deployment to the two environments will now execute in parallel.

    Changing the QA environment trigger

  5. Choose the Pre-deployment conditions icon for the Production environment and set the trigger to After environment, then select QA in the Environments drop-down list. The pipeline diagram changes to show that the deployment to the two environments will now execute in the required order.

    Changing the Production environment trigger

    Notice that you can specify deployment to start when a deployment to the previous environment is partially successful. Usually, this means the deployment tasks were set to continue the deployment even if a specific non-critical task failed (the default is that all tasks must succeed). You're most likely to set this option if you create a pipeline containing fork and join deployments that deploy to different environments in parallel.

  6. Open the Tasks drop-down list and choose the QA environment.

    Open the tasks pane for the QA environment

  7. Recall that this environment is a clone of the original Production environment in the release definition. Therefore, currently, it will deploy the app to the same target as the Production environment. Depending on the tasks that you are using, change the settings so that this environment deploys to your "QA" target. In our example, using Azure App Services websites, we just need to select the Deploy Azure App Service task and select the "QA" website instead of the "Production" website.

    Change the deployment target the QA environment

    If you are using a different type of task to deploy your app, the way you change the target for the deployment may differ. For example, if you are using deployment groups, you may be able to select a different deployment group, or a different set of tags within the same deployment group.

Add approvals within a release definition

The release definition you have modified deploys to test and then to production. If the deployment to test fails, the trigger on the production environment does not fire, and so it is not deployed to production. However, it is typically the case that you want the deployment to pause after successful deployment to the test website so that you can verify the app is working correctly before you deploy to production. In this section, you will add an approval step to the release definition to achieve this.

  1. Back in the Pipeline tab of the release definition, choose the Pre-deployment conditions icon in the Environments section to open the conditions panel. Scroll down to the Pre-deployment approvers section and expand it using the "down arrow" icon. You can see that the approval type is set to Automatic, which means that deployment to this environment, when initiated by any of the environment triggers, will be approved without user intervention - and deployment will commence immediately.

    Viewing the pre-deployment approvers settings

  2. Change the approval type to Specific users and choose your account from the list. You can type part of a name to search for matches.

    Selecting the pre-deployment approvers

    You can add as many approvers as you need, both individual accounts and account groups. It's also possible to set up post-deployment approvals by choosing the icon at the right side of the environment item in the pipeline diagram. For more information, see Environments in Release Management.

  3. Save the modified release definition.

    Save the release definition

Create a release

Now that you have completed the modifications to the release definition, it's time to start the deployment. To do this, you create a release from the release definition. A release may be created automatically; for example, the continuous deployment trigger is set in the release definition. This means that modifying the source code will start a new build and, from that, a new release. However, in this section you will create a new release manually.

  1. Open the Release drop-down list and choose Create release.

    Creating a new release

  2. Enter a description for the release, check that the correct artifacts are selected, and then choose Queue.

    Queuing the new release

  3. After a few moments, a banner appears indicating that the new release was created. Choose the link (the name of the release).

    The link to the newly created release

  4. The release summary page opens showing details of the release. In the Environments section, you will see the deployment status for the "QA" environment change from "IN PROGRESS" to "SUCCEEDED" and, at that point, a banner appears indicating that the release is now waiting for approval. When a deployment to an environment is pending or has failed, a blue (i) information icon is shown. Point to this to see a pop-up containing the reason.

    Release summary showing link for approval

    Other views, such as the list of releases, also display an icon that indicates approval is pending. The icon shows a pop-up containing the environment name and more details when you point to it. This makes it easy for an administrator to see which releases are awaiting approval, as well as the overall progress of all releases.

    Release list showing link for approval

  5. Choose the Approve or Reject link to open the approval dialog. Enter a brief note about the approval, and choose Approve.

    Approving the release

    Notice that you can defer a deployment to a specific day and time; for example, a time when you expect the app to be only lightly loaded. You can also reassign the approval to another user. Release administrators can open any approval and over-ride it to accept or reject that deployment.

Monitor and track deployments

In this section, you will see how you can monitor and track deployments - in this example to two Azure App Services websites - from the release you created in the previous section.

  1. In the release summary page, choose the Logs link. While the deployment is taking place, this page shows the live log from the agent and, in the left pane, an indication of the status of each operation in the deployment process for each environment.

    Viewing the live deployment log

  2. After the deployment is complete, the entire log file is displayed in the right pane. Select any of the process steps in the left pane to show just the log file contents for that step. This makes it easier to trace and debug individual parts of the overall deployment. Alternatively, download the individual log files, or a zip of all the log files, from the icons and links in the page.

    Viewing and downloading individual log files

  3. Open the Summary tab to see the overall detail of the release. It shows details of the build and the environments it was deployed to - along with the deployment status and other information about the release.

    Viewing the summary page

  4. Select each of the environment links to see more details about existing and pending deployments to that specific environment. You can use these pages to verify that the same build was deployed to both environments.

    Viewing details from one environment

  5. Open the deployed production app in your browse. For example, for an Azure App Services website, from the URL http://[your-app-name]

    Viewing the deployed app in the production environment

If you are having problems with a deployment, you can get more information from the log files by running the release in debug mode. For more information, see How To: Monitor releases and debug deployment issues.

Next step