How to create an Automated Release Pipeline

In this article, we are going to construct a release pipeline that leverages the advanced features available within Release Management.

Creating an Automated Release Pipeline

From within the building hub in Visual Studio Team Services, you will see that our build pipeline has a versioning task, it restores packages, runs unit testing and creates artefacts.

With our pipeline in place, we can move back into Workflow in the Release Hub. From here, you can either create a new release pipeline from within the Release hub, or you can initiate a new release definition from the Build Hub. Within the Release Hub, the Release Workflow will plug a few things into the pipeline so that you can start creating your release definition.

Note: You can divide your release definition into phases. Here we have four phases:

1. Run-on Agent (Hosted Agent): To do configuration transformation, deploy to Azure and deploy to Azure Databases.
2. Test Assemblies (Selenium Agents Dev Test Labs): To set up frameworks that are required to run tests, such as the Selenium test.
3. Manual Checks and Sign Off: To manually check that the deployment is correct and to approve the deployment.
4. Run Load Test (Hosted and Selenium Agents Dev Test Labs): To only send requests to agents who have the skill capability match that is demanded.

Additional Environment Options

We have established that we have one environment available in our example. Some additional options we have at our disposal include:

• Assign Approvers Workflow: This is useful when you want to assign specific users to sign off on the execution of the release in your environment
• Email Alerts: This option is useful when you want to notify specified users if something goes wrong in your environment.
• Core ownership: This is useful for communication, especially when you have multiple owners of an environment or multiple people sharing an environment.
• Deployment Conditions: When you have more than one environment, you can set policies that only execute to the second environment when execution to the first environment is complete.
• Schedules: This is useful for scheduling processes that are run regularly.

Triggering a Release

When your build is set up, you can trigger a release. You will be notified of any artefacts that are associated with the release. In our example, this is our git repository and our infrastructure provisioning.

Your build will now start provisioning in your environment.