A Importância da cobertura de testes e da integração do SonarQube no ciclo de vida de um projeto

Em projetos de software, a busca por qualidade e confiabilidade deve ser constante. Muitas vezes, o time foca em entregar funcionalidades rapidamente, mas negligencia práticas essenciais que garantem a manutenção saudável do código a médio e longo prazo. Duas dessas práticas são: cobertura de testes automatizados e integração com ferramentas de análise estática como o SonarQube.

Por que se preocupar com cobertura de testes?

Testes automatizados, sejam unitários, de integração ou de ponta a ponta, têm um papel fundamental: garantir que o comportamento esperado da aplicação se mantenha ao longo do tempo. A cobertura de testes, por sua vez, é uma métrica que indica qual parte do código está sendo exercitada pelos testes.

Embora uma cobertura de 100% não signifique código 100% livre de bugs, uma baixa cobertura é um sinal de alerta. Código sem testes está mais propenso a falhas quando sofre alterações, principalmente em times grandes, onde o conhecimento sobre determinadas áreas do sistema nem sempre é compartilhado.

Benefícios diretos da cobertura de testes

• Redução de regressões: mudanças não quebram funcionalidades existentes.
• Facilidade de refatoração: refatorar com testes confiáveis é como ter uma rede de segurança.
• Documentação viva: bons testes explicam como o sistema deve se comportar.
• Mais confiança na entrega contínua: possibilita integração e deploy frequentes.

SonarQube: seu aliado na saúde do código

O SonarQube é uma ferramenta de análise estática que ajuda a monitorar a qualidade do código-fonte. Ele aponta bugs, code smells, vulnerabilidades e cobertura de testes. Quando integrado a um pipeline de CI/CD (Jenkins, GitHub Actions, GitLab CI, Azure DevOps), ele se torna um gate de qualidade.

Vantagens de integrar o projeto com o SonarQube:

• Visibilidade clara de pontos fracos no código.
• Monitoramento da cobertura de testes e da dívida técnica.
• Padronização de boas práticas e convenções de código.
• Alertas em tempo real de violações críticas de qualidade.
• Feedback imediato ao time durante pull requests.

Com o SonarQube, não se trata apenas de "escrever código que funciona", mas sim de escrever código limpo, seguro e sustentável.

Estratégia prática: como começar

1. Crie uma suíte mínima de testes automatizados: Comece testando as partes críticas da aplicação.
2. Adote TDD sempre que possível: Isso impulsiona a escrita de código testável.
3. Integre o SonarQube no seu pipeline (ex: Jenkins, GitHub Actions, GitLab CI).
4. Defina métricas mínimas aceitáveis de cobertura e qualidade (por exemplo, 40% de cobertura mínima e zero bugs críticos).

Promova uma cultura de qualidade: Revisões de código devem considerar a cobertura e o feedback do SonarQube.

Considerações finais

Desenvolver sem testes é como construir um prédio sem fundações. E seguir sem análise de qualidade contínua é não perceber as rachaduras que surgem no caminho. A integração de testes automatizados com o SonarQube traz uma cultura de qualidade que não só beneficia a equipe de desenvolvimento, mas toda a organização, entregando valor de forma contínua, sustentável e segura.

Testar é responsabilidade de todos os desenvolvedores e QAs. Monitorar a qualidade também.

Feito!

Instalando e Configurando o SonarQube no ambiente Docker

O objetivo deste post, é explicar os procedimentos de instalação e configuração do SonarQube no ambiente Docker.

O que é SonarQube?

SonarQube é um software open-source que se propõe a ser a central de qualidade do seu código-fonte, lhe possibilitando o controle sobre um grande número de métricas de software, e ainda apontando uma série de possíveis bugs.

Instalação e configuração

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

$ mkdir $HOME/sonarqube
$ cd $HOME/sonarqube

Executar no HOST antes

Para que o nó do Elastiscsearch seja inicializado com sucesso, pois o SonarQube utiliza o Elasticsearch na indexação nas buscas.

Para verificar a vm.max_map_count atual, execute o seguinte comando:

$ cat /proc/sys/vm/max_map_count

Se a contagem de mapas não for 262144, siga estas etapas:

1. Atualize o arquivo /etc/sysctl.conf com o seguinte valor: vm.max_map_count=262144

2. Execute o comando a seguir para aplicar as alterações sem reiniciar o nó.
$ sudo sysctl -q -w vm.max_map_count=262144

$ curl -sSL https://raw.githubusercontent.com/bitnami/bitnami-docker-sonarqube/master/docker-compose.yml > docker-compose.yml

PS: Para utilizar no servidor de produção, é recomendado alterar a variável ALLOW_EMPTY_PASSWORD de "yes" para "no" e definir um password seguro para o SGBD PostgreSQL utilizado no SonarQube e o usuário administrador de acesso ao SonarQube.

Adicionar as variáveis SONARQUBE_USERNAME e SONARQUBE_PASSWORD para um nome de usuário e password que irá gerenciar o SonarQube.

$ docker-compose up -d

Aguarde subir o ambiente, após concluir, abre o browser e acesse http://localhost

No primeiro acesso, o username/password default são: admin/bitnami. Caso tenha alterado o username/password default no arquivo docker-compose.yml, então utilize o que você definiu.

Após o acesso do SonarQube, pode inserir as métricas de análise do código para o seu projeto e integrar com o SonarLint na IDE que estiver utilizando no desenvolvimento do seu projeto, também no CI/CD (Continuos Integrations/Continuos Delivery).

O que é CI/CD?

CI/CD (Continuous Integration/Continuous Delivery), é um método para entregar aplicações com frequência aos clientes. Para isso, é aplicada a automação nas etapas do desenvolvimento de aplicações.

Exemplos de ferramentas que fazem CI/CD: Jenkins, Bamboo, GitHub Actions, CircleCI.

Utilize a ferramenta CI/CD a sua escolha para o seu projeto. É importante ressaltar que essas ferramentas de CI/CD integram com o Git com as plataformas GitHub, Bitbucket e Gitlab.

Feito!

Realizar deploy com GitHub Actions

O que é GitHub Actions?

GitHub Actions é uma plataforma de integração contínua e entrega contínua (CI/CD) que permite automatizar a sua compilação, testar e pipeline de implantação. É possível criar fluxos de trabalho que criam e testam cada pull request no seu repositório, ou implantar pull requests mesclados em produção.

O presente post, explica os procedimentos de deploy com CI/CD no GitHub Actions.

No servidor de produção, execute:

ssh-keygen -m PEM -t rsa -b 4096 -C "seuusuario@github.com" cat github-actions >> autenticate_keys cat github-actions

A chave secreta que deve ser copiar na sua conta do GitHub

Criar o arquivo .yml para o CI/CD

$ vim github-action\workflows\ci.yml

NOTA: Se atentar a tabulação do arquivo .yml

name: seudominio.com CI
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout do repositorio
        uses: actions/checkout@1
      - name: Deploy para meu hosting
        uses: easingthemes/ssh-deploy@main
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SERVER_SSH_KEY }}
          ARGS: "-rlgoDzv0 --delete"
          SOURCE: "src/"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          REMOTE_PORT: ${{ secrets.REMOTE_PORT }}
          TARGET: ${{ secrets.REMOTE_TARGET }}

Agora criar o repositório local e remoto (GitHub, Bitbucket ou GitLab)

Em Settings/Secrets adicione o valor das variáveis definidas no arquivo ci.yml nos respectivos campos, tais como: REMOTE_HOST, REMOTE_USER, REMOTE_PORT.

git add .
git commit -m "First commit"
git remote add origin URL_REPOSITORIO
git push origin main


Verificar no GitHub Actions o processo de deploy

Pronto, é assim que precisa ser o deploy aplicando CI/CD automatizado. Caso você ainda utiliza o deploy via FTP ou conecta o servidor de produção via SSH, esteja ciente que está no modo arcaico.

Referências

https://github.com/features/actions

Feito!