Qualidade SRE

Clara Érica T. de Castro

2022
 Qualidade SRE
Clara Érica T. de Castro
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.

2
Sumário

Capítulo 1. SonarQube como aliado da Observabilidade ..........................................5

1.1. Ferramentas e práticas DevOps 5

1.2. Diferença entre análise estática e dinâmica 7

1.3. CI/CD Pipelines 10

1.4. Continuous Delivery x Continuous Deployment 11

1.5. O que é Qualidade Contínua 13

1.6. Desafios da Qualidade Contínua 13

1.7. Importância do Shift Left 14

Capítulo 2. Instalação e Configuração ......................................................................17

2.1. Instalar SonarQube 18

2.2. Instalar Java 24

2.2. Instalar SonarScanner 34

2.3. Subir instância do servidor 37

Capítulo 3. Avaliação de Resultados ........................................................................41

3.1. Introdução ao SonarQube 41

3.2. Visão geral das funcionalidades 42

3.3. Tipologia dos problemas 46

3.4. Dívida técnica 49

3.5. Definições de métricas 50

3
Capítulo 4. O que são Quality Gates ........................................................................53

4.1. Quality Gates 53

4.2. Quality Profiles 55

4.3. Estratégias de implementação 56

4.4. Cuidados gerais 57

Referências………………......................................................................................................58

4
Capítulo 1. SonarQube como aliado da Observabilidade

1.1. Ferramentas e práticas DevOps

A Observabilidade é um dos 5 pilares das práticas SRE (Site Reliability Engineer),

traduzindo, é o Engenheiro de Confiabilidade de Sites. E conhecer as práticas de DevOps,
bem como o ciclo de desenvolvimento, possibilitará ao SRE trazer o equilíbrio de manter
a confiabilidade de sites e aplicações, e a liberação de novas funcionalidades.

Segundo a Harrison Clarke (empresa que conecta talentos DevOps/SRE com

organizações líderes dos Estados Unidos), dentre as habilidades técnicas que as
empresas de tecnologia buscam em profissionais de DevOps e SRE estão a experiência
com ferramentas de DevOps através de todos os seus aspectos: “controle de fonte,
integração contínua, gestão da configuração, automação de implantação, ...”, bem
como “habilidades de segurança de software”, entre outros atributos.

5
 Fonte: Figura 1 e e-book disponível para download em:
<https://www.harrisonclarke.com/what-emerging-tech-companies-are-looking-for-in-
devops-roles>.

Desta maneira, conhecer o ciclo de vida do desenvolvimento de software (do

inglês SDLC – Software Development Life Cycle) e suas ferramentas se torna crucial para
se tornar um SRE diferenciado. O SDLC é o conjunto de fases e procedimentos pelo qual
um software passa, desde seus requerimentos até sua implantação e manutenção.

Enquanto Observabilidade para SRE é mais comumente relacionada à Shift

Right (monitorar, observar, analisar dados em produção), o Shift Left foca em identificar
os problemas o quanto antes dentro do SDLC, ou seja, mais próximo do desenvolvedor.
E, por isso, a ferramenta SonarQube se torna um aliado da Observabilidade sob a ótica
de se antecipar aos problemas e resolvê-los antes que ocorram no ambiente de
produção. Segundo a documentação da ferramenta: ela faz uma revisão automática de
código para detectar bugs, vulnerabilidades e code smells em seu código. Ela pode
integrar-se com seu workflow existente para possibilitar a inspeção contínua do código
através das branches de seu projeto e pull requests.

Fonte: <https://docs.sonarqube.org/latest/>.

6
 Ela disponibiliza indicadores da qualidade e segurança do código, detalhando a
gravidade de cada tipo de erro identificado, índices de manutenibilidade, confiabilidade
e segurança, suportando mais de 15 linguagens em sua versão gratuita e 29 linguagens
em sua versão Enterprise (consulta realizada no site em Fevereiro/2022).

E ao ser integrada de forma automática em uma esteira (pipeline) de entrega

contínua de software, os ganhos são potencializados, por proporcionar um feedback
rápido e antecipado para correção do código antes de sua integração com outros
programas e serviços.

Normalmente é utilizada no início do pipeline (CI – continuous integration), para

garantir o Shift Left, antes de efetuar o deploy do software no ambiente de
desenvolvimento. Isto impede que o software que esteja fora dos padrões definidos pela
organização impacte o ambiente, já em seu estágio inicial. Mas há empresas que optam
por executar antes da entrada no ambiente de homologação, ou ainda, executam duas
vezes: antes do desenvolvimento e antes da homologação.

Há várias ferramentas que podem ajudar a avaliar a qualidade e segurança do

código de forma automática dentro de um pipeline. Neste módulo focaremos no
SonarQube por sua versatilidade de integração com várias outras ferramentas, e por
trazer grande benefício para uma abordagem DevOps.

Não será abordada a análise dinâmica, porém, é importante saber a diferença.

1.2. Diferença entre análise estática e dinâmica

Análise estática

É um tipo de análise onde o código é testado para checar os defeitos do

software sem executar o código da aplicação, que possui como objetivo principal

7
prevenir que defeitos se propaguem para as próximas fases. Ela é executada nos
estágios iniciais do desenvolvimento a fim de evitar erros e solucioná-los mais
facilmente, sendo o local onde se deve encontrar a maioria dos erros.

É nessa fase que o SonarQube é utilizado, fazendo a inspeção do código todo,

sem executá-lo. Ele guarda a primeira versão como um baseline e da segunda execução
em diante é feito um comparativo entre o código da versão atual com o código da última
execução, gerando uma foto da saúde do código. E com base nessas informações, o
desenvolvedor terá condições de acompanhar e trabalhar o seu código para atender às
melhores práticas de mercado para codificação do software.

Importante destacar que este tipo de análise não substitui os testes funcionais
que devem ser realizados para garantir a qualidade do que foi desenvolvido.

Análise dinâmica

É um tipo de análise onde o código é executado para analisar o seu

comportamento dinâmico. Isto significa efetuar testes para analisar os valores de
entrada e os valores esperados de saída do software. O código deve estar implantado
no ambiente para que ele possa ser testado durante a sua execução.

Estático Dinâmico

Fonte: <https://enterfea.com/difference-between-static-and-dynamic-analysis/>.

8
 Diferença entre Teste Estático e Dinâmico.

Fonte: <https://www.geeksforgeeks.org/difference-between-static-and-dynamic-testing/>.

Versão traduzida:

9
1.3. CI/CD Pipelines

Segundo a Red Hat (2019):

Um pipeline de CI/CD é uma série de passos que devem ser executados

para entregar uma nova versão de software. E pipelines de integração
contínua / entrega contínua (CI/CD) são uma prática focada em
melhorar a entrega de software usando uma abordagem DevOps ou
de Engenharia de Confiabilidade de Site (SRE – Site Reliability
Engineering). (RED HAT, 2019)

Esta série de passos são potencializados com a utilização da automação para

que seja possível entregar o que foi desenvolvido com maior rapidez. Somada a essa
velocidade, necessitamos de monitoramento para assegurar que a entrega seja
realizada com confiança e que não haverá quebras no processo de desenvolvimento do
software.

Em se tratando de software, a entrega pode estar planejada com outro

conjunto de softwares, que juntos entregam o valor esperado pelo cliente. Se esse
conjunto de softwares, no todo ou em parte, apresentar alguma falha, toda a entrega
estará comprometida. Ter somente automação sem qualidade resultará em automação
de implantação de código mal escrito e erros indesejados.

A velocidade não pode estar acima da qualidade!

Elementos do CI/CD

Vamos ver a seguir os passos que ajudam a entender as delimitações de cada

fase da:

• Integração contínua (Continuous Integration);

10
 • Entrega contínua (Continuous Delivery);

• Implantação contínua (Continuous Deployment).

A integração contínua permite que os desenvolvedores integrem seu código ao

menos uma vez ao dia, por meio de builds automatizados, com os devidos testes para
detecção de problemas e possibilitando as correções o mais cedo possível.

Para que essa ação ocorra de maneira contínua e constante, é necessário que
as equipes sejam altamente colaborativas, os trabalhos sejam paralelizados por meio de
controle de versões, potencializando a velocidade de entrega e que haja a cultura de
automatizar tudo o que for possível, bem como haver o apoio da gestão para que o time
tenha tempo disponível para refatorar (reescrever) seu código constantemente e, assim,
reduzir a dívida técnica.

Em resumo, os pontos importantes da integração contínua são:

• Controle de versão de código;

• Build automatizado;

• Testes automatizados (o quanto possível);

• Cultura de colaboração;

• Tempo reservado para reduzir dívida técnica.

1.4. Continuous Delivery x Continuous Deployment

A imagem abaixo demonstra que para ser considerado um Continuous

Deployment (implantação contínua), o processo precisa estar totalmente automatizado.

11
E que o Continuous Delivery (entrega contínua) possui todos os passos automatizados,
com exceção da implantação no ambiente de Produção.

Nem sempre será permitida a implantação contínua, isto poderá depender das
definições da organização sobre quais softwares são elegíveis a uma automação de
ponta a ponta. Normalmente, são considerados itens como a complexidade e criticidade
da aplicação.

Fonte: Adaptada de <https://docs.microsoft.com/en-us/learn/modules/analyze-devops-

continuous-planning-intergration/3-analyze-continuous-integration>.

Temos o CI como parte comum das duas abordagens, garantindo que haja ciclos
pequenos de desenvolvimento, rápida detecção de falhas, menos problemas em
compilações, controle de versões, código seguro, build automatizado, dentre outras
vantagens.

12
 Podemos dizer que o CI é uma prática de desenvolvimento de software, onde
o código é alterado e entregue de maneira frequente e confiável.

1.5. O que é Qualidade Contínua

Pensando em produto ou serviço, qualidade é aquilo que faz com que ele se
destaque entre a concorrência, que o faz vendável e com baixo custo. Fazendo uma
analogia com a indústria automobilística e da necessidade de ser eficiente, no Japão pós-
guerra isso foi fundamental para que a indústria ganhasse o mercado internacional, se
destacando entre os demais fabricantes.

Isso incluiu esforços em processos para redução de desperdício (lean), uma

cultura de exigir qualidade em primeiro lugar em todas as fases da linha de produção,
autonomia aos funcionários para parar a linha de produção ao detectar problemas
(poder de decisão e liderança em todos os níveis), gerando assim menor quantidade de
problemas no produto final e, consequentemente, maior satisfação de seus clientes.

Esse conceito da manufatura se aplicou ao software, onde o controle de

qualidade se encontra na cultura, práticas e processos de uma organização.

DevOps traz a cultura de automação, porém, automação sem qualidade não

traz benefícios.

1.6. Desafios da Qualidade Contínua

Na plataforma de ensino da Microsoft Learning, há disponível o curso DevOps

Dojo White Belt, onde é demonstrado o paradigma do conceito tradicional de qualidade
e da qualidade contínua, conforme abaixo:

13
 Fonte: Adaptada de: <https://docs.microsoft.com/en-us/learn/modules/explain-devops-
continous-delivery-quality/3-explore-continuous-quality>

Nota-se uma alteração radical de pensamento, onde se destaca a prevenção

no lugar da detecção de problemas.

A qualidade contínua também preconiza a inexistência de silos, desde os

stakeholders até as equipes de tecnologia, o que gera engajamento, a crença de que a
responsabilidade é de todos, e uma cultura organizacional sólida. Soma-se ainda o
cuidado na escolha das métricas corretas (nos processos e não nos indivíduos),
ferramentas e tecnologias que possibilitem a Qualidade Contínua.

1.7. Importância do Shift Left

O relatório State of DevOps Report 2019, da empresa Puppet, demonstra o

resultado de um estudo da IBM System Science Institute, no qual é evidenciado o custo
relativo entre a correção de um defeito dentro do SDLC.

Quanto mais tarde o defeito é identificado, mais cara a sua correção.

14
 Por esse motivo, investir em qualidade e detecção de erros no início do
desenvolvimento é muito mais prático e sustentável para uma organização, garantindo
qualidade do produto ou serviço entregue ao cliente.

Fonte:
<https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_i
nto_the_Software_Development_Life_Cycle_SDLC>

Em se tratando de erros de segurança, os prejuízos podem ser exorbitantes,

custando ainda a reputação da organização.

O Shift Left necessita que haja testes numerosos, para detecção rápida e pronta
correção no início do SDLC.

Importante ressaltar que se deve ter cautela ao querer a perfeição ao extremo,

mas considerar uma avaliação criteriosa sobre o tempo e custo a serem dispendidos, e
se questionar se serão realmente frutíferos.

15
 Nesse caso, incluir uma abordagem conjunta com o Shift Right é uma saída para
minimizar possíveis impactos no ambiente produtivo, diversificando a estratégia de
implantação, como blue/green deployment, feature toggle, testes A/B, canary release.

Neste módulo focaremos no Shift Left e em como obter melhores resultados

com essa abordagem.

Veremos nos próximos capítulos como a ferramenta SonarQube pode ser

utilizada, seus recursos, dashboards e benefícios.

16
Capítulo 2. Instalação e Configuração

Conforme explicado no Capítulo 1 deste módulo, o SonarQube é uma potente

ferramenta de análise estática, focada em Qualidade e Segurança de código.

Ela está disponível para download em 4 versões:

• Community: é a única versão gratuita;

• Developer;

• Enterprise;

• Data Center.

Para fins educacionais, pode ser realizado o download da versão mais recente,
mas para fins profissionais, sempre se recomenda a versão LTS (Long Term Support),
também disponível para a versão gratuita.

Fonte: <https://www.sonarqube.org/downloads/>.

Para a escolha da versão adequada a uma empresa, deve-se levar em

consideração não só as funcionalidades, como também o preço cobrado por LoC (Lines
of Code), em português Linhas de Código (quanto maior a quantidade de programas a
serem inspecionados, maior o valor cobrado).

17
 Fonte: <https://www.sonarsource.com/plans-and-pricing/>.

Neste capítulo abordaremos como instalar, configurar e trabalhar com a versão

gratuita em seu próprio computador.

2.1. Instalar SonarQube

É possível instalar o SonarQube com a criação de um container do Docker

usando uma das imagens do Docker disponibilizadas no site da ferramenta, mas neste
módulo aprenderemos como efetuar a instalação através de um arquivo zip.

Pré-requisitos:

• Ter instalada a versão do Java para desenvolvedor, versão 11 (necessário tanto

para o servidor quanto para o scanner do SonarQube);

18
 • Mínimo de 2GB de RAM para executar eficientemente;

• 1GB livre na RAM para o Sistema Operacional;

• Espaço em disco necessário vai depender de quanto código será analisado com
o SonarQube;

• Disco rígido com alta performance;

• O arquivo “data” conterá os índices do Elasticsearch, que será usado para

conter o grande número de I/O (entradas/saídas) durante a execução quando
a instância do servidor estiver ativa;

• O Sonarqube não suporta sistemas operacionais de 32 bits no lado do servidor,

porém, suporta no lado do scanner (necessário para inspecionar o código).

Atenção:

(*) Não será necessário instalar um banco de dados nem um servidor

manualmente, a versão de download a partir do arquivo zip fará a instalação da
estrutura necessária para seu funcionamento.

Navegadores habilitados:

• Microsoft Edge;

• Mozilla Firefox;

• Google Chrome;

• Safari.

19
 Sistemas Operacionais:

• Windows (utilizado neste módulo);

• Linux;

• macOS.

Para entender a estrutura de funcionamento do SonarQube:

Fonte: Figura adaptada de: <https://docs.sonarqube.org/latest/setup/install-server/>.

De um lado, temos o SonarQube e o SonarScanner instalados no computador

do desenvolvedor, onde também se localiza a pasta com o projeto e suas subpastas,
onde estão os códigos desenvolvidos e toda a estrutura do(s) projeto(s).

De outro lado, temos o Servidor do SonarQube, composto por:

20
 • Servidor web: usado como interface entre o SonarQube e o usuário, onde será
possível consultar o relatório final (dashboard);

• Servidor de busca: baseado no Elasticsearch (mecanismo de busca e análise de

dados distribuído);

• Mecanismo de computação: responsável por processar os relatórios gerados

pela inspeção do código e salvá-los no Banco de Dados do SonarQube.

E também o Servidor de Banco de Dados, que se comunica com o Servidor do

SonarQube. No Banco de Dados serão armazenadas as métricas e os problemas
encontrados durante a inspeção do código, bem como a configuração da instância do
SonarQube.

Ao executar o SonarScanner na pasta do projeto, o resultado será exibido no

servidor web.

Passos para instalação:

• Efetuar download do SonarQube, versão gratuita Community, disponível em:

https://www.sonarqube.org/downloads/.

• Criar uma pasta em seu computador e extrair o conteúdo do arquivo zip nesse
local (nomear a pasta para fácil identificação):

21
• A pasta deverá conter as seguintes subpastas: bin, conf, data, elasticsearch,
extensions, lib, logs, temp, web.

E os arquivos COPYING e dependency-license.json.

22
 • A pasta bin conterá os arquivos para cada Sistema Operacional (Linux, macOS,
Windows), todos para 64 bits:

Pronto, o SonarQube está instalado!

Para consultar as particularidades de cada Sistema Operacional, consultar o

link: https://docs.sonarqube.org/latest/requirements/requirements/.

Observação: a partir daqui os comandos podem ser executados no Windows

via:

• cmd (linha de comando);

23
 • PowerShell;

• Qualquer outro aplicativo de execução de comandos.

2.2. Instalar Java

Antes de executar qualquer comando dentro do SonarQube ou do

SonarScanner, será necessário ter a versão 11 do Java (distribuição gratuita) para
desenvolvedor instalada em seu computador. Versões além dessa não são suportadas
oficialmente, conforme explica a seção de pré-requisitos da ferramenta. A
recomendação é que seja instalada a versão Oracle JRE 11 ou OpenJDK 11, na data em
que esta apostila foi escrita (2022).

Para consultar a versão atual necessária, consultar o site do SonarQube:

https://docs.sonarqube.org/latest/requirements/requirements/.

Se o link acima for alterado e não funcionar, procurar na Documentação do

SonarQube, Requerimentos, Pré-requisitos e Visão Geral, disponível na página inicial do
site.

Essa versão gratuita do Java não vem com um instalador.

Para conferir a versão do Java instalado em seu computador:

• Entrar em sua linha de comando (Prompt de comando) digitando cmd na barra

de pesquisa do computador.

• Digitar: java –version e clicar no botão <enter>.

• Deverá aparecer a versão 11:

24
 Caso não apareça como openjdk version “11...”, terá que seguir os passos a
seguir:

• Efetuar download do site: https://jdk.java.net/archive/.

• Clicar no arquivo zip para download, neste caso, versão para Windows 64 bit.

• Escolher ou criar uma pasta em seu computador para efetuar o download,

neste caso, criado como OpenJDK11, e extrair os arquivos nessa pasta:

25
 • Verificar integridade do arquivo baixado (checksum):

• Ao clicar em sha256, é aberta uma janela no navegador com o código de

verificação, neste caso:

cf39490fe042dba1b61d6e9a395095279a69e70086c8c8d5466d9926d80976d8

• Abrir o Prompt de Comando, entrar na pasta onde efetuou o download do

arquivo OpenJDK11, digitar dir e clicar no botão <enter>, deve aparecer o
conteúdo da pasta:

26
• Copiar o nome do arquivo com final bin.zip:

27
• Digitar o comando:

certutil –hashfile openjdk-11.0.2_windows-x64_bin.zip SHA 256 <enter>

• Comparar o resultado deste comando com o código apresentado no

navegador (devem ser iguais), para ter certeza que o seu download ocorreu
com sucesso:

• Para facilitar a comparação, copie e cole os 2 resultados no Notepad.

28
• Com a verificação finalizada, efetuar a extração do arquivo zip, que ao final
terá as pastas bin, conf, include, jmods, legal, lib e o arquivo release:

• Copiar o local da pasta onde os arquivos foram gravados, neste caso:

C:\OpenJDK11\openjdk-11.0.2_windows-x64_bin\jdk-11.0.2

• Abrir o Prompt de Comando como Administrador:

• Verificar a versão do Java na raiz do computador: C:\> java –version <enter>.

• Ainda deve estar apontando para a versão antiga.

29
 • Para alterar a versão do Java para a que foi instalada, é necessário alterar o
caminho nas variáveis de ambiente.

− Entrar no Prompt de Comando como Administrador e na raiz

do computador, digitar:

C:\>echo %JAVA_HOME%

− Após abrir a pasta onde o Java 11 foi instalado, digitar o

comando:

C:\>setx –m JAVA_HOME “local da pasta onde os arquivos do Java 11 foram gravados”

− Comando completo ficaria assim:

C:\>setx –m JAVA_HOME “C:\OpenJDK11\openjdk-11.0.2_windows-x64_bin\jdk-

11.0.2”

− Abrir o Prompt de Comando para verificar se agora está

apontando para a pasta da versão 11, com o comando java –
version <enter>.

− Uma vez confirmado que a versão está correta, vamos compilar

o Java com o comando javac –version <enter>.

30
− Outra maneira de alterar as variáveis de ambiente é entrando
em Propriedades do Meu Computador => Configurações
avançadas do Sistema:

31
− Tanto Java_Home quanto Path devem estar com o caminho do
arquivo bin do Java 11:

32
− Se não estiverem, clicar em Novo e adicioná-los.

− Para validar se todas as variáveis estão na pasta Path, clicar em

Path e depois em Editar:

− Que deverá apresentar o conteúdo abaixo (todos os 2 arquivos

devem estar neste Path):

o OpenJDK11\versão do SO_bin

o %JAVA_HOME%\bin

33
 Obs.: o arquivo do SonarScanner aparecerá após sua instalação, conforme
próxima seção.

2.2. Instalar SonarScanner

Efetuar download do site, neste curso escolher Windows 64-bit:

https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/.

34
 Criar e salvar numa pasta com seu nome para facilitar encontrá-la e efetuar a
extração dos arquivos:

Na pasta conf, arquivo Properties, configurar o Scanner para apontar para a url:

35
Adicione o caminho da pasta \bin em seu Path, em Variáveis de Ambiente:

Note que agora todos os 3 arquivos \bin necessários estão lá:

36
 OpenJDK11, %JAVA_HOME% e do SonarScanner.

Verificar a instalação do Scanner executando o comando dentro da pasta onde

instalou o SonarScanner:

C:\sonarscanner>sonar-scanner.bat –h

Se estiver tudo correto, deverá aparecer uma tela como abaixo:

2.3. Subir instância do servidor

Agora que temos tudo instalado, vamos subir a instância do servidor dentro da
pasta do SonarQube, através do comando abaixo:

No Windows: bin/windows-x86-64/StartSonar.bat <enter>.

37
 Quando a instância estiver pronta aparecerá a mensagem Process[es] is up:

Entrar no navegador e digitar o link para acessar o SonarQube:

http://localhost:9000/

38
Pode demorar um pouco para aparecer a tela inicial do SonarQube:

A página inicial do SonarQube será carregada, solicitando login e senha.

Utilizar admin para Login e Password.

Solicitará para trocar a senha em seu primeiro acesso:

39
Tudo pronto para iniciar a jornada pelo SonarQube!

40
Capítulo 3. Avaliação de Resultados

3.1. Introdução ao SonarQube

SonarQube é uma potente ferramenta de análise estática de código. Tem sido

utilizada amplamente, tanto por grandes organizações como desenvolvedores (mesmo
que a organização não a tenha instalado e fazendo parte de algum pipeline de
integração contínua), pois garante que os códigos estejam limpos e seguros.

Por sua versão gratuita atender a grande maioria de linguagens atualmente

utilizadas e de ser razoavelmente fácil de instalar e configurar, há muitos defensores de
que ela deva fazer parte de qualquer organização. Ela tem sido aprimorada ao longo dos
anos e, mesmo perdendo algumas de suas características em sua versão gratuita, ainda
assim é muito atrativa e efetiva.

Para as organizações, é necessário pensar não só nas tecnologias disponíveis,

como também a quantidade de linhas necessárias. Esta última informação afeta o preço
nas versões pagas que, por sua vez, trazem itens adicionais como visões consolidadas
por aplicação e portfolio, muito úteis para a liderança.

Maiores informações sobre quem revisou a ferramenta, suas avaliações e

comparações com outras alternativas do mercado estão disponíveis no site da GARTNER
(2022): https://www.gartner.com/reviews/market/communications-platform-as-a-
service/vendor/sonar/product/sonar.

O que chama a atenção é que ela ainda é preferida com relação a seus
concorrentes.

41
3.2. Visão geral das funcionalidades

Em sua primeira entrada ao link do SonarQube, não haverá projetos ainda, mas
é nesta aba que estarão todos os projetos executados.

A aba de Issues (problemas) será uma das mais utilizadas e que conterá a maior
parte das informações a serem analisadas e seus detalhes.

Todos os dados de bugs, vulnerabilidades e code smells estarão descritos aqui

assim que um projeto for executado:

42
 Na aba de Regras, será possível identificar a lista de regras existentes por
linguagem.

Para explorá-las, basta clicar nela que expandirá para os tipos, inclusive com a
classificação de tag (suspicious, obsolete, accessibility etc.).

Para consultar mais linguagens, expanda em Show More:

43
 Na aba Perfis de Qualidade teremos a coleção de regras por linguagem (perfil
padrão):

44
 Na aba Quality Gates temos inicialmente o padrão sugerido pela ferramenta,
de nome Sonar way.

Como Administradores da ferramenta, será possível administrá-las (acesso

restrito), podendo haver mais que um Gate, conforme necessidade e definição por parte
da organização.

Se nada for configurado, Sonar way será o Gate padrão para todas as
execuções. O mesmo se aplicará para as execuções automáticas via pipeline.

Na aba Administration há as configurações gerais utilizadas pelos times que

administrarão a ferramenta dentro da organização, com uso restrito também.

Normalmente, serão as equipes que criam pipelines, equipes SRE e equipes de

suporte da ferramenta.

45
 Para a versão gratuita, não há análise de projetos por branches e pull requests,
todas as execuções serão reportadas como sendo executadas na master no relatório
final. Essa opção está habilitada a partir da versão Developer.

3.3. Tipologia dos problemas

Vamos iniciar o entendimento da principal aba onde, segundo o site da

ferramenta SONARQUBE (2022), temos:

Issues: Quando um pedaço de código não cumpre uma regra, um problema é

registrado no snapshot. Um problema pode estar conectado em um arquivo fonte ou
em um arquivo de teste de unidade. Há 3 tipos de problemas: Bugs, Code Smells e
Vulnerabilidades.

• Definições:

46
 − Bugs: Uma questão que representa algo errado no código. Se
isso ainda não tiver sido quebrado, será, e provavelmente no
pior momento possível. Isto precisa ser consertado. Ontem!

− Code Smells: Uma questão relacionada à manutenção no

código. Deixá-lo como está significa que, na melhor das
hipóteses, os mantenedores terão mais dificuldade do que
deveriam para fazer mudanças no código. Na pior das
hipóteses, eles ficarão tão confusos com o estado do código
que introduzirão erros adicionais à medida que fizerem
mudanças.

− Vulnerabilidades: Uma questão relacionada à segurança, que

representa uma porta dos fundos aberta para os atacantes.

Cada tipo de problema estará classificado dependendo de sua gravidade,

como:

− Blocker: Bug com alta probabilidade de impacto no

comportamento da aplicação na produção: vazamento de
memória, conexão JDBC não fechada, .... O código DEVE ser
consertado imediatamente.

− Critical: Um bug com baixa probabilidade de afetar o

comportamento da aplicação na produção ou um problema
que represente uma falha de segurança: bloco de captura
vazio, injeção SQL, ... O código DEVE ser revisto
imediatamente.

47
 − Major: Falha de qualidade que pode causar grande impacto na
produtividade do desenvolvedor: peça de código não coberta,
blocos duplicados, parâmetros não utilizados, ...

− Minor: Falha de qualidade que pode afetar ligeiramente a

produtividade do desenvolvedor: as linhas não devem ser
muito longas, as declarações de "troca" devem ter pelo menos
3 casos, ...

− Info: Nem um bug, nem uma falha de qualidade, apenas uma

descoberta.

Outras terminologias importantes:

Lista completa dos conceitos disponível em:

https://docs.sonarqube.org/latest/user-guide/concepts/

− Remediation cost: O tempo estimado necessário para corrigir

problemas de Vulnerabilidade e Confiabilidade.

− Snapshot: Um conjunto de medidas e problemas sobre um

determinado projeto em um determinado momento. É gerada
uma ‘foto’ para cada análise.

− Technical debt: O tempo estimado necessário para corrigir

todos os problemas de manutenibilidade / code smells.

− New Code: Um conjunto de mudanças ou período em que você

está acompanhando de perto a introdução de novos

48
 problemas no código. O ideal é que isso ocorra desde a versão
anterior (última execução do scanner).

3.4. Dívida técnica

Esse termo é comumente confundido e traduzido como débito técnico em

português, mas a tradução correta de technical debt é dívida técnica.

Pensando em dívida bancária, lembre-se que ela não cresce aos poucos, mas
exponencialmente. O mesmo ocorre se não dermos atenção aos pequenos problemas
nos códigos, eles se acumulam a tal ponto que a correção deles acaba se tornando cada
vez mais onerosa ao longo do tempo.

O termo ‘programa macarrônico’ ilustra também a dificuldade de alguém

conseguir entender o programa, o que pode dificultar seu entendimento e correção em
caso de problemas.

Aqui, alguns pontos que podem ser considerados para identificar que o código
esteja sofrendo devido à falta de refatoração:

Fonte: criação da professora, apresentado no Minas Testing Conference (2021).

49
 Segundo KIM et al. (2016), o termo Greenfield e Brownfield tem sua origem em
projetos urbanos de planejamento e construção. Na tecnologia o termo Greenfield está
relacionado a projetos iniciando do zero, com poucas preocupações com código, bases,
processos e equipes e, em contrapartida, Brownfield está relacionado a projetos de
produtos e serviços já existentes, o que normalmente traz um grande acúmulo de dívida
técnica, como não ter teste automatizado algum ou rodando em plataformas não
suportadas.

Entender essa diferença faz parte da cultura DevOps e times SRE. Neste
módulo, o termo será utilizado como uma das métricas dentro do SonarQube, com uma
definição específica.

3.5. Definições de métricas

Agora vamos conhecer as métricas utilizadas no SONAQUBE (2021), para que

se familiarize com os termos.

• Complexity: É a Complexidade Ciclomática calculada com base no número de

caminhos através do código. Sempre que o fluxo de controle de uma função
se divide, o contador de complexidade é incrementado por um. Cada função
tem uma complexidade mínima de 1. Esse cálculo varia ligeiramente de acordo
com a linguagem, pois as palavras-chave e as funcionalidades podem variar.

• Duplications: Há uma variação na contagem de duplicações:

− Blocos de linhas duplicadas;

− Arquivos duplicados;

− Linhas duplicadas;

50
 − % de linhas duplicadas = linhas duplicadas / total de linhas *
100 (onde / é divisão e * é multiplicação).

• Issues: são considerados como erros, problemas ou violações.

• Maintainability: é o total de problemas Code Smells encontrados.

• O índice de manutenibilidade é a classificação dada ao seu projeto em relação

ao valor de seu Índice de Dívida Técnica.

A pontuação padrão de Maintainability Rating é:

A=0-0,05, B=0,06-0,1, C=0,11-0,20, D=0,21-0,5, E=0,51-1

A escala de Manutenibilidade pode ser declarada alternadamente dizendo que,

se o custo de remediação pendente for:

− <=5% do tempo que já passou na aplicação, a classificação é A;

− entre 6 e 10% a classificação é um B;

− entre 11 e 20% a classificação é de C;

− entre 21 e 50% a classificação é um D;

− qualquer coisa acima de 50% é um E.

• Reliability: Confiabilidade, é o número de bugs.

• Reliability Rating: o índice de confiabilidade é definido entre notas de A a E,

sendo:

− A = zero bugs;

51
 − B = no mínimo 1 bug de severidade Minor;

− C = no mínimo 1 bug de severidade Major;

− D = no mínimo 1 bug de severidade Critical;

− E = no mínimo 1 bug de severidade Blocker.

• Security: Segurança é o número de vulnerabilidades encontradas.

• Security Rating: O índice de segurança é definido por notas de A a E:

− A = zero vulnerabilidades;

− B = no mínimo 1 vulnerabilidade de severidade Minor;

− C = no mínimo 1 vulnerabilidade de severidade Major;

− D = no mínimo 1 vulnerabilidade de severidade Critical;

− E = no mínimo 1 vulnerabilidade de severidade Blocker.

• Lines of code: Linhas de código é o número de linhas físicas que contêm no

mínimo um caracter que não seja nem um espaço em branco, nem uma
tabulação, nem parte de um comentário.

52
Capítulo 4. O que são Quality Gates

4.1. Quality Gates

Traduzindo, seriam os Portões da Qualidade. São eles que aplicam políticas de

qualidade na organização, respondendo uma pergunta: “meu projeto está pronto para
ser implantado?”.

Neles são definidas as regras que serão aplicadas ao executar uma inspeção do
código. E os resultados terão dois valores possíveis: Error (Failed) ou OK (Passed). O
relatório final da inspeção revelará exatamente em quais condições o código passou ou
falhou e, assim, será possível corrigi-lo conforme instruções encontradas nos
comentários da ferramenta.

As regras são definidas pelos times que administram a ferramenta, times de

Qualidade ou até mesmo o SRE. Somente usuários com alçada de Administradores de
Quality Gates poderão criar, alterar, excluir regras.

Usualmente, haverá ao menos um Quality Gate, mas isso pode ser alterado,
dependendo da necessidade dos projetos que a organização possuir.

Se nada for configurado, o SonarScanner utilizará o Quality Gate padrão

chamado “Sonar way”.

As regras poderão ser criadas para todo o código ou somente para o código
novo ou alterado.

Ao definir um Quality Gate, tenha em mente que cada condição é uma

combinação de:

• Métrica;

53
 • Operador de comparação;

• Um valor de erro.

Por exemplo:

Regra: Erro do tipo Blocker (Métrica) for > (maior = comparação) que zero
(valor do erro), o que significa que não será admitido nenhum erro de gravidade Blocker.
Se isso ocorrer, o resultado do Quality Gate será Failed.

54
 Exemplo de execução com sucesso:

4.2. Quality Profiles

Quality Profiles são os perfis de qualidade, o componente principal do

SonarQube, onde você define um conjunto de regras. Cada linguagem possui seu
próprio Quality Profile (disponível para consulta na aba Quality Profiles, e clicando na
linguagem).

É possível alterar o Quality Profile, desde que haja permissão de administrador

de Quality Profile. É possível dar permissão para somente um Quality Profile e não todos.
Dificilmente será necessário alterar esse perfil, mas é bom saber que isto é possível.

55
4.3. Estratégias de implementação

Para uma abordagem inicial de regras, é necessária uma boa avaliação da

situação atual dos projetos existentes na organização. Pode-se iniciar com poucos e
pequenos projetos e seguir expandindo para os demais, assim que tiverem mais
experiência com a ferramenta.

O Quality Gate padrão é o “Sonar way”. Abaixo podemos observar os

operadores e valores que existem:

Para se criar um novo Quality Gate, clicar no botão ‘Copy’, alterar as condições
que julgar necessárias, e criar um novo nome. Após isso, também é possível alterar para
que esse novo Gate seja o padrão (default). Isso é muito prático quando temos uma
estratégia, por exemplo, de execuções de projetos novos e legado.

Suponha que seu legado não tenha nenhuma cobertura de testes unitários e
que não será necessário melhorar esses projetos, pois serão desativados num período
curto de tempo, sendo um desperdício investir em corrigir ou melhorá-los. Ao criar este
novo Gate e o pipeline estiver apontando para ele, as regras serão diferentes das que

56
os projetos novos são submetidos, possibilitando ter resultados aderentes à estratégia
da organização.

4.4. Cuidados gerais

Como visto no início deste módulo, várias configurações são realizadas

manualmente através do arquivo sonar-properties, onde é possível alterar o que o
código pode desconsiderar em sua inspeção.

Com a evolução de seu pipeline de CI, é importante que esses arquivos estejam
em locais onde o desenvolvedor não possa atualizá-los. Ou, minimamente, haver uma
auditoria para que casos assim não passem despercebidos.

Após utilizar com frequência o SonarQube, também haverá acúmulo de

informações armazenadas no Banco de Dados, então aplicar limpezas automatizadas
são uma boa maneira de não exceder os limites de armazenamento de seus bancos.

Com essa limpeza recorrente, alguns dados importantes podem ser excluídos,
então uma boa ideia é ter um mecanismo de armazenamento em um Datalake para que
possam ser utilizados por outras ferramentas, como Kibana, PowerBI ou Grafana.

A limpeza pode seguir a premissa de que o projeto não tenha sofrido execuções
no SonarQube por um período de tempo, digamos 90 dias.

Para fins de acompanhamento da evolução de um projeto utilizando a versão

gratuita, será necessário consolidar os dados em ferramentas próprias para que seja
possível ter uma visão consolidada, como um Portfólio.

57
Referências

ANALYZE Continuous Integration. Microsoft Docs, c2022. Disponível em:

<https://docs.microsoft.com/en-us/learn/modules/analyze-devops-continuous-
planning-intergration/3-analyze-continuous-integration>. Acesso em: 25 fev. 2022.

CONCEPTS. SonarQube Docs 9.3, c2008-2021. Disponível em: <>. Acesso em: 25 fev.
2022.

DAWSON, Maurice; BURREL, Darrell; RAHIM, Emad; BREWSTER, Stephen. Integrating

Software Assurance into the Software Development Life Cycle (SDLC). In: Journaul of
Information Systems Technology and Planning, v. 3, 1 jan. 2010, p. 49-53. Disponível
em:
<https://www.researchgate.net/publication/255965523_Integrating_Software_Assura
nce_into_the_Software_Development_Life_Cycle_SDLC>. Acesso em: 25 fev. 2022.

DIFFERENCE between Static and Dynamic Testing. GeeksforGeeks, 27 fev. 2020.

Disponível em: <https://www.geeksforgeeks.org/difference-between-static-and-
dynamic-testing/>. Acesso em: 25 fev. 2022.

E-BOOK—Secrets Revealed: What Emerging Tech Companies Are Looking for in

DevOps/SRE Roles. Harrison Clarke, c2022. Disponível em:
<https://www.harrisonclarke.com/what-emerging-tech-companies-are-looking-for-in-
devops-roles>. Acesso em: 23 fev. 2022.

EXPLORE Continuous Quality. Microsoft Docs, c2022. Disponível em:

<https://docs.microsoft.com/en-us/learn/modules/explain-devops-continous-delivery-
quality/3-explore-continuous-quality>. Acesso em: 25 fev. 2022.

58
EXPLORE Continuous Quality. Microsoft Learning, c2022. Disponível em:
<https://docs.microsoft.com/en-us/learn/modules/explain-devops-continous-delivery-
quality/3-explore-continuous-quality>. Acesso em: 23 fev. 2022.

INSTALL the Server. SonarQube Docs 9.3, c2008-2021. Disponível em:

<https://docs.sonarqube.org/latest/setup/install-server/>. Acesso em: 25 fev. 2022.

KIM, Gene. Greenfield Vs. Brownfield Services. In: KIM, Gene; HUMBLE, Jez; DEBOIS,
Patrick; WILLIS, John. The Devops Handbook: How to Create World-Class Agility,
Reliability, & Security in Technology Organizations. 1. ed. Portland: IT Revolution Press,
2016. cap., p. 54-56. E-book (130 p.).

MUNIZ, Antonio. Aplique técnicas de qualidade no início do ciclo para implantação

contínua de software. In: Jornada Ágil de Qualidade. 1. ed. Rio de Janeiro: Brasport,
2019. p. 54-58.

SONAR Reviews. Gartner PeerInsights, c2022. Disponível em:

<https://www.gartner.com/reviews/market/communications-platform-as-a-
service/vendor/sonar/product/sonar?marketSeoName=communications-platform-as-
a-service&productSeoName=sonar&vendorSeoName=sonar>. Acesso em: 23 fev. 2022.

SONARQUBE. sonarqube, c2022. Your teammate for Code Quality and Code Security.
Disponível em: <https://www.sonarqube.org/>. Acesso em: 23 fev. 2022.

STOTNY, Łukasz. The difference between static and dynamic analysis. Enterfea, 24 out.
2019. Disponível em: <https://enterfea.com/difference-between-static-and-dynamic-
analysis/>. Acesso em: 25 fev. 2022.

59
WHAT is a CI/CD pipeline? Understanding DevOps. Red Hat, 8 jan. 2019. Disponível em:
<https://www.redhat.com/en/topics/devops/what-cicd-pipeline>. Acesso em: 23 fev.
2022.

60