Gestion de plusieurs demandes de tirage d'une branche
Notre flux de travail actuel consiste à créer une branche Sprint, puis les développeurs créent des branches Feature avec le numéro de la user story. Une fois l'histoire terminée, cette branche Feature est fusionnée à la branche Sprint par pull request où elle subit un examen du code. Une fois la révision du code terminée, nous lançons une autre demande d'extraction à la branche Développer, où la révision du code sur site est effectuée.
Le problème est que lorsque plusieurs équipes créent des demandes de tirage de Sprint vers la branche Développement, les demandes de tirage en pipeline sont approuvées lorsque la dernière demande de tirage est approuvée (est-ce le comportement attendu?)
Les coordinateurs sur site utilisent les informations de demande d'extraction de la branche Sprint to Develop pour suivre les modifications qui doivent être mises en production.
Mais comme mes demandes de tirage sont automatiquement approuvées lorsqu'un autre dans le pipeline est approuvé, je ne peux pas obtenir le statut de la demande de tirage que j'ai soulevée. Je dois accéder à l'historique des validations de la branche Develop pour trouver le commit de fusion de la demande d'extraction.
Existe-t-il un moyen simple de suivre ma demande de tirage?
L'affichage d'une demande de tirage d'un sprint vers une branche de publication est susceptible d'inclure de nombreux changements. Ces modifications ont déjà été examinées dans les demandes de tirage précédentes. Exiger ne autre révision du code pour incorporer les changements du sprint actuel semble redondant. Fusionnez simplement la branche sprint dans la branche develop et poussez-la. Si vous ne faites qu'une seule fusion par sprint pour l'ensemble du projet, la fusion devrait de toute façon être une fusion à avance rapide, ce qui présente un faible risque.
Le vrai problème est la branche "sprint". Dans un commentaire, vous avez mentionné que les branches de sprint sont créées afin de suivre le sprint dans lequel une fonctionnalité ou une tâche a été terminée. Ce n'est pas pour cela que Git a été conçu - ni aucun système de contrôle de version d'ailleurs. Le suivi des éléments de travail n'est pas une préoccupation pour le contrôle de version. Vous devez utiliser un autre outil pour cela, comme Jira, Azure DevOps, Rational Team Concert et leurs semblables. Même des notes post-it ou une feuille de calcul Excel peuvent mieux fonctionner que d'utiliser une branche pour un sprint.
La corrélation d'une validation avec un sprint doit être effectuée à l'aide de l'horodatage associé à cette validation. Vos sprints doivent découper l'année civile en plus petits morceaux avec une date de début et de fin bien définie. Si un commit tombe dans la date de début et de fin d'un sprint, il a été validé dans ce sprint. Encore une fois, cependant, l'état d'un élément de travail doit être suivi ailleurs, pas dans le contrôle de version.