Integração Contínua / Entrega Contínua — Parte 3
- Parte 1 — Início
- Parte 2 — Jenkins Pipeline
- Parte 3 — Análise Estática de Código
- Parte 4 — Entrega com Ansible (AWX)
Sobre Qualidade de Código…
Qualidade de código é algo difícil de mensurar. Assim como existem milhares de desenvolvedores, exitem milhares de opiniões a respeito do quê significa ter um código de qualidade. Em sua forma mais básica, pode-se dizer que qualidade de código engloba um sistema desenvolvido de acordo com as especificações do usuário e que atende suas necessidades. De fato, para que tenha qualidade, um software deve, no mínimo, atender os anseios de quem o está utilizando, mas nem só de “resolveu” se faz qualidade.
Alguns aspectos que considero como fatores importantes na qualidade do código são:
- Facilidade de leitura, consistência — Códigos bem estruturados e que seguem um padrão de desenvolvimento (nomeclaturas, formatação) são mais fáceis de entender. Idealmente, o código deve ser escrito pela equipe como se tivesse sido escrito por uma só pessoa.
- Previsibilidade, confiabilidade, robustez — A execução da aplicação deve ser previsível, e não deveria conter comportamentos estranhos. O estado da aplicação e de seus dados deve ser confiável, não deveria poder chegar a um estado não desejado.
- Manutenabilidade, extensibilidade — A maioria dos sistemas tem um tempo de vida útil bastante superior ao seu tempo de produção. O código deve ser feito de forma que seja fácil consertar eventuais falhas, e que seja rápido a adição de novas funcionalidades
Importância da Qualidade de Código
Ok, já deu pra ter uma noção do que significa qualidade de código, mas, qual é exatamente a importância do desenvolvimento de código com qualidade? Vamos lá.
Imagine o desenvolvimento de seu sistema. Os prazos são curtos, as mudanças são constantes, não há tempo para pensar muito a respeito da melhor forma de organizar as coisas. No início, enquanto poucas linhas foram escritas, o custo da mudança é baixo, a equipe ainda está desenvolvendo então todos entendem exatamente o que o sistema está fazendo.
Agora imagine que este sistema foi concluído e está em produção, outra equipe é responsável pela manutenção deste sistema e pela adição de novas funcionalidades. Neste momento todas as boas práticas não usadas voltam para te assombrar.
Este é basicamente o conceito de débito técnico. Todas as vezes que você resolve dar um “jeitinho” para fazer as coisas funcionarem, você adiciona mais ao débito técnico, e assim como sua contraparte financeira, há um juros cobrado em cima deste débito, as manutenções são mais vagarosas, e o entendimento é prejudicado.
Análise Estática de Código
Análise estática de código é a análise do código sem que seja feita a execução do mesmo, e isto é feito analisando o código de acordo com um conjunto (ou vários conjuntos) de regras. No caso deste projeto, todo este processo de análise será feito automaticamente pela ferramenta SonarQube. Sem mais delongas, vamos à prática.
Criação e configuração do SonarQube
Antes de tudo, vamos precisar criar uma nova rede no docker, para que containers criados pelo jenkins possam ser inseridos nesta rede e ter acesso ao sonar.
docker network create cicdComo de praxe, vamos usar docker para criar o serviço do SonarQube. Então temos que modificar o docker-compose.yml:
Obs.: Em um ambiente de produção, o SonarQube precisa de conexão a um SGBD (Mysql, postgres, etc).
Perceba que no arquivo foi adicionado também a propriedade networks. Isso permite que os containers deste compose usem a rede que criamos anteriormente.
Agora ligue o servidor:
docker-compose up -dCom o servidor executando, acesse em http://localhost:3080. O login padrão é admin:admin.
Precisamos configurar um webhook no sonar, para que ele possa ‘avisar’ o jenkins assim que finalizar a análise do código. Navegue até Administration, clique em Configuration e selecione Webhooks. Clique no botão create e insira a seguinte configuração:
O link deve estar exatamente como é mostrado na imagem, ou não vai funcionar. A barra no final é obrigatória. Clique em Create.
Para que o sonar faça análise de branches diferentes, precisamos de dois plugins. Faça o download do arquivo jar do plugin de branch aqui e cole na pasta “sonarqube/extensions/plugins” (este é o volume ligado ao container do sonar, crie a pasta plugins se não existir). Para instalar o plugin da linguagem (TypeScript), navegue até Administration — Marketplace, procure por SonarTS e clique em Install.
Reinicie o servidor do sonar:
docker-compose restart sonarqubeE pronto. Finalizamos com o sonar. Agora precisamos instalar alguns plugins no jenkins. Acesse o jenkins em http://localhost:2080 e navegue até Manage Jenkins — Manage Plugins — Available, pesquise pelo plugin SonarQube Scanner, selecione o plugin e clique em Install without restart.
Precisamos também do plugin Cobertura. Faça o mesmo procedimento para instalar este plugin. Navegue até Manage Jenkins — Configure System e procure pelo campo SonarQube Servers. Faça a configuração conforme a imagem abaixo:
Clique em Save. Agora navegue até Manage Jenkins — Global Tool Configuration e procure SonarQube Scanner. Clique em Add SonarQube Scanner e faça a configuração conforme a imagem:
Clique em Save. Tudo pronto no Jenkins e no Sonar, agora só falta fazer algumas modificações no projeto. Vá até seu projeto (na branch master) e modifique seu Jenkinsfile para ficar assim:
Algumas explicações:
É possível usar scripts em Groovy para executar algumas ações no Jenkinsfile. Foram usadas duas funções para verificar a branch e passar configurações no CLI do sonar de acordo. No caso da property “sonar.branch.target”, só há necessidade de existir caso seja uma branch temporária, ou seja, qualquer branch diferente de master ou development, para que o sonar consiga saber em qual branch será feito o merge quando a funcionalidade da branch temporária for finalizada.
A property “sonar.branch.name” é usada para que o sonar saiba qual branch está sendo analisada, não sendo necessária para a branch master, que é a padrão.
Note que foi alterado o agent padrão. Usando o agent none, temos que especificar em cada estágio o agent que será usado para executar os passos. Note também que na linha 38 foi passada a rede como argumento, para que este container possa ter acesso ao servidor do sonarqube.
Na linha 30, foi adicionado o CoberturaPublisher. Após o estágio de teste, os resultados de cobertura de teste serão salvos no Jenkins. No passo seguinte, o sonar usa estes resultados em sua análise. Logo em seguida foi adicionado o passo waitForQualityGate, isso significa que o jenkins espera pelos resultados do sonar, e caso a análise indique que o padrão desejado não foi atingido, o processo será interrompido e sinalizado como falha.
Finalmente, crie um arquivo chamado sonar-project.properties conforme o trecho:
E é isso! Tudo pronto! Vamos ver a mágica acontecer! Faça um commit, dê seu git push e assista 😎
Obs.: Garanta que você está na branch master! A primeira análise deve ser, obrigatóriamente, na master!
Se tudo correu bem, o processo no jenkins será concluído com sucesso. Acesse o sonar em http://localhost:3080 e navegue até Projects. Você verá que seu projeto foi adicionado na lista automáticamente. Clique no projeto para ver os detalhes da análise.
O sonar já possui diversas regras pré configuradas para diferentes linguagens (através dos plugins). Análise de falhas de segurança, confiabilidade, manutenabilidade, e porcentagem de cobertura de teste no código. Você pode também criar seus próprios padrões de qualidade e métricas de aceitação de acordo com sua demanda.
Até agora conseguimos construir uma pipeline de integração do código de seu projeto desde o git, sendo automáticamente testado no jenkins e estáticamente analisado pelo sonar!
E por enquanto é isso, já estamos bem próximos do que foi definido no início do projeto, só precisamos fazer esse código chegar no servidor 🤘
Mas isso vai ficar pra outro artigo, até a próxima!
