Plusieurs équipes de mon entreprise pratiquent un workflow de révision de code que je n'avais jamais vu auparavant. J'essaie de comprendre la pensée derrière cela, avec l'idée qu'il est utile de rendre l'ensemble de l'entreprise cohérent. (Je contribue à plusieurs bases de code et j'ai été trébuché par les différences dans le passé.)
- L'auteur du code soumet une demande d'extraction
- Le réviseur examine le code
- Si le réviseur approuve, il laisse un commentaire du type "Ça a l'air bien, n'hésitez pas à fusionner"
- Si le réviseur a des préoccupations, il laisse un commentaire du type "Veuillez corriger les problèmes mineurs X et Y, puis fusionner" (pour les modifications majeures, revenez à l'étape 2)
- L'auteur du code apporte des modifications si nécessaire, puis fusionne sa propre demande d'extraction
J'ai les préoccupations suivantes:
Dans le cas de l'approbation à l'étape 3, ce flux de travail crée un aller-retour apparemment inutile pour l'auteur de la demande d'extraction. Le réviseur, qui examine déjà le code, pourrait simplement le fusionner immédiatement.
Dans le cas où des modifications sont demandées à l'étape 3, l'agence de fusionner la demande d'extraction appartient désormais uniquement à l'auteur du PR. Personne d'autre que l'auteur ne se penchera sur les changements avant la fusion.
Quels sont les autres avantages ou inconvénients de ce flux de travail? Ce flux de travail est-il courant dans d'autres équipes d'ingénierie?
la source
Réponses:
Dans le premier cas, c'est généralement une courtoisie. Dans la plupart des organisations, les fusions lancent une série de tests automatisés qui doivent être traités rapidement en cas d'échec. Surtout s'il y a eu un délai important entre le moment où une demande de retrait a été soumise et le moment où elle a été examinée, il est poli de permettre qu'elle soit fusionnée selon le calendrier de l'auteur, afin qu'ils aient le temps de faire face aux retombées inattendues. La façon la plus simple de le faire est de les laisser fusionner eux-mêmes.
De plus, parfois, l'auteur prend conscience des raisons pour lesquelles une demande d'extraction ne doit pas encore être fusionnée. Peut-être que le RP d'un autre développeur est plus prioritaire et provoquerait des conflits. Peut-être qu'elle a pensé à un cas d'utilisation découvert. Peut-être qu'un commentaire de révision a déclenché un remue-méninges qui nécessite une enquête plus approfondie avant que le problème ne soit pleinement satisfait. L'auteur en sait le plus sur le code, et il est logique de lui donner le dernier mot sur sa fusion.
Sur le deuxième point, c'est juste une question de confiance. Si vous ne pouvez pas faire confiance aux gens pour résoudre des problèmes mineurs sans être revérifiés, ils ne devraient pas travailler pour vous. Si le problème est suffisamment important pour nécessiter un autre examen après la correction, faites confiance aux examinateurs pour en demander un.
Cela étant dit, je fusionne parfois les demandes de tirage d'autres auteurs, mais il s'agit généralement de modifications très simples ou de sources externes, où je prends personnellement la responsabilité de gérer les échecs d'automatisation des tests.
la source
La fusion de leur propre demande d'extraction par l'auteur initial est mon flux de travail préféré dans les petites équipes. En plus des avantages techniques déjà mentionnés (en termes de résolution des conflits de fusion, par exemple), je pense que cela ajoute de la valeur au niveau culturel: il crée un sentiment d'appartenance.
J'ai spécifié l' auteur initial pour le (rare) cas où un autre développeur ajouterait des validations à la demande d'extraction ouverte (en tirant la branche de fonctionnalité en cours et en la repoussant). Cela n'arrive pas souvent et résulterait d'une conversation en personne ou sur Slack: ces commits supplémentaires (par quelqu'un d'autre) ne devraient pas y atterrir par surprise! Dans ce contexte, par auteur initial , je veux dire celui qui a soumis la demande de retrait.
la source
Dans mon organisation, nous sommes tout à fait nouveaux dans les demandes de tirage et votre question est celle que j'ai moi-même réfléchie.
Je voudrais ajouter une observation: dans certains outils (nous utilisons TFS), il peut y avoir un élément de travail associé à la demande d'extraction.
Si tel est le cas, cela devient un peu compliqué de savoir quand le réviseur a effectué la fusion. Dans ce scénario, le développeur doit alors revoir le PR, ouvrir le bogue ou la demande de changement et le marquer comme «résolu». Si nous le marquons «résolu» trop tôt, les testeurs pensent que le correctif fait déjà partie de la version actuelle.
TFS 2017 a amélioré sa mise en œuvre de la demande de pull. Désormais, le développeur peut demander que la demande Pull soit fusionnée automatiquement si toutes les conditions sont remplies (pas de conflit de fusion, approbation des réviseurs et pas de build cassé). YMMV.
la source
De cette façon, l'auteur a la possibilité de changer d'avis sur sa branche, peut-être qu'il a compris quelque chose qui devrait être fait d'une manière différente, et a remis les frais supplémentaires à l'examen.
la source