Quanta história de análise estática uma empresa deve manter?

5

Suponhamos que você trabalhe em uma empresa global muito grande com muitos códigos em todos os níveis (por exemplo, de código de aplicativo embarcado para plataforma móvel), e os projetos podem durar entre 6 meses a 5 anos ...

Qual seria a melhor prática em termos de manter informações de análise estática? , assumindo que a rastreabilidade entre defeitos e avisos estáticos é importante para a organização (por exemplo, aeroespacial, automotivo, governamental, etc.) / p>     

por dukeofgaming 28.01.2016 / 19:52
fonte

2 respostas

3

Não acredito que você precise manter muitas informações de análise estática, se houver alguma. No entanto, para suportar isso, você precisa de boas práticas de gerenciamento de configuração.

Primeiro, você deve marcar o código regularmente em seu repositório de código-fonte. Considere a marcação ( git , Subversion , ClearCase - a maioria dos sistemas de controle de versão deve suportar funcionalidade semelhante) qualquer construção que você faça. Marcando compilações cruciais com um identificador exclusivo (como um número de compilação ou registro de data e hora), você pode relacionar itens como um instantâneo específico do código-fonte a entradas em um banco de dados de rastreamento de defeitos ou resultados de análise estática.

Agora que você tem tags, é possível mapear resultados de análises estáticas para repositórios de código-fonte específicos. É geralmente aceito que você não deve manter o código gerado no controle de versão. Eu diria que você não deve manter nada que possa ser gerado diretamente a partir do código-fonte, o que inclui a análise estática. No entanto, para fins de rastreabilidade, você precisará poder associar os defeitos derivados da análise estática à compilação que causou a descoberta.

Realisticamente, você pode querer manter alguns resultados da análise estática. Por exemplo, os resultados da análise antes de um lançamento externo podem ser incluídos como parte de um relatório de teste formal. Mesmo que não faça parte de um relatório de teste, você pode querer mantê-lo em um arquivo de projeto. Você também pode considerar incluir um resumo de análise estática (como número de descobertas, número de descobertas por linha de código-fonte, número de descobertas por módulo, número de descobertas por criticalidade ou número de descobertas por tipo).

Você também pode considerar como gerenciar sua ferramenta de análise estática, especialmente se estiver usando-a como parte de algum tipo de teste ou relatório formal. Você precisa considerar a versão da ferramenta, bem como o arquivo de configuração ou os parâmetros usados ao executar a ferramenta em uma determinada versão da base de código. Se você não gerenciar a versão e a configuração da ferramenta, será mais difícil gerar o mesmo relatório exato para uma determinada base de código.

    
por 16.03.2016 / 00:56
fonte
1

Acho que manter os resultados da análise estática é uma prática muito boa. Eu não estaria necessariamente tão interessado em "qual build introduziu este aviso", porque isso deve ser relativamente fácil de ver a partir do seu sistema de controle de versão. Além disso, se você estiver interessado em rastrear o histórico de um determinado aviso de análise estática, provavelmente já fez algo errado ao não corrigir esse aviso quando apareceu em primeiro lugar.

A principal razão pela qual gosto das histórias de resultados de análises estáticas é que me permite ver tendências. Por exemplo, posso ver a quantidade de linhas de código, o número de problemas e as métricas de cobertura de código. Problemas, por exemplo, devem estar em um relacionamento linear com as linhas de código. Se o número de problemas crescer mais rápido que as linhas de código, provavelmente alguém está fazendo algo errado. Da mesma forma, ajuda a estabelecer uma linha de base da cobertura de teste desejada, e você pode ver se ela começa a afundar, se alguém esquecer de criar testes.

Quanto à sua pergunta atual sobre por quanto tempo manter as informações da análise estática. Eu diria que você deve mantê-lo desde o início do projeto, mas você não precisa manter tudo isso . O SonarQube, por exemplo, que seria a minha arma preferida, remove automaticamente alguns dos seus instantâneos antigos. (Uma captura instantânea é um conjunto de resultados de análise estática em uma determinada compilação.) As regras padrão são descritas em link e a parte mais relevante é esta:

  • only one snapshot per day is kept after 1 day. Snapshots marked by an event are not deleted.
  • only one snapshot per week is kept after 1 month. Snapshots marked by an event are not deleted.
  • only one snapshot per month is kept after 1 year. Snapshots marked by an event are not deleted.
  • all snapshots older than 5 years are deleted, including snapshots marked by an event.

Assim, para o dia atual, você visualiza todas as análises, mas, amanhã, somente a última análise do dia anterior está disponível e as outras foram excluídas. No final de abril, todos, exceto a última análise de março, são excluídos. Etc. Então, vá para uma resolução diferente para diferentes períodos de tempo. Isso permite que você salve com eficiência vários anos de dados.

    
por 15.04.2016 / 16:01
fonte