Com o projeto no GitHub, vamos adicionar o suporte ao Travis no projeto. Na opção
settings do seu projeto, selecione o item
Integrations & Services, opção
Add Service,
e selecione
Travis CI.
 |
| Adição do Travis CI no projeto do GitHub |
Serão solicitadas informações da sua conta do Travis CI. Você precisa de uma conta pois é lá que os testes da sua aplicação irão rodar. Então, vamos pausar a configuração no GitHub e criar a conta no Travis CI através
desse link. Para não precisar criar uma conta e vincular os seus repositórios rapidamente, selecione a opção
Sign in with GitHub e autorize o Travis a buscar informações dos seus repositórios. Você verá que ele vai exibir os repositórios que você possui e vai permitir o gerenciamento dos mesmos.
 |
| Página inicial do Travis |
Para permitir o acesso do Travis ao seu repositório, selecione a opção de habilitação ao lado do nome do repositório. Após clicar, ela irá aparecer verde, indicando a habilitação.
 |
| Habilitação do Travis no projeto mavenquickstart |
Se você acessar novamente a opção
settings do projeto do GitHub, no item
Integrations & Services vai aparecer como pré-configurado o Travis CI, ou seja, você não vai mais precisar configurá-lo lá no GitHub, o Travis fez isso por você. Agora só falta adicionar o arquivo de configuração do Travis ao projeto. Vamos criar um arquivo
.travis.yml com o seguinte conteúdo:
1
2
3
4
5
| language: java
jdk: oraclejdk10
script:
- mvn clean install
|
Feito isso, commite a mudança e realize o push do conteúdo no projeto remoto. Você vai ver que esse push disparará um build do Travis, e o commit será sinalizado com uma bolinha que ao ser clicada encaminha o usuário a página do Travis que realiza o build. O resultado deverá ser um build de sucesso, como exibido na imagem abaixo.
 |
| Build de sucesso no Travis |
Na imagem do build aparece uma
badge que indica que o build foi realizado com sucesso:
Vamos adicionar essa badge a um arquivo README do projeto, assim todos poderão ver que o seu projeto é testado e passou nos casos de teste elaborados. Clique no botão que exibe a badge, algo como o da figura acima e na caixa de diálogo selecione a opção
Markdown, que é o formato no qual escreveremos o arquivo README.
 |
| Badge do Travis |
Copie o conteúdo gerado na última caixinha e cole no arquivo README.md, que será criado no diretório raiz do projeto. Após realizar o push, acesse a página inicial do seu projeto no GitHub para visualizar a badge. O ideal mesmo é que você adicione mais informações no arquivo README, leia
esse post caso deseje se aprofundar no assunto.
 |
| Badge do Travis no GitHub |
Pronto, o Travis está configurado no seu projeto e sempre que você realizar um commit um build será disparado e a badge automaticamente atualizada dependendo do resultado do build.
SonarLint
O
SonarLint é uma ferramenta de análise estática que pode ser adicionada como plugin do Eclipse para que você possa prevenir problemas no seu projeto que podem ocorrer devido a más práticas de programação. A análise do Sonar é feita com base em regras definidas para o projeto, que seriam as métricas de qualidade da organização. Essas métricas possuem configuração padrão, com base nas métricas adotadas no mercado, mas é possível configurá-las para adequá-las a realidade da organização. Usar uma ferramenta como essa num projeto é uma forma de garantir que as métricas de qualidade do projeto sejam atendidas, por isso ela é bastante atrativa.
Vamos adicionar o plugin no Eclipse para que vejamos a análise em tempo de desenvolvimento. Para isso, acesse o menu
Help > Marketplace e digite
SonarLint. Siga os passos de instalação e reinicie o Eclipse. Quando você fizer isso, vai encontrar uma opção de análise clicando com o botão direito no projeto e acessando
SonarLint > Analyze.
 |
| Imagem do relatório do SonarLint no Eclipse |
Todas as issues do projeto serão listada com base nas regras padrão para um projeto Java. Você também pode redefinir as regras se desejado, ligando o seu SonarLint a um
SonarCloud ou
SonarQube, mas veremos isso depois de configurar um servidor no SonarCloud.
Para adicionarmos a análise do Sonar no Maven, vamos informar uma goal específica e adicionar o comando de build no arquivo do Travis. Assim, os builds vão disparar a análise estática. Ainda é necessário informar qual servidor irá rodar essa análise, pois é necessário ler as regras de qualidade definidas. Uma forma de fazer isso sem precisar levantar um servidor local é através do
SonarCloud, que permite que você use uma máquina da nuvem para executar as análises. Para isso, é só criar uma conta selecionando a opção
Sign In e vinculando a conta ao GitHub. Autorize o SonarCloud para que seja possível realizar a análise dos seus projetos. Feito isso, vamos acessar a lista de organizações e copiar a key da organização que foi criada, para informar ao Travis CI que ela será utilizada na análise. O arquivo final ficará da seguinte forma, considerando a minha
organization no SonarCloud:
1
2
3
4
5
6
7
8
| language: java
jdk: oraclejdk10
addons:
sonarcloud:
organization: "condessalovelace-github"
script:
- mvn clean install sonar:sonar
|
Depois de atualizar o conteúdo do seu arquivo
.travis.yml, realize o commit e o push no Git para disparar um build no Travis. Como esperado, será possível visualizar um erro de autorização no Sonar:
1
| Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.4.0.905:sonar (default-cli) on project mavenquickstart: Insufficient privileges
|
Esse erro ocorre pois é necessário informar o token de autenticação no SonarCloud, para garantir que ninguém simplesmente está usando a sua organização para analisar os seus projetos. O Token só poderá ser visualizado uma vez, então copie o seu conteúdo e vamos informá-lo ao Travis CI. Isso poderia ser feito no arquivo
.travis.yml mas não seria recomendado já que você deixaria o token exposto no controle de versão. A forma elegante e segura de configurar isso é através de
environment variables do Travis. Vamos criar uma variável chamada
SONAR_TOKEN. Para isso, acesse o Travis na página do build do seu projeto. Selecione o menu
More options > Settings ou se estiver na lista dos projetos, selecione a engrenagem
settings. Ao selecionar, você visualizará uma seção com o nome
Environment Variabbles que permitirá que você adicione variáveis de ambiente que serão usadas no build do Maven. Então, vamos adicionar a variável SONAR_TOKEN e colocar o valor dela, que poderá ser obtido no SonarCloud através da opção
My Organizations > Security > Generate Tokens. Informe o nome do token que será associado ao hash gerado, e
copie esse hash com a opção Copy, não o nome que você digitou, para colar no valor da variável SONAR_TOKEN.
 |
| Adição do SONAR_TOKEN no Travis |
Feito isso, vamos voltar para o build mal sucedido do Travis e selecionar a opção
Restart build.
 |
| Restart do build que falhou |
O build será realizado com sucesso e agora você poderá visualizar no SonarCloud o seu projeto analisado através do menu
My projects > mavenquickstart.
 |
| Análise do projeto mavenquickstart no SonarCloud |
Para finalizar, vamos recuperar a badge do Sonar, que pode ser obtida pela opção
Get project badges na página do projeto no SonarCloud. Copie a url gerada, adicione ao lado da badge do Travis. Como o arquivo é no formato Markdown, vamos adicionar uma legenda para a figura. No caso do meu projeto, vou adicionar o seguinte trecho da badge do SonarCloud:
1
| 
|
Lembre que você precisa ajustar a url para o seu projeto no SonarCloud. Finalmente, commite o README.md alterado. Após realizar o push, você visualizará a badge no projeto do GitHub.
 |
| Badge do Sonar no projeto do GitHub |
Você poderá editar falso positivos da análise caso o projeto não passe devido ao critério de qualidade, ou configurar no arquivo pom.xml a exclusão de pacotes que não devem ser considerados na cobertura, como por exemplo pacote de POJOS. O SonarCloud também permite que você customize os parâmetros da análise estática de acordo com as métricas de qualidade da organização. Você também pode criar várias organizações com
Quality Profiles específicos para permitir o uso de regras de análise diferentes para cada contexto de desenvolvimento.
Para finalizar, vamos ajustar nosso plugin SonarLint para usar as mesmas regras definidas no SonarCloud. Clique com o botão direito do mouse no projeto e acesse
SonarLint > Bind to a SonarQube project. Feito isso, na janela de diálgo aberta, selecione a opção
Connect to a SonarQube server..., e selecione a opção SonarCloud, que foi o servidor que criamos. Selecionando
Next>, será solicitado que você informe aquele token que você gerou para organização. Copie aquele hash e cole no campo solicitado. Se não tiver anotado, não tem problema, gere outro token para o Eclipse. Após isso, informe o nome da
organization, como é um campo autocomplete é só digitar uma parte do nome e selecionar a opção correspondente. Selecione
Next > Finish e pronto. Agora só falta adicionar a
project key do seu projeto, que pode ser encontrada na página dele no SonarCloud. Selecione
Finish e pronto! Você verá na lista de servidores a conexão configurada para o projeto no SonarCloud.
 |
| Servidor SonarCloud no Eclipse |
Vamos customizar um
Quality Profile no SonarCloud para remover essa regra do
System.out. Acesse a página do projeto, menu
Quality Profiles. Procure o profile do Java, e selecione a engrenagem ao lado, opção
Copy. Você deverá informar um nome para o seu profile customizado, vou chamar o meu de
Java Custom. Confirme a operação selecionando a opção
Copy e pronto! É só visualizar o profile customizado.
 |
| Java Custom profile do SonarCloud |
Agora vamos procurar aquela regra do Sonar do System.out, selecione o número ao lado do campo Code Smells, selecione a opção Show more no fim da lista de code smells e procure pela regra Standard outputs should not be used directly to log anything. Selecione a opção Deactivate e confirme a operação. Ainda na página do projeto no SonarCloud, selecione Administration > Quality Profiles, e selecione Java Custom na linguagem Java. O seu projeto usará o profile customizado.
 |
| Seleção do profile customizado para o projeto no SonarCloud |
Para disparar uma nova análise, vamos restartar o último build do projeto no Travis, aguardar o término e finalmente verificar o resultado no projeto do SonarCloud.
 |
| Análise do SonarCloud sem issues |
De fato a issue sumiu, agora só falta sincronizar no SonarLint do Eclipse, selecionando a aba SonarQube Servers, clicando com o botão direito do mouse na conexão e selecionando a opção Update all project bindings. Agora, rode uma nova análise do Sonar no projeto (Botão direito do mouse no projeto > SonarLint > Analyze). Nenhuma issue será exibida no relatório!
 |
| Relatório do SonarLint sem erros |
Com essa configuração, sempre que você estiver desenvolvendo, já visualizará as issues do Sonar que foram configuradas no servidor da sua organização (SonarCloud ou SonarQube). Mas lembre de atualizar o biding regularmente para trazer possíveis mudanças nos profiles de qualidade.
Conclusão
Fiz esse post com o propósito de mostrar como garantir que o seu projeto esteja estável (testes) e fácil de manter (métricas de qualidade). Para isso, apresentei duas ferramentas, o Travis CI e o SonarLint. Espero que você as use a partir de agora nos seus projetos e dissemine a adoção de boas práticas e inclusão de testes nos projetos dos seus amigos desenvolvedores.
Referências
Comentários
Postar um comentário