- Azure DevOps
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.
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:
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
Branches sections and then click on the 3 little dots on your reference branch to set up policies.
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 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:
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.
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.
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!