Azure DevOps Terraform Task

Introduction

As development teams implement more and more Infrastructure as Code (IaC) leveraging Azure DevOps(ADO) there is a need for to ADO tasks that integrate easily and help improve the software development process. This post will specifically focus on the Azure DevOps Terraform Task

Update: To see this task in action check out my TheYAMLPipelineOne GitHub Repo

The Problem

With growth in popularity on Azure DevOps Microsoft Hosted Agents we need the ability to consistently deploy software on machines that organizations don’t maintain and managed. Because of this there needs to be task(s) to install/validate that the require software for build/deployment is configured correctly on the hosted agent.

An additional ask would be feature/functionality that easily integrates into ADO and provides for a better overall developer experience.

The Azure DevOps Implementation

The Azure DevOps Terraform Task does both of these. First installing Terraform can be configured to a specific version passed in at build:

parameters:
- name: terraformVersion
  type: string
  
steps:
  - task: ms-devlabs.custom-terraform-tasks.custom-terraform-installer-task.TerraformInstaller@0
    displayName: install terraform
    inputs:
        terraformVersion: ${{ parameters.terraformVersion }}

This ensure that the correct version of Terraform is installed on the Microsoft hosted agent. After this we can use the additional commands via TerraformCLI@0.

For instance, to initialize Terraform against an azurerm backend.

parameters:
- name: serviceName
  type: string
- name: TerraformDirectory
  type: string
- name: AzureSubscriptionServiceConnectionName
  type: string
- name: TerraformStateStorageAccountResourceGroupName
  type: string
- name: TerraformStateStorageAccountName
  type: string
- name: TerraformStateStorageAccountContainerName
  type: string
  
steps:
  - task: TerraformCLI@0
    displayName: 'Terraform : init'
    inputs:
      command: init
      backendType: azurerm
      workingDirectory: ${{ parameters.TerraformDirectory }}
      backendServiceArm: ${{ parameters.AzureSubscriptionServiceConnectionName }}
      backendAzureRmResourceGroupName: ${{ parameters.TerraformStateStorageAccountResourceGroupName }}
      backendAzureRmStorageAccountName: ${{ parameters.TerraformStateStorageAccountName }}
      backendAzureRmContainerName: ${{ parameters.TerraformStateStorageAccountContainerName }}
      backendAzureRmKey: ${{ parameters.serviceName }}.tfstate

Then a plan:

parameters:
- name: TerraformDirectory
  type: string
- name: AzureSubscriptionServiceConnectionName
  type: string
- name: commandOptions
  default: '-out=$(System.DefaultWorkingDirectory)/terraform.tfplan -detailed-exitcode'
- name: additionalParameters
  type: object
  default: []

steps:
    - task: TerraformCLI@0
      displayName: 'Terraform : plan'
      inputs:
        command: plan
        workingDirectory: ${{ parameters.TerraformDirectory }}
        publishPlanResults: ${{ parameters.AzureSubscriptionServiceConnectionName }}
        environmentServiceName: ${{ parameters.AzureSubscriptionServiceConnectionName }}
        commandOptions: ${{ parameters.commandOptions }}

Take note on this one of the publishPlanResults and the commandOptions. We will show what these translate to later.

Finally, the apply:

parameters:
- name: TerraformDirectory
  type: string
- name: AzureSubscriptionServiceConnectionName
  type: string
- name: additionalParameters
  type: object
  default: []
  
steps:
- task: TerraformCLI@0
  displayName: 'Terraform : apply'
  condition: and(succeeded(), eq(variables['TERRAFORM_PLAN_HAS_CHANGES'],'true'))
  inputs:
    command: apply
    workingDirectory: ${{ parameters.TerraformDirectory }}
    commandOptions: '$(System.DefaultWorkingDirectory)/terraform.tfplan'
    environmentServiceName: ${{ parameters.AzureSubscriptionServiceConnectionName }}

Notice a condition on this apply checking against TERRAFORM_PLAN_HAS_CHANGES this is a variable created by the plan command and writes back if the Terraform will actually make any infrastructure changes. In the scenario where IaC is stored and deployed with application code (which I strongly recommend) this will skip the Terraform apply step if there aren’t any changes to apply.

Here is a screenshot confirming the apply was skipped in the case of no changes being detected:

The Azure DevOps Experience

In addition to providing the ability to skip over the apply step if no changes have occurred another key thing this task provides is the publishing of the plan directly to ADO.

Notice we have a new tab on the ADO pipeline called ‘Terraform Plan’

This tab lets me choose which plan to evaluate, in my case the plan was done per environment. Here is Dev where no changes were detected:

And here is an example of a UAT environment where changes were detected:

This information was previously available in the output of the tasks; however, by moving this to a new tab can quickly navigate and see any changes. Plus, with the push to have business users release code this is less daunting for someone without a technical background to look at.

Conclusion

Using the Azure Terraform CLI task can greatly improve the experience when working with Terraform within ADO.