Azure DevOps PR Checks for Better Code Quality

Author

Reads 876

A woman coding on a laptop in a modern office environment with multiple monitors.
Credit: pexels.com, A woman coding on a laptop in a modern office environment with multiple monitors.

Implementing PR checks in Azure DevOps is a game-changer for ensuring better code quality. By integrating automated checks into your pull request (PR) workflow, you can catch errors and inconsistencies before they reach production.

Automated checks can be configured to run on every PR, ensuring that each change is thoroughly reviewed. This includes checks for code style, syntax, and formatting, as well as more complex checks for security vulnerabilities and performance issues.

The benefits of PR checks are numerous, including reduced bugs, improved code maintainability, and increased developer productivity. By automating these checks, you can free up your team's time to focus on more strategic tasks.

By setting up PR checks in Azure DevOps, you can establish a culture of continuous improvement and ensure that your codebase remains high-quality and reliable.

Setting Up PR Checks

Setting up PR checks is a crucial step in ensuring the quality of your code. You can set a pull request to autocomplete, which means it will automatically complete and merge when all conditions are met. This feature is available in Azure Repos and TFS 2017 and higher, and you'll receive an email notification when the PR is completed or if there's an issue.

Credit: youtube.com, PULL REQUEST WORKFLOW in AZURE DEVOPS - Raising a PR, Reviewing and Setting up Branch Policies

To enable auto-complete, go to the Complete dropdown list and select Set auto-complete. You can also use the az repos pr create command to set auto-complete at PR creation, or the az repos pr update command to update an existing PR.

A PR that's set to autocomplete waits only on required policies by default, but you can choose to wait on optional policies as well. In TFS 2018 Update 2 and later, the PR Overview page displays the list of outstanding policy criteria the PR is waiting for.

To display the results of the code coverage check, you need to add a file named azurepipelines-coverage.yml to the root of your Git Repository. Inside this file, paste the YAML code and set the comments value to on. This will allow you to see the results of the coverage check in your pull request.

Here are the steps to add a file to your Git Repository:

  • Go to the root of your Git Repository.
  • Create a new file named azurepipelines-coverage.yml.
  • Paste the YAML code into the file.
  • Set the comments value to on.
  • Commit and push the changes to your Git Repository.

By setting up PR checks, you can ensure that your code meets certain standards and requirements. This includes defining status checks to improve code quality, which can be done by integrating external services with your PR workflow. With PR status checks, you can programmatically sign off on code changes and associate success or failure information with the PR.

Configuring Branch Policies

Credit: youtube.com, How to configure branch policies in Azure DevOps | Pull request creation and approval

To configure branch policies in Azure DevOps, start by navigating to the 'Branches' section under 'Repos'. Click on the kebab menu icon against the master/main branch and select 'Branch Policies' from the context menu. You can then add a 'Build Validation' policy to require a successful build of the PR pipeline before merging.

To add a build policy, click the + button in the Build Validation section and select the PR pipeline that ran earlier from the dropdown. Review other settings and click 'Save' to enable the build validation. This will ensure that future PRs will require a successful build validation to pass.

You can also set up a PR build validation yaml pipeline by creating a file in the deployment\devops-pipelines\pull-requests folder with the necessary content. This pipeline will restore, build, and test the code, and can be triggered by the Azure DevOps Build Validation policies.

To automate branch policies, you can use Azure Functions to create custom branch policies. This can include adding policies to designate code reviewers to automatically include when pull requests change certain areas of code.

Credit: youtube.com, Azure DevOps Branch policies and settings | Azure DevOps | Azure DevOps Branch Policies

The following policies can be defined to customize a branch:

  • Require a minimum number of reviewers
  • Require approval from a specified number of reviewers on pull requests
  • Encourage traceability by checking for linked work items on pull requests
  • Check to see that all comments have been resolved on pull requests
  • Limit merge types
  • Add Build Validation policies
  • Add Status Check policies
  • Add policies to designate code reviewers

Setup Pipeline

To set up a pipeline for branch policies, you'll first need to create a PR build validation yaml pipeline. This pipeline will be responsible for restoring, building, and testing your project code.

Create a file named WebApplication-pr.yml in the deployment\devops-pipelines\pull-requests folder with the following content:

  • Install .Net 5.0 in the agent
  • Restore dependencies
  • Build the solution
  • Run the tests and collect code coverage

This pipeline is the bare minimum for PR validation, but you can add more tasks as needed.

Note that this pipeline doesn't have a trigger defined, as we'll be using Azure DevOps Build Validation policies to trigger it. Also, make sure to change the pool in the build job if you're using a different agent than the Microsoft Hosted Agent.

Branch Policies

Branch policies are a powerful tool in Azure DevOps that allow you to enforce certain conditions before a pull request can be merged. You can add build validation policies to require a successful build of the proposed code, reject changes pushed directly to protected branches, and even automate code reviews.

Credit: youtube.com, Azure DevOps Branches and Branch policies

To add a build validation policy, you can navigate to the "Branches" section under "Repos" in Azure DevOps, click on the kebab menu icon against the master/main branch, and select "Branch Policies" from the context menu. From there, you can add a "Build Validation" policy and select the PR pipeline that ran earlier from the dropdown.

You can also use Azure DevOps Build Validation policies to trigger a pipeline, such as a PR build validation yaml pipeline. This pipeline can restore, build, and test the code, and can be triggered when a pull request is created or updated.

In addition to build validation policies, you can also use branch policies to require a minimum number of reviewers, require approval from a specified number of reviewers, and even automate code reviews. You can also use branch policies to limit merge types, control branch history, and add status check policies.

Here is a summary of the policies you can define to customize a branch:

By using branch policies, you can automate many of the steps involved in the pull request process, making it easier to manage your code and ensure that it meets certain standards before it's merged into the main branch.

Rebase During Completion

Credit: youtube.com, Learn Git Rebase in 6 minutes // explained with live animations!

You can't rebase during PR completion in certain situations. If a policy on the target branch prohibits using rebase strategies, you need Override branch policies permission to rebase.

If the PR source branch has policies, you can't rebase it. Rebasing would modify the source branch without going through the policy approval process.

If you used the Merge Conflict Extension to resolve merge conflicts, you can't rebase. Conflict resolutions applied to a three-way merge are seldom successful or valid when rebasing all the PR commits individually.

If any of these situations apply, you can still rebase your branch locally and then push upstream, or squash-merge your changes when you complete the PR.

Request Settings

To enable a Release to be created from a pull request in Azure DevOps, you need to head over to the Pipeline > Release area and click the Edit button. From there, you can enable the Pull request trigger in the Artifacts section.

Credit: youtube.com, Azure DevOps | Branch Policies

You'll also need to enter Target Branch Filters, which are the branches that will be allowed to trigger a release when they are a target of a pull request. This is an important step to ensure that only specific branches can trigger a release.

To fix code coverage status checks that are failing in your pull request, you may need to change the Azure DevOps pull request settings. The default settings have a required code coverage of 70%, but the setting for displaying the results of the coverage check is set to off.

Create PRs

Creating a Pull Request is a crucial step in the development process. You can create a Pull Request at PR creation or update an existing PR.

To set a Pull Request to autocomplete, use the Set auto-complete option in Azure Repos and TFS 2017 and higher. This feature is only available when you have branch policies in place.

Credit: youtube.com, setting up required github PR checks (beginner - intermediate) anthony explains #315

If you don't see the Set auto-complete option, it's likely because you don't have any branch policies. You can check for more information on branch policies.

By default, a PR set to autocomplete waits only on required policies. However, you can choose to wait on optional policies as well in the Enable automatic completion panel.

To create a Pull Request, use the az repos pr create command with the --auto-complete true option. You can also update an existing PR to autocomplete using the az repos pr update command.

Here are the steps to create a Pull Request:

  • Create a Pull Request in Azure DevOps (or GitHub) and have a place to have a conversation about what you’ve changed in the code.
  • When you’re done, you accept and complete the Pull Request and the changes get merged back to Main.

Allow Request Trigger

To enable a Release to be created from a pull request, head over to the Pipeline > Release area in Azure DevOps and select the release in question.

You'll need to click the Edit button to make changes. In the Artifacts section, click the lightning bolt to edit the continuous deployment triggers.

This will open a dialog where you can enable the Pull request trigger. You'll also need to enter Target Branch Filters, which are the branches that will be allowed to trigger a release when they are a target of a pull request.

With the Pull request trigger enabled, you'll need to enable your sample stage to be deployed for releases based on pull requests. Click the lightning bolt on the left side of the stage to edit the pre-deployment conditions.

On the dialog that shows, enable the Pull request deployment setting.

Set Completion Options

Two business professionals brainstorming and planning software development with a whiteboard in an office.
Credit: pexels.com, Two business professionals brainstorming and planning software development with a whiteboard in an office.

You can set PR completion options when creating a PR with `az repos pr create`, or update creation options in existing PRs with `az repos pr update`. This allows you to customize the merge commit message, squash commits, and more.

To set completion options, you can use the following parameters with `az repos pr update`: `--bypass-policy`, `--bypass-policy-reason`, `--delete-source-branch`, `--merge-commit-message`, `--squash`, and `--transition-work-items`.

Here are the available parameters for setting completion options:

You can also set the PR to complete automatically when all policies have passed and the source branch can be merged into the target branch using the `--auto-complete` parameter.

Requests

Requests in Azure DevOps are a great way to collaborate with team members and ensure code quality. You can create a Pull Request to merge changes from a feature branch into the main branch, and then have a conversation about those changes.

To enable a Release to be created from a Pull Request, you need to head over to the Pipeline > Release area in Azure DevOps, select the release, and click the Edit button. This will allow you to enable the Pull Request trigger in the Artifacts section.

Woman in focus working on software development remotely on laptop indoors.
Credit: pexels.com, Woman in focus working on software development remotely on laptop indoors.

You can set PR completion options when creating a PR with az repos pr create, or update creation options in existing PRs with az repos pr update. For example, you can set the pull request to complete automatically when all policies have passed and the source branch can be merged into the target branch.

To complete a PR automatically, you can use the Set auto-complete option, which is available in Azure Repos and TFS 2017 and higher when you have branch policies. This option will complete and merge the PR changes as soon as conditions satisfy all branch policies.

Branch policies can automate a lot of stuff, including requiring a particular build definition to run. This will run your automated tests and code coverage, and the code coverage features of Azure DevOps Pull Requests will automatically start working.

You can create a Pull Request and the pipeline should get triggered automatically as part of the 'Required' checks. In case of build-failure, the Pull Request won't be allowed to merge.

To change the Azure DevOps Pull Request Settings, you can add a file named azurepipelines-coverage.yml to the root of your Git Repository. Inside this file, you can paste the following YAML code, which sets the comments value to on.

From above crop anonymous male programmer in black hoodie working on software code on contemporary netbook and typing on keyboard in workspace
Credit: pexels.com, From above crop anonymous male programmer in black hoodie working on software code on contemporary netbook and typing on keyboard in workspace

Here is a list of PR completion options that you can set when creating a PR with az repos pr create, or update creation options in existing PRs with az repos pr update:

  • bypass-policy {false, true}: Whether to bypass any required policies and complete the pull request once it can be merged.
  • bypass-policy-reason: Reason for bypassing required policies.
  • delete-source-branch {false, true}: Whether to delete the source branch after the pull request has been completed and merged.
  • merge-commit-message: Customize the merge commit message.
  • squash {false, true}: Whether to squash the source commits into a single target commit for merge.
  • transition-work-items {false, true}: Whether to resolve linked work items when the PR merges.

Frequently Asked Questions

How do I see all PRs in Azure DevOps?

To view all pull requests in Azure DevOps, navigate to your team project's Repo > Pull requests from your web browser. This will list all open pull requests, including their title, description, and status.

How to approve PR in Azure DevOps?

To approve a PR in Azure DevOps, you must be a project member with Basic access or higher and have the necessary permissions, typically by being part of the Readers security group. Get added to the project and security group to start reviewing and approving PRs.

What is PR in Azure DevOps?

A pull request (PR) in Azure DevOps is a way to propose changes to code in a Git repository, allowing for review and merging of updates. It enables collaboration and ensures code quality by facilitating peer review and approval.

How do you run checks on a pull request?

To re-run failed checks on a pull request, click the pull request number and select Re-run Failed Checks. This will re-execute the checks that previously failed.

Calvin Connelly

Senior Writer

Calvin Connelly is a seasoned writer with a passion for crafting engaging content on a wide range of topics. With a keen eye for detail and a knack for storytelling, Calvin has established himself as a versatile and reliable voice in the world of writing. In addition to his general writing expertise, Calvin has developed a particular interest in covering important and timely subjects that impact society.

Love What You Read? Stay Updated!

Join our community for insights, tips, and more.