Continuous Deployment

In the previous chapter, you learned how to use Azure DevOps pipelines for continuous integration. Due to this, you now know how to pick up a version of your sources and create artifacts that can be deployed. In this chapter, you will learn how to extend this practice with continuous delivery and continuous deployment so that you automatically deploy these artifacts to the servers or platforms your code is running on.

To do this, we will start by introducing Azure DevOps release definitions so that you can define and run the releases of your application. Next, a series of strategies will be introduced that you can use to perform deployments in a low-risk manner. Doing this makes it possible for you to automate the process of deploying new versions unattended, with a limited risk of incidents occurring. From here, we will shift our attention to automating...

Technical requirements

To experiment with the techniques described in this chapter, you might need one or more of the following:

• An Azure DevOps account for building release definitions and multi-stage YAML pipelines
• An App Center account for deploying mobile applications

Free trial options are available for both of these.

Continuous delivery and continuous deployment

The difference between continuous delivery and continuous deployment is a common source of confusion. Some people think these terms are interchangeable and see them as two synonyms for the same concept, but they have, in fact, two different meanings.

Continuous delivery is a practice where teams ensure that the artifacts they build are continuously validated and ready to be deployed to the production environment. Often, this is done by deploying the artifacts to a production-like environment, such as acceptance or even a staging environment, and applying a series of tests, such as verification tests, to ensure the application is working correctly.

Continuous deployment is a practice where every version that is deployed to a production-like environment and passes all tests and verifications, is also deployed to production automatically...

Working with Azure DevOps releases

Continuous delivery and deployment can both be implemented in Azure DevOps by using releases. When creating a new release definition, an outline of the release process is created. This process will often start with an artifact that triggers the creation of a new release. Next, it is possible to define one or more stages that the release can be deployed to. Often, these stages correspond to the different application environments, for example, test and production, but this is not mandatory.

Let's learn how to create a new release definition and explore the various options we have. First, navigate to Pipelines and choose Releases from the menu. From here, it is possible to start creating a new release pipeline, which will take us to a screen that looks similar to the one shown in the following screenshot:

From the preceding screen, we can...

Writing multi-stage YAML pipelines

In addition to the visual designer for release definitions, it is also possible to implement continuous deployment using YAML pipelines. When doing so, it is still recommended to differentiate between the build (CI) and release (CD) phases of a pipeline. The concept of stages is used to make this possible. A YAML pipeline can be divided into one or more stages. A stage can represent an environment such as test, acceptance, or production, but this isn't always true. If, in an application scenario, it makes sense to add extra stages such as pre-production or staging, this is possible. It is good practice to publish pipeline artifacts to earlier stages and to consume or download artifacts in later stages.

Multi-stage YAML pipelines are the new default for creating pipelines in Azure DevOps. Since working with YAML pipelines can have a steeper...

Implementing continuous deployment strategies

Before we deploy an application continuously, it is important to think about the strategy we should use. Just doing deployment after deployment may have more risks associated with it than the business is willing to accept. It is important to think about how to deal with issues that might occur during or after deploying a new version of your application.

There are a few deployment strategies that can be applied to reduce the risks that might come with deployments, all of which will be covered in this section. Please note that it is possible to combine one or more of the following patterns. For example, it is perfectly possible to use a blue-green strategy for every ring in a ring-based deployment. Also, all deployment strategies can be combined with the use of feature flags.

...

Deploying mobile applications

One type of application that needs a special approach to deployment is mobile applications. These applications are often not downloaded and installed by end users directly and are mostly consumed via an app store on their mobile device.

App Center is a Microsoft offering that can be used for distributing (deploying) mobile applications to end users via app stores, but also via private distribution lists.

After logging into App Center, you will be taken to the following screen:

Here, you can create a new app definition. An app definition should be created for every target operating system of an application. If the same application is going to be deployed to both Android and iOS, at least two apps have to be created.

Creating an app is done by performing the following steps:

1. Log in to App Center.
2. Click the blue Add new app button. If there are no...

Automating release notes

After automating the build, releasing an application, and working on increasing the flow of value to end users, many developers find that it becomes harder and harder to keep documentation and release notes up to date. As the amount of releases increases, this becomes more and more work, and eventually, the team will fall behind or even give up completely.

To combat this, it is possible to automate the creation and publication of release notes. One way to do this is by using the Azure DevOps Release Notes Generator. The generator is an Azure Functions application that is available on GitHub. To use the Release Notes Generator, the following needs to be done:

1. Download or clone the function code from GitHub.
2. Create an Azure App Service Plan, function app, and storage account in Azure.
3. Create a new blob container in the storage account called releases.
4. Compile...

Other tools

In addition to Azure DevOps and App Center, there are other tools that can be used for deploying and releasing software. GitLab CI/CD and Jenkins, which were discussed in the previous chapter for executing builds, can also be used for releases. Besides those, Octopus Deploy is also a commonly used tool that integrates well with Azure DevOps.

Octopus Deploy

Octopus Deploy is a deployment automation tool that is based on the concept of running a series of tasks on one or more target machines.

Octopus reaches these machines through a tentacle (an agent) that is installed on these machines. In Octopus Deploy, it is possible to define applications and environments and assign one or more machines to each of those. To...

Summary

In this chapter, you learned about continuous delivery and deployment and how you can implement them using Azure DevOps. In addition to the visual release editor, you also learned about multi-stage YAML pipelines, which you can use for releasing your software to multiple stages, all of the way to production. Next, we discussed a series of strategies that you can use for releasing. You now know about blue-green deployments, using immutable servers, and different strategies for progressive exposure. You also learned how to choose between making sure you have rollback capabilities or accepting a fail forward strategy.

Then, you learned about automating release notes and documentation and how you can generate those automatically as part of your pipeline. After that, you learned about continuous deployment for mobile applications and how that differs from the delivery of web...

Questions

As we conclude this chapter, here is a list of questions for you to test your knowledge of this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. True or false: An Azure DevOps Classic Release is always triggered by the availability of a new version of an artifact.
2. Which of the following platforms can App Center publish apps to? (You can choose more than one.)
   
   1. Google Play Store
   2. Apple App Store
   3. Microsoft Intune
3. Which of the following techniques use progressive exposure for minimizing the risks of deploying a new version? (You can choose more than one.)
   1. Feature Toggles
   2. Ring-based deployments
   3. Canary deployments
4. True or false: Deployment groups can be used for deploying software to on-premises servers when an Azure Pipelines agent is installed on the machine that will be running the software.
5. What is the advantage of integrating...

Further reading

• More information on using stages in YAML pipelines can be found at https://docs.microsoft.com/en-us/azure/devops/pipelines/process/stages.
• More information on the idea of immutable servers can be found at https://martinfowler.com/bliki/ImmutableServer.html.
• More information about LaunchDarkly can be found at https://launchdarkly.com/.

• More details about the build and release extension for integration with Octopus Deploy can be found at https://marketplace.visualstudio.com/items?itemName=octopusdeploy.octopus-deploy-build-release-tasks.
• The Azure DevOps Release Notes Generator can be found at https://docs.microsoft.com/en-us/samples/azure-samples/azure-devops-release-notes/azure-devops-release-notes-generator/.
• Some Microsoft hands-on labs for practicing the topics we covered in this chapter can be found at https://docs.microsoft.com/en-us/learn/modules/create...