Working with pull requests is a common pattern for teams in the software development area. Here is how to enforce the workflow in Azure DevOps.
The most common workflow in software projects is the pull request workflow. First, a developer develops new functionality or bug fixes on a separate branch. When the work is done, a pull request is created to integrate the changes into another branch (usually the main or master branch, but it depends on the exact workflow). The other team members review the changes and approve or decline the request.
When done right, it’s a proven strategy to minimize errors, get valuable feedback on changes, and keep a consistent code base.
By default, Azure DevOps allows pushing directly to the master branch without the need for a pull request. I’ll show you how to change the setting in this short demo.
Go to Repos → Branches and click on the three dots on the right side of the branch you want to enforce pull requests on. Next, click on Branch policies and choose a least one of the policies offered. This will prevent pushes to the selected branch and require a pull request. The branch will be marked with a blue medal symbol as a hint.
Want More Flutter Content?
Join my bi-weekly newsletter that delivers small Flutter portions right in your inbox. A title, an abstract, a link, and you decide if you want to dive in!
Here is a quick demo video:
The following options are available
▶ Require a minimum number of reviewers
Require approval from a specified number of reviewers on pull requests.
▶ Check for linked work items
Encourage traceability by checking for linked work items on pull requests.
▶ Check for comment resolution
Check to see that all comments have been resolved on pull requests.
▶ Limit merge types
Control branch history by limiting the available types of merge when pull requests are completed.
▶ Build Validation
Validate code by pre-merging and building pull request changes. You need to reference a working pipeline to use this option.
▶ Status Checks
Require other services to post successful status to complete pull requests. A common check is the code quality metrics of SonarCube for example.
▶ Automatically included reviewers
Designate code reviewers to automatically include when pull requests change certain areas of code. Useful if you have lead developers or architects that need to approve changes.
Related articles
