This is part 3 of a series of Blog posts about Terraform and Azure Devops Services.
After preparing the required Azure DevOps Services and Visual Studio Code in part 1 and the deployment of the Multi-Stage YAML pipeline in part 2. We are now ready for further configuration with branches, reviews and approvals within the pipeline.
CloudFive-IaC/cloud-examples: IaC examples for Cloud deployments (github.com)
The content required for this demo is located in the folder: AzureDevOps-Terraform
Table of Contents
Add Manual Validation task in pipeline
Only YAML pipelines support this task and can only be used in an agentless job.
Add code
- Add the following code in your pipeline above the apply stage
- An example can be found here
- job: waitForValidation
dependsOn: Plan
displayName: Wait for external validation
pool: server
timeoutInMinutes: 4320 # job times out in 3 days
steps:
- task: ManualValidation@0
timeoutInMinutes: 1440 # task times out in 1 day
inputs:
notifyUsers: |
your@email.com
instructions: 'Please validate the build configuration and resume'
onTimeout: 'resume' #reject
The result
Now that we have added the Manual Validation task this should be the result when running the pipeline. During the run there will be a manual review step before you can continue.

- Check if the previous stages have done what you expected
- Click on ‘Review’ which will take you to the Manual Validation task
- Add your comment and hit ‘Resume’

After the run is completed you can click on ‘1 manual validation passed’ and view who completed the task and what was commented


All done 👍
More about the usage of Manual Validation tasks and Agentless jobs.
Enable Branch policy
- Go to the Azure DevOps Portal > https://dev.azure.com/ (First 5 users free)
- Go to your Project
- From within your project navigate to ‘Repos’ > ‘Branches’
- Select the main (or any other given name) branch where the code is deployed
- Select the three dots and click on ‘Branch policies’

- Require a minimum number of reviewers (for this demo set it to 1)
- Allow requestors to approve their own changes (so you can approve changes within this demo)
- Select Reset all code reviewer votes to remove all reviewer votes whenever the source branch changes, including votes to approve, reject, or wait

Automatically included reviewers
You can automatically add reviewers to pull requests that change files in specific directories and files, or to all pull requests in a repo.

All done and ready to test
Test commit in main branch
- Go to the Azure DevOps Portal > https://dev.azure.com/ (First 5 users free)
- Go to your Project
- From within your project navigate to ‘Repos’ > ‘Files’
- You can select the correct branch (highlighted in blue square below)
- Select a *.tf file and click ‘Edit’
- Add some text for testing and ‘Commit’

When configured correctly you will receive this message, which is the expected outcome.

Create dev branch for testing with pull requests
- Go to the Azure DevOps Portal > https://dev.azure.com/ (First 5 users free)
- Go to your Project
- From within your project navigate to ‘Repos’ > ‘Branches’
- Click on ‘+ New branch’

- Give in the ‘Name’ and select where it should be based on.
- When using work items you als link the branch creation to a work item.
- Click on ‘Create’ to create the branch.

The branch is created and now ready for further testing!
Create pull request
- Go to the Azure DevOps Portal > https://dev.azure.com/ (First 5 users free)
- Go to your Project
- From within your project navigate to ‘Repos’ > ‘Files’
- Select the ‘dev’ branch (as you can see, it is also possible to create a new branch from here)

- Select a *.tf file and change a line of code (in this example I changed main to dev in main.tf)

- Commit the changes and create a pull request

- Review the the ‘Title’, ‘Description’, ‘Reviewers’ (if needed) and create the pull request

The reviewers will be informed about the needed approval and a check is done for merge conflicts.
When you select ‘Files’ you are able to view what has changed:

The pull request can be completed after approval. For this demo I selected to ‘Delete dev after merging’. So the created dev branch will be removed.


After completing the pull request there is an overview of what is done within the pull request. Which you can always review later on (for troubleshooting).
The pipeline is triggered after main.tf has been updated.
This is because of the following lines of code in the YAML pipeline (which specifies the trigger and includes the main branche):
trigger:
branches:
include:
- main