SonarQube — quality gate como barreira de merge

SonarQube analisa o código sem executá-lo e classifica o que encontra por impacto em confiabilidade, segurança e manutenibilidade, com um quality gate que aprova ou reprova cada análise. Aqui ele roda com PostgreSQL, recebe a análise do scanner oficial e decide, pela Web API, se o serviço de transferências pode ser integrado. Use como etapa de CI: gate reprovado bloqueia o merge.

passos: 6
arquivos: 8
testes: 0
tecnologias: 5

Infraestrutura realTypeScriptBunPostgreSQLSonarQubeDocker

Cenário Relações Comparar

Baixar cartão

Cenário

Um serviço de transferências PIX e TED entra em revisão antes de subir para produção. src/service_transfer.ts carrega defeitos plantados — senha do PSP no código, valores ordenados como texto, || com os dois lados iguais que rejeita toda TED, variável atribuída e nunca lida, função de tarifa copiada e aninhamento profundo. O gate do banco exige nota A em confiabilidade, segurança e manutenibilidade e no máximo 3% de linhas duplicadas: o serviço defeituoso reprova em confiabilidade e segurança; src/service_transfer_reviewed.ts, a mesma lógica depois da revisão, passa.

> service_transfer.ts quebra de propósito as regras do repositório e desliga o lint para si. Ele é o objeto da análise, não um exemplo a copiar.

Como funciona

6 passos

Análise estática de um serviço de transferências

Esconde cada passo: lembre antes de tocar para revelar.

01
adminLogin troca a senha padrão admin/admin no primeiro boot; nas execuções seguintes ela já está trocada
02
bankGateEnsure cria o gate Bank só com condições sobre o código inteiro e o associa aos dois projetos
03
tokenIssue gera um token por execução, revogado ao fim — token de scanner que não expira é credencial esperando vazar
04
scannerRun roda sonar-scanner-cli na rede do host, com o token por variável de ambiente, e lê o id da tarefa que o servidor enfileirou
05
analysisWait espera o compute engine terminar: ler o gate antes devolve a análise anterior
06
gateStatus e issuesList trazem o veredito e as regras que o explicam

apps/infrastructure/sonarqube

8 arquivos

src/

service_transfer.tsServiço sob análise, com os defeitos plantados
service_transfer_reviewed.tsO mesmo serviço depois da revisão
sonar_api.tsWeb API: senha do admin, token, gate, espera da análise, status e issues
scanner_run.tsRoda o scanner oficial e devolve a tarefa do compute engine
config_sonar.tsConfiguração validada do ambiente
demo.tsdemoAnalisa as duas versões e imprime o veredito de cada uma

./

sonar-project.propertiesPadrões do scanner quando rodado direto no diretório
docker-compose.ymlinfraSonarQube e PostgreSQL

Executar · com Docker

$ sudo sysctl -w vm.max_map_count=262144
$ docker compose up -d --wait# sobe PostgreSQL · SonarQube
$ cp .env.example .env# variáveis de ambiente
$ bun install# dependências
$ bun run demo# roda o cenário
$ bun run test# integração contra o serviço real
$

UI: http://localhost:9000 (admin, senha do SONAR_ADMIN_PASSWORD). O primeiro boot leva um ou dois minutos.

Requisitos: BunDocker
Sobe junto: PostgreSQLSonarQube

Relações

Onde ele se encaixa

Mapa

SonarQube

Combina com3

Por que se relacionam

Combina com

O que cada defeito plantado vira no relatório

Defeito no código	Regra	Nota que derruba
Senha do PSP fixa no fonte	`typescript:S2068`	Segurança
`[100000, 20000, 5000].sort()`	`typescript:S2871`	Confiabilidade
`rail === "pix" \|\| rail === "pix"`	`typescript:S1764`	Confiabilidade
`auditPrefix` atribuído e nunca lido	`typescript:S1854`	— (code smell)
Tarifa TED idêntica à PIX	`typescript:S4144`	— (code smell)
Seis níveis de `if` aninhado	`typescript:S3776`	— (code smell)

Teste rápido

Qual destes combina com SonarQube?

Próximo projeto · Infraestrutura em Dockerk6 — teste de carga como portão de CI

Contatos

SonarQube — quality gate como barreira de merge