Processo de review

Após realizado as alterações, deve ser criado um merge request no servidor git, para que seja realizado o review das alterações. O processo de review é realizado pelos membros do seu time que interagem com a mesma tecnologia. Por exemplo, em uma alteração no backend, deve ser realizado o review por membros do time que trabalhem com backend.

Durante o review, pode ser encontrado correções para serem realizadas no código, que devem ser feitas criando novos commits na branch, que devem corrigir os problemas encontrados nas alterações de um commit original criado na branch. Estes commits de correção depois serão juntados com o commit original, então devem ser utilizadas descrições claras. Durante o review, também deve ser identificado se os commits estão dentro do Padrões de nomes/descrição, caso contrário devem também devem ser ajustados.

Quanto a peridiocidade de review, será adotado o seguinte critério:

• Para reviews urgentes o review deve ser feito na hora
• Para reviews normais deve-se tentar fazer nos seguintes períodos 08:15 , 11:15 e 16:00 para que de tempo de fazer as correções necessárias, caso houver, e fazer o merge no mesmo dia.

Para iniciar um review, deve ser adicionado as labels de backend e/ou frontend, dependendo de que tipo de código foi alterado no MR, e a label review / start, que diz para o bot de reviews que o MR entrou em review. O bot então vai alocar as pessoas de forma randômica para fazer os reviews e vai enviar mensagens de review nos horários definidos. Caso seja um review urgente, pode ser adicionado a label urgent, que faz o bot enviar imediatamente as notificações para as pessoas alocadas para fazer review.

Além disso, o autor do MR recebe uma notificação quando seu merge request receber um status de fix (label status / fix), e quando a label status / fix for removida os reviewers recebem uma notificação que o MR foi corrigido, para fazer review novamente. Quando os reviewers finalizarem os reviews, o bot vai adicionar a label status / reviewed se já não tiver sido adicionada e enviar uma mensagem para o autor do MR que o review foi concluido.

Após realizado o review, deve ser realizado um rebase iterativo para limpar o histórico de commits, juntando commits de correção de commits com os seus originais. Isto pode ser feito utilizando o comando git rebase -i master ou GIT_EDITOR="code -w" git rebase -i master, que abre um editor vim/code com a lista de commits do branch. Seguindo da ordem de cima para baixo, os commits aparecem na lista do mais antigo para o mais novo.

Para juntar um commit com o seu original, deve ser reordenado os commits colocando os commits de correção após o seu commit original, marcado os commits de correção com a marca squash, que irá juntar os commits com o commit anterior na sequência, que deve ser o commit original.

Este processo é realizado para manter o histórico do git limpo e fácil de trabalhar, evitando manter os commits de correções realizados durante o processo de desenvolvimento/review de uma funcionalidade/correção.

Após finalizar as atividades do ticket o merge request principal deve ser mergeado na master com um commit de squash com a mensagem contendo a descrição do ticket. Se houver alguma alteração de generalização, como componentes, libs, etc, deve-se fazer o squash manual dos commits juntando separando os commits da generalização dos commits da atividade. Isso deve ser feito pois se houve a necessidade de reverter o commit reverter apenas o que for necessário.

Lembre-se, que antes de uma feature, RFC, etc, ser mergeada deve passar pela etapa de teste integrado do front e back para garantir que tudo esteja funcionando.

Review de código (processo e aplicação)

O nosso processo de review se inicia após o término do desenvolvimento e abertura do merge request. Com o MR criado, precisamos adicionar as labels expecíficas para orientar nosso bot a designar as pessoas corretas sobre a review e notificá-las. Para isso, na criação do MR ou após criado, devem ser selecionadas as labels referente á área do review (backend, frontend, docs) e a label review/start, essas duas são necessárias para dar início ao processo de review. Para acrescentar mais informações, podemos incluir também a label informando o tipo do ticket, kind/feature, kind/rfc, kind/bug, entre outros.

Após isso, o bot automaticamente seleciona duas pessoas disponíveis para fazer a review do código.

E nos horários programados de notificação ele irá mandar uma mensagem em seu chat. Obs: Olhar a documentação do bot.

Realizando o review

Após você ser designado para o review, existem certos “passos” para você seguir, para realizar um bom review.

Pipeline

O primeiro passo é sempre analisar o status do pipeline. O pipeline é um linha de processos que garante a consistência do código em relação a master, executando testes das docs, front e back, construção de pacotes, imagens docks entre outras tarefas. Sempre devemos verificar se o pipeline está quebrado ou não.

Quando isso ocorre, simplesmente vamos na área de comentários do MR e informamos que o pipeline está quebrado em forma de thread, junto da adição da label status/fix.

Commits

Verificar se as mensagens de commits estão dentro do nosso padrão de nomenclaturas.

Quando existe algum commit fora dos padrões, simplesmente vamos na área de comentários do MR e informamos para revisar a nomenclatura dos commits, junto da adição da label status/fix.

Código

Está é a parte mais importante do review, nele devemos analisar se existem erros de sintaxe, lógicas que parecem não fazer sentido ou até mesmo oferecer sugestões de melhoria no código alterado, visando facilitar a leitura, manutenção ou uso de algo mais simples e pŕatico.

Sempre que identificamos algo no código para ser corrigido, o que devemos fazer é, ir na linha que iremos comentar sobre a alteração, e clicar no botão de mensagem, isso irá fazer uma caixa de comentários onde podemos escrever o que está de errado ou a melhoria, ou ir além, inserir pedaços de código para auxiliar.

Ao finalizar seus comentários, basta você adicionar a label status/fix e seu processo de review está finalizado por hora, pois quando as alterações forem realizadas, você deve repetir essas três etapas novamente.

Como a qualidade do review do código é inversamente proporcional a quantidade de alterações no MR, sabemos que nem sempre conseguiremos captar todos os problemas numa única review, por isso, sempre que seu colega de equipe ajustar as correções e colocar seu código para review novamente, realize um review do MR inteiro, assim você evita que algo passe despercebido.

Label

Sempre que um MR receber uma label de status, uma mensagem diferente será enviada para você pelo bot. Porém as duas únicas instantâneas são de status/fix e quando os reviewers removem suas labels, na qual o bot adiciona a label status/reviewed.