Como tornei meu processo de desenvolvimento mais ágil com o Sonarqube?
Dando início ao meu primeiro artigo técnico, estarei falando um pouco sobre Sonarqube, ferramenta que normalmente está no seu pipeline, faz análise de código e segurança da sua aplicação.
Acredito que está pode ser uma série de alguns post sobre Sonarube que estarei fazendo. A ideia é explicar um pouco da experiência que estou tendo com Sonar na squad em que trabalho. Além disso, também vou falar como superei algumas dificuldades relacionadas ao pipeline da aplicação, desenvolver cobertura de testes, e tornar o meu desenvolvimento de código mais ágil e consequentemente com mais qualidade.
Este artigo requer que você já tenha alguma familiaridade com Docker, CI/CD, git, pois serão algumas das ferramentas que estarão presentes por aqui.
Como objetivo inicial, a ideia neste momento é instalar o Sonarqube na sua máquina. Para isso vou mostrar duas abordagens possíveis. Uma observação importante. Tentei aqui ser agnóstico de Sistema Operacional, portanto se aplica para qualquer SO que esteja instalado na sua máquina. No exemplo abaixo utilizei o Windows.
Sonarqube com Docker
A primeira forma é através do Docker. Então, é necessário que o Docker esteja instalado na sua máquina. Caso não tenhas o Docker, sugiro ir para a segunda forma de instalação do Sonarqube, logo mais abaixo.
Uma vez com o Docker instalado, basta executar o download da imagem que deseja utilizar.
docker pull sonarqube:6.7.7-community
No meu caso para tentar reproduzir o cenário mais próximo do pipeline utilizei a versão 6.7.7-community do Sonarqube. Este ponto é muito importante, porque caso a versão que você esteja usando no seu ambiente local, seja diferente da versão que é utilizada no servidor do pipeline de sua aplicação, pode ser que ocorra divergências de análises e regras que o Sonarqube aplica no seu código.
Vamos verificar se o download da imagem foi realizado com sucesso, para isso basta executar o comando:
docker image ls
Por fim é necessário iniciar a imagem.
docker run -d — name exemplo-sonarqube -p 9000:9000 sonarqube:6.7.7-community
Acesse o endereço http://localhost:9000 e você verá a imagem a seguir, a home page do Sonarqube. Caso ainda não apareça a imagem abaixo, é comum observar uma tela de loading.
Se você chegou até aqui, muito bem, você subiu corretamente SonarQube.
Sonarqube com Bat
Como falei anteriormente caso você não tenha o Docker instalado na sua máquina, esta é uma outra estratégia bastante interessante. No site https://www.sonarqube.org/downloads/, faça o download da mesma versão do Sonarqube, que foi comentado na etapa anterior.
Uma vez feito o download basta, descompactar o arquivo .zip, abrir a pasta onde foi descompactado e acessar /bin/<SEU-SISTEMA-OPERACIONAL>.
Caso o seus SO seja o Windows, de dois cliques no arquivo StartSonar.bat.
Caso contrário, se o seu SO seja Linux ou Mac rode o sonar.sh.
Ao executar tanto .bat ou .sh será inicializado o servidor do Sonarqube e, você verá a home page do Sonarqube.
Como tornei meu processo de desenvolvimento mais ágil com o Sonarqube?
Aqui, repito novamente a pergunta que é título deste artigo. A ideia é recapitular o que foi feito até aqui. Nós instalamos o Sonarqube que é uma ferramenta de qualidade e segurança de código.
Considerando que no pipeline da sua aplicação, há a etapa de análise de código, temos que ponderar alguns cenários. Normalmente, o pipeline é disparado considerando alguma condição do seu .gitlab-ci ou jenkins ao realizar alguma operação com git:
- merge request na master/main ou develop;
- Criação de uma tag;
- Criação de hotfix;
- Todo commit na develop;
Enfim “n” possibilidades que normalmente são convenções da squad. Porém, tais convenções precisam ser conhecidas por quem está desenvolvendo, caso contrário muito provavelmente haverá retrabalho.
Não entrando no mérito de certo ou errado, na minha situação, a convenção que tínhamos, o pipeline rodava apenas quando havia commit na master. O fato de haver apenas uma trigger para o pipeline, faz com que o processo de validação de qualidade seja tardio, o que pode comprometer a qualidade do código que vai para produção. Nesse momento o que acontece na prática:
- O build da sua aplicação concorre com outros runners;
- Após conseguir um runner disponível o pipeline demora;
- O build quebra porque o quality gate barrou o build;
Dependendo de quanto tempo demora o pipeline, as vezes pode demorar um bom período de tempo que pode onerar a produtividade. No momento em que temos Sonarqube local, com muito mais velocidade conseguimos identificar o seguinte:
- Bugs e vulnerabilidades em todo o seu código;
- Código duplicado referente ao novo código e total;
- Cobertura de testes referente ao novo código e total;
- Code smells;
Como base em todos estes apontamentos, é possível identificar todos os pontos de alerta/erro e antes mesmo de submeter o código para a branch master, já podemos trabalhar em todas as condições que impeçam o quality gate e corrigi-las. Ou seja, muito antes conseguimos apurar eventuais bugs, falta de cobertura de código, vulnerabilidade, código duplicado. Uma vez que corrigimos qualquer um destes, o código muito provavelmente estará mais seguro, limpo e com mais qualidade.
Resumindo
Neste momento estamos com o Sonarqube rodando localmente. Para não me estender muito mais, o próximo artigo vai mostrar como configurar o seu projeto para enviar as informações para o Sonarqube.
Abaixo fica um pequeno spoiler. Ah, e lembrem-se do Jacoco.
mvn clean install sonar:sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.login=admin -Dsonar.password=admin
