Lors du précédent article, nous avons démontrer une approche de développement Agile avec Git et Visual Studio 2017. Pour compléter cette expérience, nous allons regarder dans le présent article comment avec VSTS et Visual Sudio le développeur va pouvoir valider la qualité de ses développement au travers du processus de Pull Request.
Suite au dernier article, nous avons développé une fonctionalité de calcul de Discount, le code a été commité localement puis poussé sur le serveur via un Push.
C'est à ce moment précis qu'intervient tout le processus qualité au travers de l'intégration continue et des Pull Requests. Pour rappel, l'objectif d'un Pull Request est de proposer du code poussé au travers d'une feature branche pour promotion au merge dans la branche master.
Définition : Une Pull Request est un process collaboratif qui permet au reste de l'équipe de discuter des changements dans une feature branch et valider le merge vers master une fois que tout le monde à approuvé.
Définition : Une Pull Request est un process collaboratif qui permet au reste de l'équipe de discuter des changements dans une feature branch et valider le merge vers master une fois que tout le monde à approuvé.
ETAPE 1 - Configuration préliminaire pour les Pull Requests
La première chose à faire est de préparer son Repo pour la gestion des Pull Requests
Afin de procéder à la revue de la Pull Requests, il faut d'abord que le code présenté passe au travers d'un "Quality Gate", nous allons utiliser pour cela une Build. Nous créeons à cet effet une build suffixée PR (pour Pull Request) qui sera utilisée pour la validation des Pull Requests, pour cela nous clonons simplement la Build Master CI qui est notre build d'intégration continue standard pour notre branche master.
Le point suivant va consister à configurer les Branch Policies de notre Repository, à partir de l'onglet Code / Version Control, choisir la branche master du Repo et cliquer sur l'onglet Branch Policies comme montré ci dessous
La première configuration consiste à demander l'exécution de la build dédiée pull Request afin de s'assurer que le Reviewer va inspecter du code qui passe le minimum qualité imposé à savoir que le code compile, les tests passent et l'analyse automatique de code est OK. Tous ces points sont portés par le workflow de la build.
Il faut s'assurer également que la Pull Request est bien reliée à un PBI et dans notre exemple, que la Pull Request ne peut pas être validée par la personne qui a poussé le changement, également que la Pull request ne pas être complétée si le reviewer l'a rejetée
Il suffit simplement de sauvegarder cette configuration
ETAPE 2 - Création et Validation d'une Pull Request
Une Pull Request peut être crée par le développeur à partir de Visual Studio. Après avoir poussé ses changements sur le serveur, il suffit de naviguer dans l'onglet Branches du Team Explorer, se positionner sur la feature branch, dans notre exemple Discount et lancer la commande Create Pull Request
On est alors redirigé sur l'instance web de VSTS, il suffit alors de compléter la description de la Pull Request, selectionner le ou les reviewers et valider la création
On peut voir en bas de page le code modifié / ajouté / supprimé
Suite à la création, on est redirigé vers la page de statut de la Pull Request, et en parallèle la build a été lancée
Le point très interessant au niveau des Pull requests est notamment la discussion qui peut être initée directement dans le code inspecté, ci dessous après avoir activé l'onglet Files, on peut voir le thread de discussion inité
Il est interessant également de regarder le contenu des onglets Updates et Commits pour le détail
Enfin si tout est OK du point de vue du Reviewer, il reste à approuver la Pull Request :
Ce qui va déclencher une build de validation du merge, et dernière étape, il va falloir Compléter la Pull request, si la build n'est pas terminée, c'est indiqué dans le haut de la boite de dialogue.
Dès que la build est terminée, on peut complèter le merge
Au final, on a l'affichage du détail montrant l'achèvement avec succès de la Pull Request
On notera que nous avons demandé la suppression de la feature branch suite au merge et également un Squash des changements qui consiste à condenser l'historique des changements réalisés dans la feature branche (nous n'avons plus tout le détail), comme montré ci dessous
Aucun commentaire:
Enregistrer un commentaire