Fluxo de trabalho de revisão de código em que o autor da solicitação pull deve mesclar

16

Várias equipes da minha empresa praticam um fluxo de trabalho de revisão de código que nunca vi antes. Estou tentando entender o pensamento por trás disso, com a ideia de que há valor em tornar a empresa inteira consistente. (Eu contribuo com várias bases de código e fui enganado pelas diferenças do passado.)

O autor do código envia uma solicitação de recebimento
O revisor examina o código
- Se o revisor aprovar, ele deixa um comentário como "Parece bom, fique à vontade para mesclar"
- Se o revisor tiver alguma dúvida, deixe um comentário como "Corrija os problemas menores X e Y e depois mescle" (Para alterações importantes, retorne à etapa 2)
O autor do código faz alterações, se necessário, e mescla sua própria solicitação de recebimento

Tenho as seguintes preocupações:

No caso de aprovação na etapa 3, esse fluxo de trabalho cria uma ida e volta aparentemente desnecessária para o autor da solicitação de recebimento. O revisor, que já está vendo o código, pode mesclá-lo imediatamente.
No caso de alterações serem solicitadas na etapa 3, a agência para mesclar a solicitação pull agora fica apenas com o autor do PR. Ninguém além do autor analisará as alterações antes da fusão.

Quais são algumas outras vantagens ou desvantagens desse fluxo de trabalho? Esse fluxo de trabalho é comum em outras equipes de engenharia?

code-reviews pull-requests

— aednichols
fonte

5

Você já perguntou às pessoas da sua organização por que elas escolheram esse fluxo de trabalho específico? Eles provavelmente estão em uma posição melhor para iluminar os méritos relevantes do que nós. Nós estaríamos apenas especulando.

— Robert Harvey

1

O que acontece na sua organização quando o revisor escreve "Corrija o problema principal X"?

— Doc Brown

8

Na minha experiência, é melhor que o autor original seja o responsável pela mesclagem, caso haja um conflito de mesclagem a ser resolvido. O autor original geralmente é aquele que está melhor equipado para descobrir como resolver um conflito de mesclagem.

— 17 de 26

Eu ficaria curioso quanto à lógica aqui. Você deve perguntar a seus colegas e escrever como uma resposta automática - pode haver um processo de pensamento muito bom ou justificativa aqui. Só não consigo pensar em um rapidamente.

— Thomas Owens

21

No primeiro caso, geralmente é uma cortesia. Na maioria das organizações, as fusões iniciam uma série de testes automatizados que devem ser tratados imediatamente se falharem. Especialmente se houver um atraso significativo entre quando uma solicitação de recebimento foi enviada e quando foi revisada, é educado permitir que ela seja mesclada no cronograma do autor, para que eles tenham tempo para lidar com qualquer precipitação inesperada. A maneira mais fácil de fazer isso é deixá-los fundir eles mesmos.

Além disso, algumas vezes o autor toma conhecimento dos motivos mais tarde para que uma solicitação de recebimento ainda não deva ser mesclada. Talvez o PR de outro desenvolvedor seja uma prioridade mais alta e cause conflitos. Talvez ela tenha pensado em um caso de uso descoberto. Talvez um comentário de revisão tenha desencadeado um brainstorm que precisa de mais investigação antes que o problema seja totalmente satisfeito. O autor sabe o máximo sobre o código e faz sentido dar a última palavra sobre quando ele é mesclado.

No segundo ponto, isso é apenas uma questão de confiança. Se você não pode confiar nas pessoas para corrigir pequenos problemas sem ser verificado duas vezes, elas não devem estar funcionando para você. Se o problema for grande o suficiente para precisar de outra revisão após a correção, confie nos revisores para solicitar uma.

Dito isto, ocasionalmente mesclo solicitações de recebimento de outros autores, mas geralmente são alterações muito simples ou de fontes externas, nas quais eu pessoalmente assumo a responsabilidade de pastorear qualquer falha de automação de teste.

— Karl Bielefeldt
fonte

2

Parece que há mais variedade do que eu imaginava. Minha experiência com testes automatizados é que os testes são executados na ramificação antes da fusão, e não depois, tornando-se uma condição prévia para a mesclagem. Também vi correções "menores" não revisadas, incluindo as minhas, que causam bugs.

— aednichols

2

Os testes geralmente são executados como uma pós-condição e também como uma pré-condição. É completamente possível que mudanças de várias ramificações entrem em conflito de maneiras não óbvias que não apareciam como um conflito de código e causavam falhas nos testes. No meu local de trabalho, exigimos que uma filial esteja atualizada com a filial base, bem como todos os testes aprovados antes de ser candidato à mesclagem e mesclagem, que ocorrem automaticamente se essas duas condições forem atendidas. Nem sempre tivemos essa primeira condição - antes disso, na verdade, tínhamos problemas introduzidos para dominar com pouca freqüência, apesar de cada ramo ter passado individualmente

— Matthew Scharley 24/16

3

Ter o autor inicial mesclando sua própria solicitação de recebimento é o meu fluxo de trabalho preferido em equipes pequenas. Além das vantagens técnicas já mencionadas (em termos de resolução de conflitos de mesclagem, por exemplo), acho que agrega valor em nível cultural: constrói um senso de propriedade.

Especifiquei o autor inicial para o caso (raro) em que outro desenvolvedor adicionaria confirmações à solicitação de recebimento aberto (puxando o ramo do recurso de trabalho em andamento e retornando a ele). Isso não acontece com frequência e resultaria de uma conversa pessoalmente ou por meio do Slack: Esses commits adicionais (por outra pessoa) não devem chegar lá de surpresa! Nesse contexto, por autor inicial , quero dizer quem enviou a solicitação de recebimento.

— mkcor
fonte

2

Na minha organização, somos bastante novos em solicitações pull e sua pergunta é uma que eu me questionei.

Uma observação que eu gostaria de acrescentar: Em algumas ferramentas (usamos o TFS), pode haver um item de trabalho associado à solicitação de recebimento.

Se for esse o caso, torna-se um pouco complicado acompanhar quando o revisor executou a mesclagem. Nesse cenário, o desenvolvedor precisa revisitar o PR, abrir o bug ou a solicitação de alteração e marcá-lo como 'resolvido'. Se a marcarmos como 'resolvida' muito cedo, os testadores acreditarão que a correção já faz parte da compilação atual.

O TFS 2017 melhorou a implementação da solicitação pull. Agora, o desenvolvedor pode solicitar que a solicitação de solicitação seja mesclada automaticamente se todas as condições forem atendidas (sem conflito de mesclagem, aprovação dos revisores e nenhuma compilação quebrada). YMMV.

— 9Rune5
fonte

1

Dessa forma, o autor tem a chance de mudar de idéia sobre seu ramo, talvez ele tenha descoberto algo que deve ser feito de uma maneira diferente e colocado os custos adicionais de volta para revisão.

— gnasher729
fonte