Une Pull Request est un moyen fréquent utilisé sur la plupart des projets en équipe pour développer des features de manière plus propre.
Elle donne la possibilité d’obliger un développeur à adopter des guidelines de développement. Elle évite les éternels conflits de commit lorsque plusieurs personnes travaillent en même temps sur des fichiers communs.
Leur gestion passe tout d’abord par la sécurité des branches de développement. Nous allons reprendre l’application exemple horizon pour créer deux nouvelles branches : demo et prod.
En imaginant que je souhaite travailler en équipe sur ce projet, je veux sécuriser la branche « master » pour que celle-ci puisse recevoir les commits des différents développeurs avec le moins de conflits possible, fonctionnalité par fonctionnalité.
La branche de « demo » servira quant à elle à déployer le projet dans un MDM tel qu’AppCenter afin de présenter l’application à un client ou de la distribuer à un nombre restreint de personnes.
Enfin la branche de « prod » servira à déployer le résultat sur le store.
En appuyant sur le menu contextuel, appuyez sur « Branch policies ». On aperçoit alors un nouveau menu. Celui-ci permet de protéger la branche et gérer les conditions d’acceptation de la pull request.
Le formulaire apporte donc un certain nombre de fonctionnalités que nous allons détailler.
En cochant un nombre de reviewers. La pull request se retrouve bloquée tant qu’un certain nombre de personne n’a l’a pas évaluée. En plaçant le minimum à 1, une équipe de 2 personnes ou plus peuvent travailler ensemble aisément.
En ajoutant la fonctionnalité « Boards » à Azure DevOps, il est possible de gérer le projet via un système de ticketing, de work items et d’entretenir un Backlog pour gérer ses projets sous la forme de sprint.
En intégrant ceci à notre projet, il est possible d’assigner les pulls requests à des works items et améliorer la visibilité du projet pour un product owner ou un chef de projet. Leur non-assignation peut également être considérée comme bloquante mais alors qu’en est-il des pulls requests contenant un petit « fix » ?
En cochant la résolution des commentaires avant la résolution, il n’est pas seulement possible de bloquer une pull request après la review d’un autre développeur. Il est également possible de faire un blocage après l’analyse d’un service tel que SonarQube.
Il est également possible de modifier le résultat de merge d’une pull request. Ceci se gère en fonction, bien sûr, des préférences de développement que vous avez mise en place.
La partie « Build Validation » est la plus importante de la gestion d’une pull request. En effet, elle permet de valider que le développement réalisé fonctionne. En y plaçant la build principale du projet, on peut ainsi s’assurer que celui-ci pourra générer le projet correctement. Mais il ne garantit pas sa qualité. Des builds pour des tests unitaires, un SonarQube ou toute autre build qui peut être relative au projet.
La validation par service additionnel permet également de conditionner la pull request au fonctionnement de service ou à des déclencheurs particuliers. Le lien suivant permet d’avoir un aperçu de leurs fonctionnalités et de leur création :
L’exemple simple est de faire une vérification sur le fonctionnement d’une API avant de vérifier l’application.
Enfin l’ajout automatique de reviewers peut bloquer une pull request tant que celle-ci n’est pas validée par au moins la personne désignée. Ainsi un Leader Technique peut passer le code de l’équipe en revue avant le merge final.
Le résultat de la merge request est, en résumé et pour cet exemple, le suivant :
- Il faut au moins une personne pour valider ma pull request
- Je suis rajouté automatiquement à ma propre pull request
- Je ne peux pas valider seul ma propre pull request
- Je dois au moins valider moi-même ma pull request
- La build de développement doit réussir
- La build de test unitaire doit réussir
- Tous les commentaires doivent être résolus
Tout cela est donc parfait, cependant si je souhaite avoir la possibilité de valider mon propre code seul, je dois avoir des droits supplémentaires. Et pour cela je dois retourner au niveau de la liste des branches.
En m’attardant cette fois-ci sur les sécurités.
J’ajoute le droit de "Bypass" les règles de sécurités liées aux pull request pour pouvoir effectuer un commit malgré tout cela.
Voilà, vous avez maintenant toutes les clefs en main pour travailler en équipe sur un projet.
