TOC

Análise de código com o SonarQube

Análise de código com o SonarQube

*1. Visão geral *

Neste artigo, veremos a análise estática do código-fonte em SonarQube - que é uma plataforma de código-fonte aberto para garantir a qualidade do código.

Vamos começar com uma pergunta central - por que analisar o código fonte em primeiro lugar? Simplificando, para garantir qualidade, confiabilidade e capacidade de manutenção ao longo da vida útil do projeto; uma base de código mal escrita é sempre mais cara de manter.

Tudo bem, agora vamos começar baixando a versão LTS mais recente do SonarQube da página de download e configurando nosso servidor local, conforme descrito neste https://docs.sonarqube. org/display/SONAR/Como começar + em + Dois + minutos [guia de início rápido].

===* 2. Analisando o código fonte *

Now that we’re logged in, we’re required to create a token by specifying a name – which can be our username or any other name of choice and click on the generate button.

Usaremos o token posteriormente no momento de analisar nossos projetos. Também precisamos selecionar o idioma principal (Java) e a tecnologia de construção do projeto (Maven).

Vamos definir o plugin no pom.xml:

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.sonarsource.scanner.maven</groupId>
                <artifactId>sonar-maven-plugin</artifactId>
                <version>3.4.0.905</version>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

A versão mais recente do plug-in está disponível https://search.maven.org/classic/#search%7Cgav%7C1%7Cg%3A%22org.sonarsource.scanner.maven%22%20AND%20a%3A%22sonar-maven -plugin% 22 [aqui]. Agora, precisamos executar este comando a partir da raiz do diretório do nosso projeto para varrê-lo:

mvn sonar:sonar -Dsonar.host.url=http://localhost:9000
  -Dsonar.login=the-generated-token

Precisamos substituir o token gerado pelo token de cima.

Especificamos a URL do host do servidor SonarQube e o login (token gerado) como parâmetros para o plug-in Maven.

Após a execução do comando, os resultados estarão disponíveis no painel Projetos - em http://localhost: 9000.

Existem outros parâmetros que podemos passar para o plug-in Maven ou até definir na interface da web; sonar.host . url, sonar.projectKey e sonar.sources são obrigatórios enquanto outros são opcionais.

Outros parâmetros de análise e seus valores padrão são aqui. Além disso, observe que cada plug-in de idioma possui regras para analisar o código-fonte compatível.

===* 3. Resultado da análise *

Agora que analisamos nosso primeiro projeto, podemos acessar a interface da web em http://localhost: 9000 e atualizar a página.

Lá, veremos o resumo do relatório:

link:/wp-content/uploads/2018/02/9029390_overview.jpg [imagem:/wp-content/uploads/2018/02/9029390_overview.jpg [imagem]]

Os problemas descobertos podem ser um erro, vulnerabilidade, cheiro de código, cobertura ou duplicação. Cada categoria tem um número correspondente de problemas ou um valor percentual.

Além disso, os problemas podem ter um dos cinco níveis de gravidade diferentes: blocker, crítico, principal, menor e info. Logo à frente do nome do projeto, há um ícone que exibe o status do Quality Gate - aprovado (verde) ou com falha (vermelho).

Clicar no nome do projeto nos levará a um painel dedicado, onde podemos explorar questões específicas do projeto em mais detalhes.

Podemos ver o código, a atividade e executar tarefas de administração no painel do projeto - cada um disponível em uma guia separada.

Embora exista uma guia Issues global, a guia Issues no painel do projeto exibe problemas específicos apenas para o projeto em questão:

link:/wp-content/uploads/2018/02/383732889_issues.jpg [imagem:/wp-content/uploads/2018/02/383732889_issues.jpg [imagem]]

A guia de problemas sempre exibe a categoria, o nível de gravidade, as tags e o esforço calculado (em relação ao tempo) necessário para corrigir um problema.

Na guia problemas, é possível atribuir um problema a outro usuário, comentar sobre ele e alterar seu nível de gravidade. Clicar no problema em si mostrará mais detalhes sobre o problema.

A guia de problemas vem com filtros sofisticados à esquerda. Estes são bons para identificar problemas. Então, como saber se a base de código é saudável o suficiente para a implantação na produção? É para isso que serve o Quality Gate.

===* 4. Portão de qualidade do SonarQube *

Nesta seção, veremos um recurso importante do SonarQube - Quality Gate. Em seguida, veremos um exemplo de como configurar um personalizado.

====* 4.1 O que é um Quality Gate? *

Um Quality Gate é um conjunto de condições que o projeto deve atender antes de se qualificar para a liberação da produção.* Responde a uma pergunta: posso enviar meu código para produção em seu estado atual ou não? *

Garantir a qualidade do código "novo" e corrigir os existentes é uma boa maneira de manter uma boa base de código ao longo do tempo. [.hardreadability] O Quality Gate facilita a configuração de regras para validar todos os novos códigos adicionados à base de código em [. complexword] subsequente [. hardreadability] # análise #.

As condições definidas no Quality Gate ainda afetam segmentos de código não modificados. Se pudermos evitar que novos problemas surjam, com o tempo, [.complexword] # eliminamos # todos os problemas.

Essa abordagem é comparável a Fixando o vazamento de água da fonte.* Isso nos leva a um termo específico - Período de fuga. Este é o período entre duas análises/versões do projeto *.

Se executarmos novamente a análise, no mesmo projeto, a guia visão geral do painel do projeto mostrará resultados para o período de vazamento:

link:/wp-content/uploads/2018/02/36326789289_leak_period.jpg [imagem:/wp-content/uploads/2018/02/36326789289_leak_period.jpg [imagem]]

Na interface da web, a guia Portões da qualidade é onde podemos acessar todos os portões de qualidade definidos. Por padrão, o SonarQube way veio pré-instalado com o servidor.

A configuração padrão para SonarQube way sinaliza o código como falhado se:

  • a cobertura no novo código é inferior a 80%

  • porcentagem de linhas duplicadas no novo código é maior que 3 *classificação de manutenção, confiabilidade ou segurança é pior que A

Com esse entendimento, podemos criar um Quality Gate personalizado.

====* 4.2 Adicionando Custom Quality Gate *

Primeiro, precisamos* clicar na guia Quality Gates e depois clicar no botão Create * *, que fica à esquerda da página. Precisamos dar um nome a ele - __.

Agora podemos definir as condições que queremos:

link:/wp-content/uploads/2018/02/create-custom-gate-1.png [imagem:/wp-content/uploads/2018/02/create-custom-gate-1.png [imagem]]

*No menu suspenso _Add Condition_, vamos escolher* _ *Blocker Issues* ; _ ele aparecerá imediatamente na lista de condições.

Vamos especificar é maior que como Operator, _ defina zero (0) para a coluna _Error e verifique a coluna Over Leak Period:

link:/wp-content/uploads/2018/02/create-custom-gate-2.png [imagem:/wp-content/uploads/2018/02/create-custom-gate-2.png [imagem]]

*Em seguida, clique no botão _Add_ para efetuar as alterações* . Vamos adicionar outra condição seguindo o mesmo procedimento acima.

Selecionaremos os itens no menu suspenso Adicionar condição _ e verificaremos a coluna _Over Leak Period.

O valor da coluna Operator será definido como "é menor que" _ e adicionaremos um (1) como valor para a coluna _Error. Isso significa se o número de problemas no novo código adicionado for menor que 1, marque o Quality Gate como com falha.

Eu sei que isso não faz sentido técnico, mas vamos usá-lo para fins de aprendizado. Não se esqueça de clicar no botão Add para salvar a regra.

*Uma etapa final, precisamos anexar um projeto ao nosso Quality Gate personalizado. Podemos fazer isso rolando a página para a seção Projetos.*

Lá, precisamos clicar em Tudo e marcar o nosso projeto de escolha. Também podemos configurá-lo como o Quality Gate padrão no canto superior direito da página.

Analisaremos o código-fonte do projeto novamente, como fizemos anteriormente com o comando Maven. Quando isso for feito, iremos para a guia Projetos e atualizaremos.

Desta vez, o projeto não atenderá aos critérios do Quality Gate e falhará. Why? Como em uma de nossas regras, especificamos isso, ela deverá falhar se não houver novos problemas.

Vamos voltar à guia Quality Gates e alterar a condição de issues para is maior que. Precisamos clicar no botão de atualização para efetuar essa alteração.

Uma nova varredura do código-fonte passará desta vez.

*5. Integrando o SonarQube em um IC *

É possível tornar o SonarQube parte de um processo de Integração Contínua. Isso falhará automaticamente na construção se a análise de código não atender à condição do Quality Gate.

Para conseguirmos isso, usaremos SonarCloud, que é a versão hospedada na nuvem do servidor SonaQube. Podemos criar uma conta aqui.

Em Minha conta> Organizações, podemos ver a chave da organização, que geralmente estará no formato xxxx-github ou xxxx-bitbucket.

Também em My Account> Security, podemos gerar um token como fizemos na instância local do servidor. Anote o token e a chave da organização para uso posterior.

Neste artigo, usaremos o Travis CI e criaremos uma conta here com um perfil existente do Github. Ele carregará todos os nossos projetos e podemos ativar qualquer um para ativar o Travis CI nele.

Precisamos adicionar o token que geramos no SonarCloud às variáveis ​​de ambiente do Travis. Podemos fazer isso clicando no projeto que ativamos para o IC.

Em seguida, clique em "Mais opções"> "Configurações" e role para baixo até "Variáveis ​​de ambiente":

link:/wp-content/uploads/2018/02/travis-ci-1.png [imagem:/wp-content/uploads/2018/02/travis-ci-1.png [imagem]]

Adicionaremos uma nova entrada com o nome SONAR_TOKEN e usaremos o token gerado, no SonarCloud, como valor. O Travis CI criptografará e ocultará da exibição pública:

link:/wp-content/uploads/2018/02/travis-ci-2.png [imagem:/wp-content/uploads/2018/02/travis-ci-2.png [imagem]]

Por fim, precisamos adicionar um arquivo .travis.yml à raiz do nosso projeto com o seguinte conteúdo:

language: java
sudo: false
install: true
addons:
  sonarcloud:
    organization: "your_organization_key"
    token:
      secure: "$SONAR_TOKEN"
jdk:
  - oraclejdk8
script:
  - mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar
cache:
  directories:
    - '$HOME/.m2/repository'
    - '$HOME/.sonar/cache'

Lembre-se de substituir a chave da organização pela chave descrita acima. Confirmar o novo código e enviar para o repositório do Github acionará a criação do Travis CI e, por sua vez, ativará a verificação do sonar.

===* 6. Conclusão*

Neste tutorial, vimos como configurar um servidor SonarQube localmente e como usar o Quality Gate para definir os critérios para a adequação de um projeto à liberação de produção.

O documentation do SonarQube possui mais informações sobre outros aspectos da plataforma.

Related