5 Elementos para um Pull Request perfeito

Graças à expansão de sistemas de controle de versão distribuídos (DVCS), como o Git, o processo de feedback melhorou enormemente. A habilidade do Git de se ramificar e se mesclar facilmente possibilitou revisar pequenos conjuntos de alterações com mais frequência. Este tipo de revisão de código é baseado em um conceito conhecido como “pull requests”. Os pull requests fornecem uma espécie de fórum para discutir alterações propostas na base de código antes de serem incorporadas em ramificações compartilhadas (por exemplo, antes de mesclar uma ramificação de recursos com uma master).

A popularidade do Git e do pull request têm crescido exponencialmente sem sinais de desaceleração. Os benefícios da revisão por pares (ou “peer review”) – código de maior qualidade, conhecimento e senso de propriedade compartilhado entre equipes – e fluxos de trabalho flexíveis no Git atraíram equipes de todos os tamanhos.

Com a velocidade de desenvolvimento e a qualidade do código em jogo, não chega a ser uma surpresa que pull requests tenham se tornado um argumento de venda fundamental para as ferramentas de gerenciamento Git. Claro, outros fatores também entram no jogo, como a segurança, a escalabilidade e a flexibilidade de deploy, mas quando se trata de produtividade do desenvolvedor é a experiência em pull request que dá o tom, para além de outras ferramentas importantes. A experiência em pull request é o fator decisório mais importante ao selecionar uma solução de controle de versão. Afinal, eles são a melhor maneira de garantir que a liberação de código de alta qualidade.

Os pull requests funcionam melhor quando 5 peças-chave deste recurso estão a pleno vapor. Vamos analisá-los com base na solução Bitbucket Server:

 

#1. Revisores destacados

Na sua forma mais básica, os pull requests são simplesmente uma solicitação para mesclar mudanças em um ramo ou fork de destino. Uma vez que apresentamos a ideia de adicionar revisores, eles se tornam muito mais do que isso: um verdadeiro fórum para uma discussão aberta em torno do código produzido. Quando buscamos uma ferramenta para gerenciar repositórios Git, a capacidade de adicionar explicitamente os membros da sua equipe como revisores é a base para um bom fluxo de trabalho de revisão. De que outra forma sua equipe saberá que precisa revisar suas alterações?

 

#2 Comentários em TODAS AS COISAS

O quão bom seria uma revisão de código sem os comentários que a acompanham? Capturar o feedback no contexto dá aos autores do pull request um ponto de referência para melhorias. Os revisores podem fazer sugestões de alterações ou felicitar um membro da equipe por uma lógica brilhante. No Bitbucket Server, o usuário tem a opção de deixar todos os tipos de comentários: em todo o pull request, commit por commit, em um arquivo específico ou em linhas específicas de código em um arquivo.

Dica: Precisa de uma segunda opinião sobre uma seção específica de código? No Bitbucket Server, o usuário pode se valer de um @mention em uma linha específica para comunicar-se com um especialista – por exemplo, um front-end ‘ninja’, um engenheiro de performance, um especialista em segurança etc – para analisar um trecho do código em particular, sem vinculá-los com a revisão completa do material.

 

#3. Revisão iterativa

Os pull requests criam um loop de feedbacks – você escreve algum código, sua equipe o revisa, você incorpora alterações, sua equipe as revisa e aprova, você faz o merge e conclui a tarefa. Se a sua ferramenta de gerenciamento Git não fornece um mecanismo para capturar o status do revisor ou rever as iterações, como fará para acompanhá-los?

No Bitbucket Server, resolvemos esse problema fornecendo botões de status para revisores (ou seja, se o autor precisa fazer alterações, você pode clicar em “Needs Work”). Uma vez que as alterações foram incorporadas, os revisores podem encontrar facilmente o que há de novo através de revisão iterativa, um mecanismo que permite restringir o diferencial somente para as novas alterações desde a última revisão. Não há necessidade de procurar arquivos por alterações ou revisar o código antigo. Se a sua equipe se preocupa em ocupar o tempo com sabedoria, a revisão iterativa é uma ferramenta essencial.

 

#4. Flexibilidade do fluxo de trabalho

A criação de um fluxo de trabalho de desenvolvimento envolve muitos fatores. Por exemplo: você trabalha em uma indústria altamente regulamentada? Quem deveria ter acesso à sua base de código? Que tipos de verificações de qualidade você precisa? E a lista é longa. Por isso a flexibilidade do fluxo de trabalho é tão importante: não há duas equipes de desenvolvimento exatamente iguais.

O Bitbucket Server oferece a liberdade de escolher como um pull request é mesclado (as estratégias de merge disponíveis incluem merge commit, fast forward only, e squash) e quando passa pelo merge com as verificações de merge (por exemplo, só permite o merge se houver 2 aprovações e um build). Nenhuma outra ferramenta Git possui a flexibilidade encontrada no Bitbucket Server.

 

#5. Integrações

Finalmente, antes de comprar uma nova ferramenta de gerenciamento Git, considere como ela irá se encaixar no restante da sua cadeia de ferramentas. O desenvolvimento é muito mais divertido quando não há a necessidade de ficar saltando entre ferramentas para informar sobre o status do pull request. Com os smart commits, a capacidade de fazer a transição do JIRA através de mensagens de commit, o Bitbucket Server lida com a sobrecarga para o usuário.

Usando outras ferramentas? A Atlassian fornece um marketplace repleto de integrações e recursos adicionais através de add-ons. Por que se conformar com uma ferramenta que “serve para tudo” quando se pode combinar o poder das melhores ferramentas que funcionam para cada finalidade?
 
 
Fonte: DZone.com

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.