Photo by Josh Redd

Setup Azure DevOps for efficient Pull Requests

Improve the quality of your code!

Posted by Damien Aicheh on 07/09/2020 · 7 mins

When there are many developers on the same project you need to merge your code to a single branch, but before it’s important to insure that the new feature you just created is done correctly. To check, you need to propose your code as a pull request (PR). In this article I m going to explain you, why doing pull requests are importants and how to configure them through Azure DevOps.

Why doing some pull requests?

To build a good project with a team, each developer needs to understand how the project is structured and what the rest of the code does. Doing pull requests is not a waste of time because:

  • It ensures that many members of your team know parts of the code they have not written
  • You can learn from each other
  • Avoid some wrong architecture implementation
  • Improve the code as the project progresses
  • Detect potential bugs early

What can be done with Azure DevOps?

Azure DevOps has a really interesting interface for submitting Pull Requests.

Configuring the policies for a specific branch can be done easily. Go to Azure DevOps in the Repos > Branches sections and then click on the 3 little dots on your reference branch to set up policies.

Branch policies

The reviewers

First it’s recommended to require a number of reviewers. A minimum of 1 reviewer is needed but if you have 2 it’s even better. Also disable the ability to auto approve your work, if you don’t do that, pull requests has no sense. Remember, the goal is to give the ability to the others developers to check your code before it’s being merged into the rest of the project.

Minimum reviewer

Then, to let the reviewer(s) check the code and understand more what was done, it’s important to ask for linked work items, it also avoid adding some code that does not match exactly the User Story or the task associated.

Linked items

At a glance you can see the status of your pull request: the reviewer(s) have the ability to Approve, Approve with suggestions, Wait the author or Reject which is directly visible with a little badge.

If your project needs it, you can also provide a list of reviewers which will be automatically notified when a new pull request is created, this can be interesting for the architect or technical leader of the project for instance:

Default reviewers

The comments

After reviewing a pull request if some comments were made it’s important to check if they have been seen by the developer before closing it. So it’s important to check the comment resolution checkbox.

Comments resolution

If all comments are not set to resolve the pull request could not be merged with the rest of the code. The comments are a good way to comunicate between developers, you can also tag someone to draw its attention to a specific point.

Build the project

To make sure the project not only build in the developer machine it’s a good thing to add a build validation using the Azure DevOps pipelines. If you already have setup one, it’s easy, click on Build Validation and select the pipeline you want to run:

Build pipeline

In this case the pipeline is named Pull Request Check.

Let’s take an example with a Xamarin project which is composed of an iOS, Android and a Unit Tests project. You will first run the Unit Tests and then build the two platform projects. If one of these 3 steps failed, your pull requests will not be able to complete and the code will not be merged. It’s a good way to avoid embedding some code that doesn’t compile with the rest of the project.

Pull request build

Down below an example of YAML configuration for your pull requests:

trigger: none

  vmImage: 'macOS-10.14'

  - group: xamarin-full-pipeline
  - template: templates/variables.yml

  - stage: Run_Unit_Tests
      - job:
        displayName: 'Run Unit Tests'
          - template: templates/run_unit_tests.yml
              solutionPath: '$(solutionPath)'
              projects: '$(Build.SourcesDirectory)/XamarinDevOps.Tests/*.csproj'
              buildConfiguration: '$(buildConfiguration)'

  - stage: Build_Xamarin_Android
    dependsOn: Run_Unit_Tests
      - job:
        displayName: 'Build Xamarin.Android'
          - template: templates/init_restore.yml
              solutionPath: '$(solutionPath)'
          - template: templates/build_xamarin_android.yml
              xamarinSdkVersion: '$(xamarinSdkVersion)'
              packageFormat: 'aab'
              projectFile: '$(Build.SourcesDirectory)/XamarinDevOps.Android/*.csproj'
              buildConfiguration: '$(buildConfiguration)'
              apksignerKeystoreFile: 'production.jks'
              apksignerKeystorePassword: $(keystore.password)
              apksignerKeystoreAlias: $(key.alias)
              apksignerKeyPassword: $(key.password)

  - stage: Build_Xamarin_iOS
    dependsOn: Run_Unit_Tests
      - job:
        displayName: 'Build Xamarin.iOS'
          - template: templates/init_restore.yml
              solutionPath: '$(solutionPath)'

          - template: templates/build_xamarin_ios_ipa.yml
              xamarinSdkVersion: '$(xamarinSdkVersion)'
              p12FileName: '$(p12FileName)'
              p12Password: '$(p12Password)'
              provisioningProfile: '$(provisioningProfile)'
              solutionPath: '$(solutionPath)'
              buildConfiguration: '$(buildConfiguration)'
              signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)'
              signingProvisioningProfileID: '$(APPLE_PROV_PROFILE_UUID)'

This is the same process as for a nightly build. You can find all the explanation detailed in my previous tutorial.

Final touch

If you haven’t got pull request setup in your project with Azure DevOps, don’t wait, you will save a lot of time and learn so much, you will not regret it I guarantee it!

Do not hesitate to follow me on to not miss my next tutorial!