Azure Resource Manager templates (ARM templates) enable you to adapt and implement an Infrastructure as Code (IaC) practice for your Azure solutions. 

The declarative syntax and idempotent nature of ARM templates make them an effective and reliable tool for managing and provisioning immutable infrastructure. Regardless of whether the resource needs to be created, or an existing resource needs to be updated, the ARM template is the same.  

The declarative programming model enables you to define the desired state without worrying about the current state or actions/steps needed to transition from the current to desired state. 

Compared to an imperative programming model, where you must define a precise sequence of instructions for the computer to execute to get to the desired state, with the declarative programming model you only need to define a desired state and let the computer (in this case Azure Resource Manager) figure out the rest. The desired state, in this case, is described by the ARM template and it is a responsibility of Azure Resource Manager to interpret the template and orchestrate deployment operations, taking care of all complexities in the process. 

It is good practice to validate the template and verify that changes projected to be made by the template match our expectations without actually applying those changes. This practice is an additional safety net and a precaution measure aimed at ensuring the integrity of our infrastructure. Azure Resource Manager provides the what-if operation that enables you to do exactly that: see how resources will change if you deploy the template. For those familiar with Terraform, the what-if operation is an equivalent to the terraform plan command, but with one significant difference: the what-if operation does not require state files. Instead, it compares your template (the desired state) against the actual target environment (the current state). 

However, there is no easy way to integrate the what-if operation in Azure DevOps pipelines. While some might argue that running the what-if operation using the Azure CLI task is the “easy way,” not having a dedicated task is certainly a barrier to entry. In addition, even if you end up using Azure CLI to run the what-if command, the best you can get is CLI output and you must open logs to see the results, which – hands down – is not very presentable and looks more like a hack than an actual solution. 

ARM Deployment Insights Makes the What-If Operation More Accessible 

There’s no doubt that using build logs to check results of the what-if operation can (and does) work. However, it felt like there was untapped potential there. Our idea was to make the what-if operation more accessible and more convenient to use within Azure DevOps, so we built an Azure DevOps extension to serve that purpose. The extension, named ARM Deployment Insights, is now available in the Visual Studio Marketplace, where you can download it for free.  

The extension consists of a custom task and a build results tab. The task acts as a facade for Azure CLI, translating input parameters to the Azure CLI command. It runs the what-if operation and then stores the what-if results as build attachments. The results can then be viewed under the ARM Deployment Insights build results tab. 

The build results tab shows the what-if operation results organized into multiple tabs, where each tab represents a single deployment (or what-if operation). This means that you can preview the effects of multiple deployments in a single pipeline. For example, in a multi-stage pipeline, where different stages represent a deployment to a different environment, you can run the what-if operation against all environments and see how each environment will be affected before deploying the template to any of the environments. 

The Change Type field indicates if and how resources will be affected by deploying the template. Changes are automatically filtered to show only the Create, Delete, Deploy and Modify change types, but you can modify the filter to include other change types as well. If you are looking for a specific resource, you can also filter changes by resource name or type. 

In addition to top-level changes, the Details view lets you see how the properties of each resource (top-level change) will get affected, if at all. The Details view can show either current or desired state, or both, depending on the change type. For example, changes with the Create change type have only desired state because the resource does not yet exist. Likewise, changes with the Delete change type have only current state because the resource does not exist in the desired state.
  

However, for changes with the Modify change type, the Details view shows both the current and desired state, side by side. This makes it easy to compare them and identify the delta. 

If you prefer to look at the code though, you can switch to a Diff View (Side-by-Side or Inline) and see actual JSON differences between the current and desired state model.

You can find a detailed overview of the extension in the Visual Studio Marketplace. 

Potential Use Cases 

You’re probably wondering how you can make use of this extension, and it wouldn’t be fair to end this article without discussing potential use cases and reasons why you’d even consider including this in your CI/CD pipeline, so let’s name a few. 

• Validate ARM templates – The Validate operation is a common way to check/validate templates in Azure DevOps pipelines. This is because there is a dedicated task that enables you to validate the template you are deploying simply by changing one single parameter (compared to the deployment task). However, the what-if operation does a better job at validating the template than a dedicated validate operation, which only validates whether the specified template is syntactically correct and will be accepted by Azure Resource Manager, but it does not guarantee a successful deployment. The what-if operation, on the other hand, validates the template against the target environment and can also detect errors specific to that environment. For example, the what-if operation can detect and report if the target environment has exceeded a limit of 800 instances of a resource type in a resource group. It also validates the syntax and makes it easier for you to manually verify the changes. 
• Assess deployments – Someone usually needs to approve the deployment in upper environments. Approvers can utilize the ARM Deployment Insights extension to check if the changes projected to be made by the template match their expectations and based on the assessment, decide whether to approve deployment or not.
• Track changes – Results are stored as build attachments, effectively acting as “what-if snapshots” for a specific pipeline run and deployment. You can always come back to a specific pipeline run and see how it affected your infrastructure. 

• Review ARM templates – Reviewing ARM templates can be inconvenient, especially if you are using expressions. Compared to an expression like this [concat(toLower(parameters(‘storageName‌Prefix’)), uniqueString(resourceGroup().id))], it is much easier to review and validate the actual name of the resource. When looking at the ARM template, you have to manually parse and evaluate expressions to understand what the actual value will be. The ARM Deployment Insights extension shows actual values and makes it easier for you to review and validate changes in your templates. 
• Identify changes made via Azure Portal and resources not managed by your template – Treating infrastructure the same way developers treat application code is a fundamental principle of IaC and DevOps. Following this principle, you should never modify resources directly in the Azure Portal, just like you should never change code directly in the running environment (e.g., you never change the JS code directly on the Web Server). Terraform, for example, does not tolerate this because state files will get out of sync from the actual state. ARM templates are more forgiving and will not break if you make a change directly in the Azure Portal (because there are no state files), but it’s still not something you should do. The what-if operation (and the ARM Deployment Insights extension) makes it easy to identify such changes and it also helps you identify resources not managed by your template. Ideally, you want all your resources to be defined in the ARM templates. 

Even though it is possible to do all this without using the ARM Deployment Insights extension, I think we can agree that the extension provides a much better experience overall – from running the what-if operation to presenting the results. As mentioned earlier, our goal was to make the what-if operation more accessible and convenient to use within Azure DevOps, and I think we have succeeded. 

Authority Partners is a US-based international IT consultancy and service provider. With offices around the world, we are able to offer expert solutions and a level of technological excellence that sets us apart from the competition. To our clients we are partners who deliver business outcomes. 

We are Authority Partners.   

To learn more about how we can help your business, please reach out to us here or via email at hello@authoritypartners.com.