How to Create a Release Pipeline in Azure DevOps

A successful build does not guarantee a safe deployment. A team can pass every test, then accidentally publish an older package or send development settings to production. Manual deployment steps make those mistakes harder to trace and repeat.

Learning how to create a release pipeline in Azure DevOps helps you promote a known application package through controlled stages, with deployment logs and approvals attached to each release.

This guide walks through a Classic release pipeline that deploys a tested package to Azure App Service, explains the security decisions, and shows how to validate and recover from a deployment.

Understand Classic Releases Versus YAML Pipelines

Azure DevOps supports release workflows through both Classic release pipelines and multi-stage YAML pipelines.

Classic releases use the visual editor under Pipelines > Releases. YAML pipelines store build and deployment instructions in the repository, making changes available for code review.

This tutorial uses Classic because “create a release pipeline” commonly refers to that interface. For a new project, also evaluate YAML, especially when your organization requires pipeline-as-code.

Classic pipeline creation can be disabled at organization or project level. New organizations may have these restrictions enabled by default, so a missing Releases option is not necessarily an installation problem.

Pro Tip: I recommend choosing the release model with your platform team before building it. Do not enable Classic pipelines just to follow a tutorial if your organization deliberately requires YAML.

1. Prepare the Application and Deployment Target

Use a small application in a development environment first. This example assumes:

• An Azure DevOps project with a repository.
• A successful build that publishes a ZIP package.
• An existing Linux Azure App Service with a compatible runtime.
• Permission to create releases and use an approved service connection.
• An available agent pool.

Azure App Service hosts the application. Its App Service plan supplies the underlying compute capacity. A release pipeline deploys application content; it does not automatically create that hosting infrastructure.

Keep development and production settings separate. Use meaningful resource names such as orders-api-dev, and choose a region appropriate for users, dependencies, and data requirements.

For background, review what Azure App Service is and the Azure DevOps beginner tutorial.

Pro Tip: I recommend starting with a development target that contains no production data. The first goal is to verify the deployment path, not to test how quickly a mistake reaches customers.

2. Publish a Deployable Build Artifact

A release should deploy the package that passed testing—not rebuild the application independently.

For an existing .NET build pipeline, the following steps publish an application and store its ZIP as a build artifact:

steps:
- task: DotNetCoreCLI@2
  displayName: Publish application
  inputs:
    command: publish
    publishWebProjects: false
    projects: src/Orders.Api/Orders.Api.csproj
    arguments: >
      --configuration Release
      --output $(Build.ArtifactStagingDirectory)/publish
    zipAfterPublish: true

- tas