- Azure
- Azure DevOps
- Xamarin
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.
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.
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.
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:
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’.
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:
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.
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!