In my previous note, [Azure DevOps and Terraform to provision AWS S3], I listed in detail the steps to be followed to provision an S3 bucket using Azure DevOps and Terraform. I referred to the classic editor in the build definition/azure pipelines. Build and release definitions declared via a classic editor in Azure DevOps, although they have a log/history of change, tend to evolve independently of the evolution of the code repo they support.
This gap was identified, and Azure DevOps has a solution of storing the build/pipeline definition as a YAML file alongside the code that it is referring to. The benefit of storing the build definition (YAML) along with the code is that the changes to the build definition are versioned in the same repo, so traceability is simpler -whoever is using the repo now has access to the build definition as well, thereby saving time and effort.
Picking up from the approach in my previous note, I migrated the code repo into a new repo and added a YAML pipeline. The pre-requisites remain the same -we still need IAM user credentials to provision a resource, an existing S3 bucket to store remote state, and a Github repo containing Terraform configuration files, and an Azure DevOps project.
We follow the first three steps that I listed in the classic editor approach here. So, install the Terraform extension, create two service connections, one to Github and AWS for Terraform.
With these out of the way, laying the pipeline is relatively straight-forward. On our Azure DevOps team project, navigate to Pipelines -> Pipelines -> New pipeline [button at top right corner]. Here select the Github repository that contains Terraform configuration files (you might have to authenticate if not done so already) and configure the pipeline -existing Azure Pipelines YAML file, if you already have the YAML in the repo or -starter pipeline, if you want to add a new pipeline YAML file to your repo. If this is the first time that the Github repository is being added, you might be prompted to add an Azure Pipelines extension. You may select whether you want this extension installed on just the selected repository or all repositories. For simplicity, I suggest selecting only the repository where the Terraform configuration files are stored.
Depending upon what you selected –starter pipeline or existing Azure pipelines YAML file, you are prompted to configure the same. I had the YAML file in my repository with the same steps copied from the classic editor. If you recollect, in the classic editor, I added variables to the build definition, and I did not do so here. Since we are using an already configured Terraform extension, it was not necessary. I checked that even the build definition in classic editor worked fine with these variables removed, since there, too, we were using the same Terraform extension.
Once saved, I gave the pipeline a try, and as expected, it ran just fine.
Here is a link to the Github repo that contains the Terraform configuration files along with azure-pipelines.yaml file. Fork it and give it a try. Let me know if you have any suggestions and questions.