While this chapter isn't about Azure DevOps, it's a good idea to begin with a fundamental understanding of what it brings to the table. Azure DevOps is both a developer tool and a business tool, as it can be the source of truth for your code base and a backlog of items that code needs to accomplish. Let's look at some of the options that it brings to the table, from which you can pick and choose:

• Azure Repos allows you to either create a Git repository or Team Foundation Version Control to store your development source control.
• Azure Pipelines, one of the critical processes we will use in this chapter for the artifacts we create, provides build and release services for continuous integration and delivery (CI/CD) of your apps.
• Azure Boards helps deliver a product backlog to plan and track work, code defects, and other issues that may arise during your software development.
• Azure Test Plans allows you to test the code within your repository and enables you to perform manual and exploratory testing, along with continuous testing.
• Azure Artifacts provides the elements needed for your code to be packaged and deployed, such as NuGet resources usually shared with your CI/CD pipelines.

As you can see, Azure DevOps is Microsoft's tool for deploying and managing applications within Azure as part of the release management process. To learn more about Azure DevOps, you can head over to the documentation at https://docs.microsoft.com/azure/devops/user-guide/what-is-azure-devops?view=azure-devops.

Note

Azure DevOps is available for free with a five-user license, so feel free to have a look and explore how deployment in Azure works. Head to https://azure.microsoft.com/services/devops/ to create your free account.

Now that we've discussed some of the toolings at a very high level, let's take a look at ARM templates.

ARM templates

ARM templates are how your infrastructure is represented as code. ARM templates help teams take a more agile approach to deploying infrastructure in the cloud; it is no longer necessary to click deploy within the Azure portal to create your infrastructure. An ARM template is a mixture of a JSON file representing the configuration of your infrastructure and a PowerShell script to execute that template and create the infrastructure.

The real benefit of using the ARM template system is that it allows you to have declarative syntax. That means you can deploy a virtual machine and create the networking infrastructure that goes around it. Templates end up providing a process that can be run repeatedly in a very consistent manner. They manage the desired state of the infrastructure, meaning a template becomes the source of truth for those infrastructure resources. If you make changes to your infrastructure, you should do that through the templates.

The template deployment process can't be accomplished without orchestrating how the template process needs to run and what order it needs to run in. It is also useful to break these files into smaller chunks and allow them to be linked together or reused in different fashions with other templates. This can help with understanding and controlling your infrastructure while making it repeatable and stable. ARM templates are used in CI/CD pipelines and code deployment to build a suite of applications within the organization.

The following JSON file shows you how ARM templates are structured:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "variables": {},
  "resources": [],
  "outputs": {}
}

As you can see, there are several important parts: parameters, variables, resources, and outputs. Let's discuss each of them briefly:

• ARM template files should be parameterized, and there is a separate file for the parameters that maps to the parameters list in the JSON template file.
• The variables portion is for variables used within this file. Variables are generally used for creating naming functions to help generate a naming convention that is already structured, and for building that structure to use input parameters to make the name.
• The resources section is where all of the resources that you're trying to deploy with this ARM template are represented; these can range from virtual machines to websites.
• Finally, the outputs section is anything you want to pass out of your ARM template to be used elsewhere, such as an SQL Server name, before running your SQL scripts.

Three files are created when you create an ARM template file within Visual Studio:

• The first is the JSON file, which is the template that is represented in the preceding code.
• The second is the JSON parameter input file, a file that can be changed with every deployment to match the environment you want to deploy.
• The third is the PowerShell script used to execute the template. The PowerShell script accepts the resource group's inputs, the ARM template file, and the parameters file.

That was a quick overview of Azure DevOps and the files that are created when you create an ARM template. Let's see how Azure resources are deployed using these ARM templates.

As we saw in the ARM templates section, we want to use ARM templates to deploy our infrastructure, as it fits in nicely with our CI/CD process. There are several ways to approach building out these templates.

One way is to create a monolithic template that contains all of the resources that you want to deploy. To make things a little more modular, you could use a nested template structure. Alternatively, you may want to take a more decoupled approach and create smaller templates that you can link together, making a highly usable and repeatable structure.

Let's take a look at each of these methods, starting with the monolithic view:

Figure 2.1: Monolithic ARM template

As you can see in Figure 2.1, a monolithic ARM template deploys a UI front end with an API middle tier connected to the SQL database. In this process, we need to build out all of the dependencies within the JSON template. The SQL database is deployed before the API middle tier to use the connection string in the API application configuration. You would then deploy the UI layer with the API URL being used in the UI application configuration. The chaining of the deployment can work not only for deploying code but also helping with the configuration.

Alternatively, you could implement a nested template arrangement:

Figure 2.2: Nested ARM templates

As you can see, this is similar to the structure in Figure 2.1. However, the templates within this structure are nested in separate file sections. This means that each template owns the resource within it that it's trying to deploy. This structure is similar to breaking out your C# code into manageable methods and actions. This follows the same deployment process as discussed in the monolithic scenario, but the files are nested.

The final structure is linked ARM templates:

Figure 2.3: Linked ARM templates

As you can see, the templates are initially separate and decoupled from each other, and then we link them together in our release pipeline. Linked templates are similar to nested templates, except the files are external to the template and system, whereas the nested templates are included in the same scope as the parent template. This helps with reusability down the line, because the templates are separate files that can be linked to other deployment files.

We should note that with linked or nested templates, the deployment mode can only be set to Incremental. However, the main template can be deployed in Complete mode, so if the linked or nested templates target the same resource group, that combined deployment will be evaluated for a complete deployment; otherwise, it will deploy incrementally. To learn more about ARM deployment modes, visit https://docs.microsoft.com/azure/azure-resource-manager/templates/deployment-modes.

We've seen different ways of using these ARM templates to automate the deployment of infrastructure; now we turn to the benefits of doing so.

The main benefit of using IaC is automating the creation, updating, and configuration of different resources and environments. Automation takes the human element out of the picture while adding certain key benefits:

• The ability to schedule automated deployments, helping your operations staff work fewer hours.
• The ability to smoke test your automated deployments.
• The ability to create a repeatable process.
• Pure self-healing applications can be achieved.
• The ability to roll back changes.
• Resource Manager helps in tagging resources.
• ARM takes care of the dependencies of resources in the resource group.

Automation at any point is the real key to using a platform like Azure, whether that is automating your infrastructure deployments or testing to ensure the stability of your production deployments.

In order to reap these benefits, we need to learn how to use ARM templates effectively.