Photo par Josh Redd

Configurez Azure DevOps pour des Pull Requests efficaces

Améliorez la qualité de votre code !

Posted by Damien Aicheh on July 09, 2020 · 7 mins

Lorsque vous développez votre projet par équipe, vous devez merger votre code en une seule branche, mais avant il est important de vous assurer que la nouvelle fonctionnalité que vous venez de créer est faite correctement. Pour vérifier, vous devez proposer votre code en tant que pull request (PR). Dans cet article, je vais vous expliquer pourquoi les pull requests sont importantes et comment les configurer avec Azure DevOps.

Pourquoi faire des pull requests ?

Pour construire un bon projet avec une équipe, chaque développeur doit comprendre comment le projet est structuré et ce que fait le reste du code. Faire des pull requests n’est pas une perte de temps car:

  • Cela garantit que plusieurs membres de votre équipe connaissent le code de l’ensemble du projet
  • Vous pouvez apprendre les uns des autres
  • Évitez une mauvaise mise en œuvre de l’architecture
  • Améliorez le code tout au long du projet
  • Détectez rapidement les bugs potentiels

Que peut-on faire avec Azure DevOps ?

Azure DevOps possède une interface vraiment intéressante pour soumettre des Pull Requests.

La configuration des stratégies pour une branche spécifique peut être effectuée facilement. Accédez à Azure DevOps dans les sections Repos > Branches, puis cliquez sur les 3 petits points de votre branche de référence pour configurer les stratégies.

Branch policies

Les relecteurs

Tout d’abord, il est recommandé d’exiger un certain nombre de relecteurs. Un minimum de 1 critique est nécessaire, mais si vous en avez 2, c’est encore mieux. Désactivez également la possibilité d’approuver automatiquement votre travail. Si vous ne le faites pas, les pull requests n’ont aucun sens. N’oubliez pas que l’objectif est de donner aux autres développeurs la possibilité de vérifier votre code avant de le merger au reste du projet.

Minimum reviewer

Ensuite, pour permettre aux relecteurs de vérifier le code et de mieux comprendre ce qui a été fait, il est important de demander les éléments de travail liés, cela évite également d’ajouter du code qui ne correspond pas exactement à la User Story ou à la tâche associée.

Linked items

En un coup d’œil, vous pouvez voir l’état de votre demande de tirage: le ou les relecteurs ont la possibilité d’Approve, Approve with suggestions, Wait the author ou Reject qui est directement visible avec un petit badge.

Si votre projet en a besoin, vous pouvez également fournir une liste de relecteurs qui seront automatiquement avertis lors de la création d’une nouvelle pull request, cela peut être intéressant pour l’architecte ou le responsable technique du projet par exemple:

Default reviewers

Les commentaires

Après avoir examiné une pull request si certains commentaires ont été faits, il est important de vérifier s’ils ont été vus par le développeur avant de la fermer. Il est donc important de cocher la case ‘résolution des commentaires’.

Comments resolution

Si tous les commentaires ne sont pas à resolve, la pull request ne peut pas être mergé avec le reste du code. Les commentaires sont un bon moyen de communiquer entre développeurs, vous pouvez également taguer quelqu’un pour attirer son attention sur un point précis.

Builder le projet

Pour vous assurer que le projet ne build pas uniquement sur la machine du développeur, c’est une bonne chose d’ajouter une validation de build à l’aide des pipeline Azure DevOps. Si vous en avez déjà configuré un, c’est facile, cliquez sur Build Validation et sélectionnez le pipeline que vous souhaitez exécuter:

Build pipeline

Dans ce cas, le pipeline est nommé Pull Request Check.

Prenons un exemple avec un projet Xamarin composé d’un projet iOS, Android et d’un projet de tests unitaires. Vous allez d’abord exécuter les tests unitaires, puis builder les deux projets de plate-forme. Si l’une de ces 3 étapes a échoué, vos pull requests ne pourront pas se terminer et le code ne sera pas fusionné. C’est un bon moyen d’éviter d’incorporer du code qui ne compile pas au reste du projet.

Pull request build

Ci-dessous un exemple de configuration YAML pour vos demandes de 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)'

C’est le même processus que pour un nightly build. Vous pouvez trouver toutes les explications détaillées dans mon précédent tutoriel.

Touche finale

Si vous n’avez pas de configuration de pull request dans votre projet avec Azure DevOps, n’attendez pas, vous gagnerez beaucoup de temps et apprendrez tellement, vous ne le regretterez pas, c’est garanti!

N'hésitez pas à me suivre sur pour ne pas rater mon prochain tutoriel !