Utilizando SonarQube como sua ferramenta de Code Smells + Cobertura de testes unitários em projeto Android parte 2
No post anterior que você pode ler aqui, eu iniciei o papo de como configurar o SonarQube no seu projeto Android de forma a aproveitar as ferramentas que ele proporciona como métrica para verificar a integridade/qualidade do seu código.
Neste post eu irei explicar em como alimentar esse código com o Github Actions e como mensurar suas alterações conforme as alterações são feitas e seus impactos no dia a dia.
Alimentando o SonarQube
Após você realizar todas as suas configurações no projeto e antes de realizar a integração com o Github Actions, você precisa determinar qual é a base de código em que ele se baseará para comparação e como ele irá demonstrar ao longo prazo a evolução do projeto.
Após as configurações, você deve rodar o seguinte comando Gradle no terminal onde está a raiz do repositório, onde no post anterior são as chaves mencionadas de forma de autenticação que serão feitas no servidor onde está rodando o SonarQube.
./gradlew sonarqube -Dsonar.projectKey=projectKey -Dsonar.host.url=hostUrl -Dsonar.login=loginCom base na configuração do post anterior, essa task irá limpar reports antigos, compilar o projeto, rodar os testes unitários, gerar os relatórios com base nas suas configurações do JaCoCo e posteriormente irá submeter esses reports para o SonarQube gerar o report.
Após este envio ao analisar o seu painel do SonarQube irá poder ver aproximadamente um exemplo de como seu código está determinado com as configurações.
Com base nesse código podemos ter as seguintes métricas:
- Não há nenhum bug de lógica que pode gerar resultados inesperados (como por exemplo uma condicional if onde os dois valores são verdadeiros).
- Não há nenhuma vulnerabilidade de segurança (tokens expostos, senhas, chaves de segurança colocadas diretamente no código).
- Cinco dicas de problemas de segurança que podem ser ajustados visando uma proteção melhor de código.
- 29 dias de débito técnico, ou seja, problemas que podem gerar um impacto no futuro e que devem ser analisados).
- 925 code smells, códigos que estão duplicados ou que podem gerar comportamentos inesperados.
- 43,5% de cobertura de testes, ou seja, das 102 mil linhas de código presentes na aplicação 39 mil linhas de código (43,5%) do código está coberto e aqui adiciono um parênteses pois esse numero pode ser um falso positivo, visto que no Android este valor pode estar representando Fragments, telas com JetPack Compose entre outros cenários.
Criando uma ação de Pull Request no Github Actions
Após realizar essa alimentação inicial no SonarQube, precisamos criar uma ação no Github Actions (ou no seu CI de preferência) para que quando um Pull Request for aberto ele rode a tarefa de gerar os reports e enviar esses reports para o SonarQube.
No exemplo acima, eu realizo a ação de a cada Pull Request para minha branch de desenvolvimento eu rodo uma task do Gradle passando os parâmetros necessários para alimentar o SonarQube com os reports dos testes unitários e outras informações para análises de código e caso tudo de certo eu utilizo uma outra ação para notifica via Slack (canal de comunicação da empresa) para avisar se o build passou com sucesso ou falha.
Como podemos perceber no passo de rodar a tarefa do Gradle, eu insiro alguns parâmetros de Pull Request, como para qual branch ele irá ser mergeado, qual o id da tarefa no Github entre outros identificadores que informam ao SonarQube que a tarefa está rodando em um contexto de Pull Request.
Um ponto importante que vale a pena destacar é que, como pode haver vários commits em um Pull Request e visando não gerar gastos desnecessários no Github Actions, eu coloquei que, se haver uma nova action rodando com o mesmo Pull Request ele cancela esta ação atual para manter a mais atualizada rodando, isso ajuda também a não ter vários reports desnecessários sendo inseridos no SonarQube.
Configurando auto alimentação do SonarQube
Finalizando os passos para uma integração com o SonarQube, devemos criar uma action no Github Actions ou no CI de preferencia que atualize a base de código atualizada no SonarQube para que esta nova base de código sirva de parâmetro para Pull Requests futuros.
Ela não difere muito da ação de Pull Request, sendo a única diferença entre elas é que nela não iremos enviar os parâmetros identificadores de Pull Request na hora da tarefa do Gradle, desta forma o SonarQube irá identificar como uma atualização da base de código do projeto.
Conclusão
O SonarQube é uma ferramenta extremamente poderosa para métricas e analise de código para desenvolvedores que buscam se aperfeiçoar como profissionais e também muito útil para empresas que buscam quantificar suas entregas e como elas podem melhorar e evoluir na visão de produto e quão saudável a aplicação irá se manter a longo prazo.
Até a próxima 😃.
