You probably utilize Azure DevOps as a developer to simplify your development process. Nonetheless, it is imperative to ensure your team adheres to the same standards just like any other project. To accomplish this, branch policies in Azure DevOps can be a beneficial tool. These policies assist in enforcing workflows and avoid errors from appearing.
Understanding branch policies
Azure DevOps allows development teams to implement branch policies to maintain code integrity and quality. These policies help enforce restrictions and prerequisites for code changes in specific branches. By using branch policies effectively, teams can ensure a stable and reliable codebase.
This involves testing and validating changes before merging them into the main branch, as well as conducting code reviews to improve quality and minimize bugs. Branch policies are essential for maintaining a high-quality codebase in Azure DevOps.
Policies discussed in this post
- Branch Policies
- Build validation
Let’s start
Using branch policies, you can go to the Azure DevOps portal and log in using your account details. Once you have signed in, you have the option to either create a new project or select an existing project.
- I already have an Azure DevOps organisation. But be sure to create one if you don’t have one. Create a new organisation here free of cost.
- Submit a request to Microsoft to get 1800 minutes of free runtime per month on Microsoft hosted agents.
Find branch policies by navigating to the project’s repository and select the “Branches” option from the left-hand menu.
From there, you can select a branch and click on the “Branch Policies” option.
Branch policies
With the expansion of your projects, it is likely that your team will grow as well. It is important to realize that managing the changes in your code can become a daunting task. To maintain the quality of your code, policies can assist in enforcing standards.
This section focuses on policies that safeguard one or more branches in your repository. Configuring branch policies, you need to be either a member of the:
- Project Administrators security group.
- Or have repository-level Edit Policies permissions.
Require a minimum number of reviewers
Code reviews play a crucial role in software development projects. One way to ensure team members review and approve pull requests effectively is to mandate approval from a minimum number of reviewers. To meet the basic criteria, a specified number of reviewers must approve the code with no dismissals. Start at least with one reviewer per pull request until teams get larger.
Check for linked work items
Changes in code often begin with a request from a stakeholder or team member. Therefore I am considering it a best practice to require the association between the pull request and work item. Connecting work items adds more context to the changes and guarantees that updates follow the work item tracking process.
Check for comment resolution
Finalising a pull request, approvers put forth comments that must be addressed. This obligates the author of the pull request to reconsider their modifications and make necessary amendments, if required. This condition must also remain activated while using Build Validation, and its details will be discussed in the succeeding section.
Limit merge types
This feature helps to maintain a controlled and consistent codebase by restricting the types of merges that can be performed on a specific branch. This policy ensures that only certain types of merges, such as squash, rebase, or merge commit, are allowed, while other merge types are disallowed.
Enforcing this policy adds an extra layer of governance to your codebase, preventing accidental or undesirable merge actions. For example, you can choose to only allow squash merges to maintain a cleaner commit history or require rebase merges to ensure a linear development history.
Build validation
Validation is crucial for ensuring code quality and functionally testing changes. You can set a policy requiring a pipeline to run successfully before the pull request can complete. It is used to test changes in an early stage, especially if you’re using continuous integration in your pipelines. The pipeline triggers automatically when a new pull request is made and is identically configured like other pipelines.
I will use a fictional situation to validate PowerShell code using PSScriptAnalyzer. The file and folder structure used in this example can be modified to suit your own needs.
- pipelines/pipeline-validation.yaml: Configuration of the Azure Pipeline. Runs the PowerShell script which installs/executes PSScriptAnalyzer and PowerShell support functions and post comments back to the Pull Request.
- supportFiles/validation-psscriptanalyzer.ps1: Deployment script which runs PSScriptAnalyzer.
- supportFiles/validation-module.psm1: Contains custom PowerShell functions to invoke PSScriptAnalyzer and post comments to Pull Requests.
- deploymentFiles/deployment.ps1: Example of a script. Obviously in a real world scenario this would be files that actually should do something within your pipeline.
Note: Find all files in this GitHub repository.
Creating a build validation pipeline
Please copy the folder structure from the Github link provided above. Also, feel free to make any necessary changes to the folder structure for our code. However, keep in mind that the information in the next sections may be slightly different.
Permissions
Unlike users, who mostly contribute pull requests, the build agent that runs the pipeline should also be able to contribute. Therefore, we need to set some permissions for the build service.
- Head over to your Azure DevOps project and go to Project Settings.
- In the menu, go to Repositories and click on Security.
- Click on Microsoft Azure Build Service from the list of users. Secondly, allow this user to Contribute to pull requests.
Note: Permissions can be set at project- or repository scope. I recommend to set permissions per repository.
Deploy new pipeline
Simply committing our pipeline-validation.yaml file to Azure Repos won’t create a new pipeline. Let’s create one now!
- In the Azure DevOps project, click on Azure Pipelines. Now, click New pipeline.
- Select Azure Repos Git and secondly the repository where this pipeline should connect with.
- Choose Existing Azure Pipelines YAML file since we already defined our pipeline configuration.
- Pick the YAML file containing our pipeline configuration.
- Lastly, don’t run the pipeline just yet. Instead, click the arrow next to it and choose Save.
Set build validation policy
- Navigate to Repos in the left menu.
- Click on Branches and select the main branch.
- Click on the 3 vertical dots and choose Branch Policies.
- Go to Build Validation section and click on the + button.
- Select the pipeline. Leave all other options unchanged.
Testing
It is now the right time to combine all the steps and evaluate this policy. We assess a pull request where I attempted to change some code and convert a plain text string to a secure string.
However, this method should not be used according to best practices. Thus, the pipeline added a fresh comment for us to address this issue. Since Comment Resolution has been enabled in our branch policy, the code creator is compelled to solve all posted comments.
If PSScriptAnalyzer detects no problems with the code to be merged, there will be no comments published. In such a case, since there are no comments to be addressed, the pull request can be merged without issue.
Conclusion
In conclusion, branch policies in Azure DevOps are a powerful tool for maintaining the integrity and quality of your codebase. By enforcing limitations and prerequisites on code changes, development teams can ensure that their code remains stable, dependable, and adheres to established workflows.
Branch policies offer several features such as requiring a minimum number of reviewers, checking for linked work items, resolving comments, and limiting merge types. These policies help teams maintain code quality, improve collaboration, and reduce the number of bugs introduced into the codebase.
Additionally, by implementing build validation, teams can ensure that changes are thoroughly tested before they are merged, further enhancing code quality and functionality. Overall, understanding and effectively using branch policies is essential for maintaining a high-quality codebase in Azure DevOps and ensuring the success of your software development projects.