Skip to content

Políticas de Merge Requests e Revisão de Código

Índice

Definições

  • Assignee: O autor da branch, no caso você.
  • Reviewer: Quem irá revisar conforme apontado no planejamento da sprint.

Template para MRs

  • Em cada projeto deverá conter na pasta .gitlab/merge_request_templates/ o template para MR sendo Default o modelo padrão adotado.
  • Cada projeto tem suas particularidades e pode ser necessário personalizar o template de MR para adequá-lo a esses aspectos únicos. No entanto, todas as personalizações devem seguir a estrutura geral e as diretrizes estabelecidas no template Default.
  • O template deverá está na branch master para que o Merge Request possa reconhecer o template.
  • Maiores detalhes sobre o funcionamento dos templates para o Gitlab podem ser encontrados aqui.

Referências para o modelo de MR

Boas práticas

  • Marque como draft os MRs que não estiverem prontos para revisão.
  • Durante o processo de criação de um MR, marque a opção de deletar a branch atual quando o merge for aceito.

Diretrizes para revisão de código

Ao revisar o código, avalie se:

  • A documentação é adequada e está presente.
  • Comentários e docstrings foram adicionados em funções grandes ou complexas.
  • Os comentários no código são relevantes e úteis.
  • Os testes automatizados foram implementados e estão corretos.
  • Foram incluídos e validados os testes de dados via Great-expectations.
  • O CI/CD dos testes executam sem erros.

Para as queries do SQL verifique as seguintes especificidades:

  • Avaliar a estilização das CTEs, se estão de acordo com o guia de estilo do DBT.
  • As queries SQL seguem boas práticas de escrita.
  • Verifique se as transformações de dados estão corretas e se fazem sentido.
  • Assegure-se de que as junções, filtros e agregações em SQL estão corretas.

Para threads abertas, seguir o padrão:

  • Threads abertas deverão ser fechadas por quem abriu, para que seja avaliado se satisfaz o que foi abordado na thread.
  • Somente poderão ser marcadas como aprovadas MRs que tiverem todas as threads fechadas por quem as abriu.
  • Somente poderão ser merged as MRs marcadas como aprovadas e tiverem todas as threads fechadas.

Ao fornecer feedback, seja construtivo e focado no código, e não no autor.

Integração Contínua (CI)

Verifique se o código:

  • Passa nos testes automatizados.
  • Atende aos requisitos de cobertura de testes.
  • Mantém ou melhora a qualidade do código.
  • É importante garantir na situação onde exista uma CI/CD de deploy que ele só seja incluido na execução da branch ao final de todas as modificações para garantir que não seja enviado nenhum commit que possa quebrar o projeto em produção.

Observe a particularidade dos testes automatizados no CI/CD, por exemplo projetos Kedro validam os testes do pytest e o uso do pre-commit. Ao abrir um MR, certifique-se de que seu código passa nos testes.