Define your Classic pipeline
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure Pipelines provide a highly configurable and manageable pipeline for releases to multiple stages such as development, staging, QA, and production. It also offers the opportunity to implement gates and approvals at each specific stage.
In this tutorial, you'll learn about:
- Continuous deployment triggers
- Adding stages
- Adding pre-deployment approvals
- Creating releases and monitoring deployments
Prerequisites
You'll need:
A release pipeline that contains at least one stage. If you don't already have one, you can create it by working through any of the following quickstarts and tutorials:
Two separate targets where you'll 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 Service website instances. If you decide to do the same, you'll 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. Use the Azure portal to create a new web app.
Continuous deployment (CD) triggers
Enabling continuous deployment trigger will instruct the pipeline to automatically create a new release every time a new build is available.
In Azure Pipelines, open the Releases tab. Select your release pipeline, then select Edit.
Select 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.
Select the Pre-deployment conditions icon in the Stages section to open the conditions panel. Make sure that the trigger for deployment to this stage is set to After release. This means that a deployment will be initiated automatically when a new release is created from this release pipeline.
You can also set up Release triggers, Stage triggers, or schedule deployments.
Add stages
In this section, we'll add two new stages to our release pipeline: QA and production (Two Azure App Services websites in this example). This is a typical scenario where you would deploy initially to a test or staging server, and then to a live or production server. Each stage represents one deployment target.
Select the Pipeline tab in your release pipeline and select the existing stage. Change the name of your stage to Production.
Select the + Add drop-down list and choose Clone stage (the clone option is available only when an existing stage is selected).
Typically, you want to use the same deployment methods with a test and a production stage so that you can be sure your deployed apps will behave the same way. Cloning an existing stage is a good way to ensure you have the same settings for both. You then just need to change the deployment targets.
Your cloned stage will have the name Copy of Production. Select it and change the name to QA.
To reorganize the stages in the pipeline, select the Pre-deployment conditions icon in your QA stage and set the trigger to After release. The pipeline diagram will then show the two stages in parallel.
Select the Pre-deployment conditions icon in your Production stage and set the trigger to After stage, then select QA in the Stages drop-down list. The pipeline diagram will now indicate that the two stages will execute in the correct order.
Note
You can set up your deployment to start when a deployment to the previous stage is partially successful. This means that the deployment will continue even if a specific non-critical task have failed. This is usually used in a fork and join deployments that deploy to different stages in parallel.
Select the Tasks drop-down list and select the QA stage.
Depending on the tasks that you're using, change the settings so that this stage deploys to your "QA" target. In our example, we'll be using Deploy Azure App Service task as shown below.
Add Pre-deployment approvals
The release pipeline we previously modified deploys to QA and production. If the deployment to QA fails, then deployment to production won't trigger. It's recommended to always verify if your app is working properly in QA or test stage before deploying to production. Adding approvals will ensure all the criteria are met before deploying to the next stage. To add approvals to your pipeline follow the steps below:
Select the Pipeline tab, Pre-deployment conditions icon then Pre-deployment approvers.
In the Approvers text box, enter the user(s) that will be responsible for approving the deployment. It's also recommended to uncheck the The user requesting a release or deployment should not approve it check box.
You can add as many approvers as you need, both individual users and organization groups. It's also possible to set up post-deployment approvals by selecting the "user" icon at the right side of the stage in the pipeline diagram. For more information, see Releases gates and approvals.
Select Save.
Create a release
Now that the release pipeline setup is complete, it's time to start the deployment. To do this, we'll manually create a new release. Usually a release is created automatically when a new build artifact is available. However, in this scenario we'll create it manually.
Select the Release drop-down list and choose Create release.
Enter a description for your release, check that the correct artifacts are selected, and then select Create.
A banner will appear indicating that a new release has been created. Select the release link to see more details.
The release summary page will show the status of the deployment to each stage.
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 stage 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.
Select the pending_approval icon to open the approval window panel. Enter a brief comment, and select Approve.
Note
You can schedule deployment at a later date, for example during non-peak hours. You can also reassign approval to a different user. Release administrators can access and override all approval decisions.
Monitor and track deployments
Deployment logs help you monitor and debug the release of your application. To check the logs of our deployment follow the steps below:
In the release summary, hover over a stage and select Logs.
During deployment, you can still access the logs page to see the live logs of every task.
Select any task to see the logs for that specific task. This makes it easier to trace and debug deployment issues. You can also download individual task logs, or a zip of all the log files.
If you need additional information to debug your deployment, you can run the release in debug mode.