The job of a release is to use an artifact that was created by a build and deploy it to an environment.

Simple Pipeline.png

A release uses tasks, just like builds. Releases consume artifacts that have been created by a build and deploy them to an environment.


The above screenshot depicts the release pipeline we use for production. It uses a set of artifacts from a build in the master branch of version control. A set of tasks deploys the artifacts to the QA environment. At this point, processing is paused until it is approved. This is called a post-deployment approval.

The intent here is to have the final QA testing performed before the codebase is deployed to production. The approval occurs when all tests have been passed.

The codebase does not go directly into production; there is also a pre-deployment approval necessary for the final deployment into production.

Note: Approvals are optional and may be configured as needed. In fact, if approvals were left off, the codebase would be deployed without any interaction.

Release Example.png

This release deploys the website and database to the build environment. It then runs integration and automated QA tests.


Above we see that the artifacts are from the SPRINT – Sports Store Lab build. There is one environment, Build. There are six tasks.


We need some variables for the automated QA tests, including login credentials for the database and for the private agent. We will cover the details of automated QA tests in a later article.

NOTE: information for login credentials is protected and not visible.


The release has two tasks that deploy Sports Store:

Azure App Service Deploy: OcambSSBuildWeb – This task uses WebDeploy to deploy the website to an Azure App service. The following parameters are required:

  • Azure Subscription – This is an endpoint to an Azure subscription.
  • AppService name – This is the name of an existing Azure App Service application where the codebase will be deployed to. See the section on infrastructure as code to see how the App Service application is created.
  • Package or Folder – this is the name of the ZIP file generated by the artifacts that contains the bits for the website.

Execute Azure SQL: SportsStore Database – This deploys the database to Azure. It uses the specified DacPac and generates the SQL for updates based on the target database. It uses the following parameters:

  • Azure Subscription – This is an endpoint to an Azure subscription.
  • Azure SQL Server Name – This specifies the name of an existing Azure SQL Server. See the section on infrastructure as code to see how the SQL server is created.
  • Database Name – Our database name is SportsStore.
  • Server Admin Login – This is set to $(ServerAdminLogin).
  • Password – This is set to $(DBPassword).
  • DacPac File – This is the name of the DacPac file generated by the artifacts that contains the database schema.
  • PublishProfile – This is the name of the publish profile of the artifacts. We must set BlockOnPossibleDataLoss to false so that we can deploy the DacPac when schema changes cause data loss.

The tasks above are used for the integration and automated QA tests.

  • Deploy Test Agent – This task deploys a test agent on a private agent. This is required by automated QA tests. The details are covered in the linked article.
  • Copy Files – This task copies files needed by the automated QA tests.
  • Run Tests – This task is very similar to the task in the build. It is tailored to run on a private agent, and TestCategory is set to Nightly_Build.

Next, we will explore the release pipeline for releasing to production. There are many ways software can be released to a production environment. At the one extreme, firms such as Etsy deploy many times each day. Some firms regulated by agencies such as the FDA require multiple formal approvals.

We have chosen to require a set of approvals before SportsStore can be released to production. Our release pipeline is shown below.

Release Pipeline.png

Point 1 – When we are ready for the final testing and deployment to production, we perform a pull request into the master branch. When this is accepted, we have a release candidate in the master branch.

This release is not scheduled and must be manually invoked.

Point 2 – Visual Studio Team Services allows pre- and post-environment conditions. We have no pre-conditions for the QA environment, so when the release is invoked, the artifact is deployed to the QA environment.

Point 3 – We do have a post-deployment approval. The intent is to have the deployment pause and wait for formal QA in order to successfully complete.

Point 4 – We have a pre-deployment approval for production. This is so that a final person may approve the release. Once approved, the release is deployed to production.

Next, we will discuss Zero Downtime Releases.


For details on the topics covered in this article, please visit the links below. You may also download the source code for the DevOps Roadmap Lab on Git HubContact me to set up a free meeting where we can dive deeply into the lab material  and discuss your individual needs.

  • Microsoft’s introduction document on release management is useful.
  • Microsoft has a very useful portal devoted to DevOps containing valuable information on release pipelines and all things DevOps. It is available here