Setup Azure DevOps for efficient Pull Requests

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.

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.

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.

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:

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.

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:

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.

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

trigger: none

pool:
  vmImage: 'macOS-10.14'

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

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

  - stage: Build_Xamarin_Android
    dependsOn: Run_Unit_Tests
    jobs:
      - job:
        displayName: 'Build Xamarin.Android'
        steps:
          - template: templates/init_restore.yml
            parameters:
              solutionPath: '$(solutionPath)'
          
          - template: templates/build_xamarin_android.yml
            parameters:
              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
    jobs:
      - job:
        displayName: 'Build Xamarin.iOS'
        steps:
          - template: templates/init_restore.yml
            parameters:
              solutionPath: '$(solutionPath)'

          - template: templates/build_xamarin_ios_ipa.yml
            parameters:
              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 Twitter to not miss my next tutorial!