🔍 Analisando Qualidade de Código com SonarQube e Docker: Guia Completo
Se você trabalha com desenvolvimento de software, sabe o quanto é importante manter um código limpo, seguro e de fácil manutenção. Para isso, ferramentas de análise estática como o SonarQube são grandes aliadas.
Neste post, vou te mostrar como subir um ambiente SonarQube com Docker, analisar um projeto com o SonarScanner via CLI e ainda te explicar como ignorar arquivos específicos e ajustar regras de análise.
🚀 Subindo o SonarQube com Docker Compose
Vamos utilizar dois serviços:
- SonarQube: Ferramenta de análise de qualidade de código.
- PostgreSQL: Banco de dados utilizado pelo SonarQube.
A estrutura do docker-compose.yaml define variáveis de ambiente para os dois serviços e três volumes para persistência de dados:
services:
sonarqube:
image: sonarqube:lts-community
depends_on:
- db
networks:
- sonar_net
environment:
SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
SONAR_JDBC_USERNAME: sonar
SONAR_JDBC_PASSWORD: sonar
ports:
- "9000:9000"
volumes:
- sonar_data:/opt/sonarqube/data
- sonar_logs:/opt/sonarqube/logs
db:
image: postgres:13
environment:
POSTGRES_USER: sonar
POSTGRES_PASSWORD: sonar
POSTGRES_DB: sonar
networks:
- sonar_net
volumes:
- sonar_db:/var/lib/postgresql
networks:
sonar_net:
driver: bridge
volumes:
sonar_data:
sonar_logs:
sonar_db:
Principais volumes:
sonar_data: Dados da aplicação SonarQube.sonar_logs: Logs gerados durante a análise.sonar_db: Dados do banco PostgreSQL.
Comando para iniciar:
docker compose up -d
Após isso, o SonarQube estará disponível em http://localhost:9000.
🔎 Executando o SonarScanner via Docker
Para analisar o código, usaremos a imagem oficial sonarsource/sonar-scanner-cli:
docker container run --rm --network=host \
-e SONAR_HOST_URL="http://localhost:9000" \
-v "/caminho/para/seu/projeto:/usr/src" \
sonarsource/sonar-scanner-cli \
-Dsonar.projectKey=nome-do-projeto \
-Dsonar.sources=. \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=SEU_TOKEN_DO_SONARQUBE
| Parâmetro | Função |
|---|---|
--rm |
Remove o container ao fim da execução |
--network=host |
Permite acesso à rede do host (necessário se o SonarQube estiver em localhost) |
-v /seu/projeto:/usr/src |
Monta o código local dentro do container |
-Dsonar.projectKey |
Nome do projeto no SonarQube |
-Dsonar.sources=. |
Define o diretório onde o código será analisado |
-Dsonar.login |
Token pessoal de acesso ao SonarQube |
⚠️ IMPORTANTE!!!
- Certifique-se de que o diretório montado contenha o código a ser analisado.>
- O token informado no parâmetro `-Dsonar.login` precisa ser gerado no painel do SonarQube em **My Account > Security > Generate Tokens**.>
- Altere o valor de `sonar.projectKey` conforme o projeto a ser analisado.
🔒 Ignorando arquivos e diretórios na análise
Nem todo arquivo precisa ser analisado. Para ignorar testes, bibliotecas ou outros arquivos específicos, você pode:
Opção 1 – No comando do scanner:
-Dsonar.exclusions=/tests/,/node_modules/,**/*.spec.js
Opção 2 – Usando sonar-project.properties:
Crie este arquivo na raiz do projeto com:
sonar.projectKey=meu-projeto
sonar.sources=src
sonar.exclusions=**/test/**,**/scripts/**
# Ignorando regras específicas
sonar.issue.ignore.multicriteria=r1
sonar.issue.ignore.multicriteria.r1.ruleKey=squid:S00122
sonar.issue.ignore.multicriteria.r1.resourceKey=**/*.js
Você pode excluir arquivos, diretórios inteiros ou até regras específicas para tipos de arquivos.
🛠 Ajustando as regras de análise
O SonarQube organiza as regras em Quality Profiles. Para editar as regras:
- Acesse o painel do SonarQube (
http://localhost:9000) - Vá em Quality Profiles
- Escolha a linguagem desejada (ex: JavaScript, PHP, etc.)
- Clique em Deactivate nas regras que deseja desabilitar
Você também pode clonar um perfil e criar um conjunto de regras personalizado para seu time ou projeto.
🧭 Entendendo a Interface do SonarQube
Após realizar uma análise com sucesso, o SonarQube exibe um painel de controle com os principais indicadores de qualidade do seu projeto.
✅ Quality Gate Status
- Passed: O projeto passou em todas as regras definidas no Quality Gate.
- Se aparecer como Failed, é porque alguma métrica crítica (como cobertura de testes, vulnerabilidades, bugs, etc.) não atingiu o valor mínimo esperado.
📊 Painel de Métricas (Measures)
A aba Overall Code exibe um resumo completo da análise. Veja o que cada item significa:
| Indicador | Significado |
|---|---|
| Bugs | Problemas no código que podem causar comportamentos incorretos. |
| Vulnerabilities | Pontos que podem representar falhas de segurança exploráveis. |
| Security Hotspots | Trechos de código que podem representar risco, mas exigem revisão manual. |
| Debt (Débito Técnico) | Tempo estimado necessário para corrigir todos os problemas. |
| Code Smells | Problemas que não afetam diretamente o funcionamento, mas prejudicam manutenção e legibilidade. |
| Coverage | Percentual do código coberto por testes automatizados. |
| Duplications | Porcentagem de linhas de código duplicadas em diferentes partes do projeto. |
| Duplicated Blocks | Quantidade de blocos de código repetidos. |
| Unit Tests | Número de testes unitários identificados (se configurado). |
🔴 Indicadores Críticos
- Reliability (E): A nota vai de A a E, baseada principalmente na quantidade de bugs. "E" é uma nota baixa, mas se o Quality Gate permitir, o projeto ainda pode passar.
- Security Review (E): Significa que nenhum dos Security Hotspots foi revisado manualmente.
- Maintainability (A) e Security (A): Indicam boa saúde nesses aspectos.
✅ Conclusão
Com essa estrutura, você consegue:
- Rodar o SonarQube em qualquer ambiente com Docker
- Analisar qualquer projeto local com o scanner CLI
- Ignorar arquivos irrelevantes para a análise
- Ajustar regras que não fazem sentido para sua realidade
Essa abordagem te dá controle total sobre a análise de qualidade do seu código, sem depender de ferramentas externas ou ambientes complexos.
Se quiser conferir o vídeo original onde baseei esse setup, dá uma olhada aqui:
🎥 Instalando e Configurando o SonarQube com Docker Compose
:P