Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Classic release pipelines help you deploy applications to multiple environments in a secure and reliable way. Using classic release pipelines, you can automate testing and deployments, define flexible deployment strategies, add approval gates, and manage deployments across stages.
Prerequisites
| Product | Requirements |
|---|---|
| Azure DevOps | - An Azure DevOps organization. - An Azure DevOps project. |
How do release pipelines work
For each deployment, Azure Pipelines runs the following sequence of steps:
Pre-deployment approval:
When a deployment is triggered, Azure Pipelines checks whether a pre-deployment approval is required for the stage. If approval is required, it sends notifications to the configured approvers and waits for approval before continuing.
Queue deployment job:
Azure Pipelines queues the deployment job and schedules it on an available Agent.
Select an agent:
An available agent picks up the deployment job. Release pipelines can be configured to dynamically select an appropriate agent at runtime.
Download artifacts:
The agent downloads all artifacts associated with the release.
Run deployment tasks:
The agent executes the tasks defined in the deployment job for the stage.
Generate deployment logs:
The agent generates detailed logs for each deployment step and sends them back to Azure Pipelines.
Post-deployment approval:
After deployment to the stage completes, Azure Pipelines checks whether a post-deployment approval is required. Once approval is granted, or if no approval is required, the pipeline proceeds to the next stage.
Deployment model
Azure release pipelines support a wide range of artifact sources including Jenkins, Azure Artifacts, and Team City. This flexibility allows you to design deployment models that span multiple build systems and environments. The following example illustrates a deployment model using Azure release pipelines.
In this model, the release pipeline consumes two build artifacts produced by separate build pipelines. The application is first deployed to the Dev stage, followed by deployment to two parallel QA stages. After the application is successfully validated in both QA stages, it is deployed to Prod ring 1 and then to Prod ring 2.
Each production ring represents multiple instances of the same web application deployed to different geographic locations. This ring‑based approach enables gradual rollouts, controlled validation, and reduced risk during production deployments.
Releases vs deployments
A release is a construct that holds a versioned set of artifacts specified in a CI/CD pipeline. It includes a snapshot of all the information required to carry out all the tasks and actions in the release pipeline, such as stages, tasks, policies, and deployment options.
A single release pipeline can produce multiple releases. Azure Pipelines stores information about each release and displays it for the specified retention period.
A deployment is the execution of the tasks defined for a single stage in a release. A deployment can include actions such as running automated tests, deploying build artifacts, and performing any other tasks configured for that stage. When you create a release, Azure Pipelines initiates deployments based on the policies and settings defined in the release pipeline. A release can be deployed multiple times to the same stage. If a deployment fails for a stage, you can redeploy the same release to that stage by selecting Deploy from the release.
The following diagram shows the relationship between release pipelines, releases, and deployments.
