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
- 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: | email@example.com instructions: 'Please validate the build configuration and resume' onTimeout: 'resume' #reject
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
Enable Branch policy
- 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
When configured correctly you will receive this message, which is the expected outcome.
- 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!
- 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