From 30a0bfbfddf611eec2432950ab7f9c48d0b42e33 Mon Sep 17 00:00:00 2001 From: Anthony Borghi <anthony.borghi@veremes.com> Date: Fri, 17 Nov 2023 10:33:24 +0100 Subject: [PATCH] process git reporter/MR --- source/tools/git/basics.md | 44 +++++++++++++++++++++++++++++++++++++- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/source/tools/git/basics.md b/source/tools/git/basics.md index 72179a3..451c168 100644 --- a/source/tools/git/basics.md +++ b/source/tools/git/basics.md @@ -206,4 +206,46 @@ L'écriture de la documentation suit le flow habituel en temps normal. La documentation est validée avec le responsable produit et le service Marketing si possible. -En ce qui concerne la rédaction des documentations des applications, une charte est disponible à [ce lien](http://documentation.veremes.net/charte/index.html). \ No newline at end of file +En ce qui concerne la rédaction des documentations des applications, une charte est disponible à [ce lien](http://documentation.veremes.net/charte/index.html). + +## Processus de création des issues + +Lorsque vous trouvez une anomalie, ou que vous pensez à une évolution interressante pour une application. Vous devez ajouter une issue sur le dépot d'une des **applications** concernés (dans le cas où plusieurs applications sont concernés, celle pour laquelle c'est le plus pertinent ou qui sortira le plus rapidement). + +Vous pouvez assigné les tags en fonction du type d'issue (bug/évolution), et éventuellement, dire si ça concerne le noyau, un module, .... + +Quoiqu'il arrive vous n'assignez jamais le milestone, sauf contre indication du responsable de l'application, ou dans le pire des cas vous le passer dans le milestone qui contient les tickets non assigné s'il y en a un (sur le dépot de GTF à définir par exemple). L'assignation d'un ticket à un milestone, joue sur la feuille de route de l'application et ce genre de choix doit être fait en accord avec le responsable applicatif concerné. + +Si votre issue est relative à d'autres issues, n'hésitez pas à les lier, ça permettra au développeur qui fera l'issue d'avoir un complément d'information. Dans la même idée, n'hésitez pas à ajouter des capture d'écran, maquette, ou tout ce qui pourra aider le développeur à reproduire/comprendre une feature. + +## Processus de gestion des merge requests + +Lorsque vous prenez une issue, vous allez suivre le flow Git, créer la branche et la merge request liée, faire votre développement, puis assigner la merge request (MR par la suite) à une ou plusieurs personnes. + +De façon à faciliter la vie à cette personne, je pense qu'il est important que tout le monde adopte les mêmes pratiques. + +Prenons l'exemple d'une fonctionnalité que vous venez de terminer. Vous allez pouvoir assigner la MR à un reviewer et/ou un responsable. + +Première étape, retirer le mot clé draft au début du titre en cliquant sur "Mark as ready", ça permet d'expliciter que la MR est prète pour la review. + +On va considerer en interne que le role de reviewer vise à relire le code sans pour autant valider la MR, une fois que le reviewer a relu le code, tester la fonctionnalité, il va pouvoir cliquer sur le bouton approve pour notifier le responsable de la MR, que pour lui la première lecture est conforme au résultat attendu. Dans le cas contraire, il ajoutera des commentaires de façon à ce que le développeur fasse certaines modification. le responsable, lui aura la même fonctionnalité sauf qu'il lancera en plus le merge et sera en charge de tenir le dépot propre (suppression de branche artéfact, ...). Dans l'état l'ajout d'un reviewer se fait en fonction de la charge des lead, ou d'indication spécifique sur les projets. + +Une fois que le/les reviewers ont approuvés la MR, c'est au responsable de passer sur la MR, de faire une dernière vérification, en fonction de ses tests, valider ou non la MR. Sa validation clôturera la MR, mergera la banche, ... + +Petite mise en situation pour illustrer tout ça : + +Michel est un développeur, Sam est un autre développeur en charge de relire le code de Michel, et Max est le lead developer en charge de valider les MR pour une application. + +1. Michel prend une issue d'évolution, il va donc copier l'issue sur les modules concernés, créer une branche depuis next_version pour chaque module concerné, associé une Merge Request (qu'il n'assignera pas à ce moment là). Opération classique décrite dans le flow précédemment. + 1. Michel est sympa, donc il coche la case "delete source branch ..." ce qui économisera un clique à Max à la fin. +1. Michel réalise l'évolution demandé, il doit passer par Sam qui va faire la review de son code, il ajoute donc Sam, comme reviewer. +1. Michel clique sur "Mark as ready" de façon à retirer le statut "Draft:" +1. Michel va aussi ajouter le tag "En cours de validation" à minima sur l'issue principale pour simplifier la vie du responsable de l'application. + 1. Michel a oublié de vérifier le linter manuellement, qui ne passe pas, la MR est donc automatiquement bloquée. Michel doit donc mettre en conformité son code avant que Sam intervienne (voir le désassigner temporairement). +1. Sam passe sur l'issue (Michel a pu corriger les erreur de lint avant), et valide le code de Michel, il clique donc sur "Approve". +1. Michel peut alors assigner la MR à Max pour le contrôle final. +1. Max fait un retour à Michel sur un petit point de lisibilité du code, rien de méchant. +1. Max se désassigne la MR (de façon à limiter son retour dans l'application ce qui lui simplifie le listing). +1. Michel fait la retouche et réassigne la MR à Max. +1. Max valide finalement le code, initialise le merge (clique sur "delete source branch ...", si ce n'est pas fait, mais Michel est sympa il l'a fait en amont), Max va ensuite aller cloturer manuellement toutes les issues associés (à minima 2). +1. Max en profitera pour retirer les tags "Validation en cours". -- GitLab