Documentação da revisão de código

5

Em um projeto, temos uma revisão de código bastante formal, que é feita manualmente e documentada em planilhas do Excel e documentos do Word.

Gostaríamos de melhorar o atual processo de revisão de código, integrando-o em um fluxo de trabalho Git (utilizando ferramentas como Bitbucket Server, que já temos, Gerrit, etc.).

A ideia atual é que cada desenvolvedor implementa recursos e correções de bugs e cria uma solicitação pull. Essa solicitação pull é revisada por outros desenvolvedores e, em seguida, mesclada em nossa ramificação de desenvolvimento principal ou não.

Gostaríamos de exportar todas as solicitações pull (que agora são as revisões de código) para documentá-las formalmente em um documento off-line. Este documento de revisão de código é um item de entrega para nosso cliente.

Esta é uma abordagem viável?

    
por Simon 11.01.2016 / 12:22
fonte

2 respostas

1

Você pode dar uma olhada em Phabricator . É um ótimo aplicativo de gerenciamento de projetos de software que lida com revisões de código semelhantes ao que você descreveu e faz muito mais em torno do desenvolvimento de software.

Eu não quero recomendar uma ferramenta para você, mas quero mostrar a você a ideia que eles têm sobre revisões de código, que considero sólida e viável.

Todo o processo de desenvolvimento dentro do Phabricator é documentado, não apenas as revisões de código, porque conecta todas as informações usando identificadores que são traduzidos automaticamente em links e produzem referências com datas, horas e usuários envolvidos em ações.

Aqui está o que é uma revisão de código no Phabricator (para abordar sua pergunta mais especificamente):

  1. O desenvolvedor cria uma nova ramificação no repositório git local e faz um commit com suas alterações.
  2. O desenvolvedor inicia arc diff para lint e testar as alterações e para criar uma revisão de código (chamada de "diferencial"). Alguns metadados podem ser adicionados neste momento.
  3. O Phabricator recebe o diferencial e o disponibiliza para outros desenvolvedores neste projeto.
  4. Outros desenvolvedores podem comentar o conjunto de alterações e anotá-lo. O autor pode atualizar o diferencial.
  5. Os revisores podem aceitar ou rejeitar o diferencial.
  6. O autor pode abandonar o diferencial ou confirmá-lo ( arc land ).
  7. O repositório recebe o commit e o liga automaticamente com o diferencial. E o diferencial também está conectado com o commit e / ou as ações que levam ao resultado.
O phabricator é desenvolvido muito rapidamente e é desenvolvido em uma instância pública do Phabricator.

    
por 02.09.2016 / 21:18
fonte
1

O Bitbucket Server certamente pode fazer isso, ele tem APIs REST para extrair dados de solicitação pull). Se você quiser algo mais específico incluído no produto, o SDK do plug-in está disponível para gerar documentos automaticamente.

Como outros sugeriram, esse pode ser um bom momento para analisar o que seus clientes precisam (ou acham que precisam) e quais outras maneiras que podem ser capturadas e entregues. Pode ser que você já esteja procurando a melhor opção disponível, mas pode haver alternativas mais simples que economizam tempo e dinheiro.

Divulgação: Eu trabalho para a Atlassian

    
por 07.09.2016 / 01:10
fonte