Dans mon dernier article, j’ai introduis Git Flow avec un exemple, la naissance d’une application.
A un moment, je raconte l’évolution de l’équipe de dev et de leur organisation autour du code source. On y parle de Pull Request.
La PR est une procédure de validation d’un ensemble de commits regroupés dans une branche feature (quand on applique Git Flow). On peut aussi appliquer une PR de la branche develop vers master. C’est ce qu’on appelle une « release ».
Chacun ayant ses stratégies, je vous propose la mienne, qui va bien pour un petit/moyen projet :
Situation
J’ai 2 branches principales :
– master. A considérer comme la branche release car c’est ce code qui part en prod.
– develop. Son code part en staging. Ca sert aux dev pour voir le résultat de leur travail sans influencer la prod.
Quand j’estime que la branche develop a quelque chose d’intéressant, je pousse le code vers la master (merge).
Cette action est réalisé via une Pull Request depuis Azure Devops. Je ne fais aucune manipulation git. Tout ce passe sur Azure Devops. D’ailleurs j’ai interdit toute manipulation de la branche master en dehors d’une PR. Voyons voir comment faire cela :
Règle de branche master
Sur Azure Devops, il faut se rendre sur l’onglet « Repos » puis « Branches » :
Cliquez sur le bouton à droite de la branche master, ce qui ouvre un menu. Cliquez sur Branch Policies.
Nous y voila, si on lit la première ligne, elle nous dit que si une seule des options est cochée, alors la branche ne peut pas être effacée et toute modification devra passer par une PR. Quelque part, je pourrais m’arréter la car c’est tout ce dont j’ai besoin. Mais on va voir qu’il y a quelques options bien intéressantes :
– Require a minimum number of reviewers. J’ai une équipe de 1 dev, moi. donc je vais m’auto évalué, ça n’a pas de sens. Je n’ai pas coché cette case. Mais c’est intéressant dès lors qu’on valide par un second dev (lead tech pour la master).
– Check for linked work items. Cette option est intéressante dès lors que l’on travaille avec un backlog. Ce qui n’est pas mon cas pour ce projet « demo ». Mais c’est conseillé. En effet, vous allez améliorer chaque PR avec un « work item » qui sera donné par votre product owner ou votre tech lead. C’est hyper quali de faire ça. Surtout intéressante depuis une branche feature vers la develop. Ici depuis la branche develop vers la master, on aurait plus un ensemble de feature. A voir avec les types de work item. Si ca se trouve ça peut coller.
– Check for comment resolution option pas obligatoire. Si coché, cela force à valider tout commentaire dans le code. On le verra plus tard, mais si un reviewer constate un manquement, une erreur ou une objection dans le code, il le signifie par un « commentaire ». Si celui ci n’est pas « résolut », alors on peut pas valider la PR. A tester avec votre équipe. La encore, c’est intéressant pour une PR vers la branche develop
– Limit merge types cette option permet de laisser le choix lorsque la PR est validé, de choisir le type de merge que l’on souhaite appliquer à la branche cible. Pour mon cas, je ne laisse pas le choix, j’impose un squash merge. La encore, c’est les goûts et les couleurs. It’s up to you. Je pense qu’un article entier peut y être consacré. On en discute encore dans l’équipe où je bosse…
On va maintenant rajouter des règles de build :
On ajoute une règle qui impose qu’un build s’execute correctement. Pour cela on doit construire une pipeline de build. Si la branche develop ne build pas, alors on ne fait pas le merge. Pour ma part, le build est un publish. Ce qui revient a peu prêt au même (un publish est un build + génération des fichiers statics web dans le cas d’une app Blazor WASM).
Ma première Pull Request
On va tester tout ça. On va dans Repos – Pull request
Cliquez sur New pull request :
Il faut choisir sa source et sa destination, pour nous, develop –> master
Notez que j’ai juste mis un titre. On peut ajouter des reviewers et bien sûr un work item. Tout ca on le verra dans une pull request de type feature –> develop. Cliquez sur Create. Voici ce qui se passe :
Première chose, on a un élément requis qui doit se lancer. Celui ci c’est notre « règle de build » écrite juste avant.
Notez aussi qu’il y a un check « No merge conflict ». Ce qui permet de vérifier en amont qu’on a pas foiré un merge/rebase malencontreux. Si on attends qq secondes :
On voit notre pipeline qui se lance et qui passe au vert si notre publish est ok.
En haut a droite on a un bouton approve qui va concerner des validations « humaines ».
Tout est vert. On a un pre-merge ok. Un build ok. Pas de reviewer, et pas d’autre règle (j’ai volontairement fait en sorte que ce soit pas trop compliqué pour cet exemple)
Si on clic sur Complete
On a un message qui veut supprimer develop. On veut pas. Surtout pas. D’ailleurs on fera en sorte par la suite de rendre develop ineffacable.
Le squash commit est l’unique option, comme indiqué dans les règles de la branche master que l’on vient de définir. On peut si on veut rajouter un commentaire personalisé de commit.
On clique sur Complete merge, quand il est fini, on a cette info :
Et si on vérifie nos pipeline, notre DEPLOY master to prod est lancée !
On vient d’automatiser notre branche master. Elle est sécurisée (personne hormis une PR peut la modifier). Elle est tracable et on peut échanger via une interface web sur une operation qui d’habitude se passe en ligne de commande dans un coin.
De plus en rajoutant une seconde pipeline, lorsque la PR est validé puis mergé, on a un deploy automatique vers la prod. QUE DE TEMPS GAGNE !
Ces opérations, d’habitude sont longues et pas rassurante. Ici on est ceinture bretelle. (j’ai pas parlé de Test auto, mais ca rentre dedans)
suite de l’article : https://reactor.fr/azure-devops-pull-request-part-2/
