DevSecOpsARTIGO

Spring Boot na nuvem, de graça, e com as melhores práticas

Minha intenção aqui é fazer um guia rápido baseado na experiência que tive ao colocar um projeto 100% na nuvem com a melhor engenharia possível e gratuita.

Pode ser que para muitos eu esteja fazendo chover no molhado, mas não custa nada procurar ajudar os mais atrasados que estão batendo cabeça por aí – assim como eu até pouco tempo atrás.

Minha intenção aqui é fazer um guia rápido baseado na experiência que tive ao colocar um projetinho 100% na nuvem com a melhor engenharia possível (ao meu alcance, claro!) e de maneira gratuita.

Vamos dividir esse post em 2 partes. São elas:

  • Parte 1 – Vincular o build do seu projeto ao Travis-CI e usar o Codacy.com para análise estática e cobertura de código
  • Parte 2 – Fazer o deploy do projeto no Heroku

Para alcançar o objetivo, vamos precisar das seguintes ferramentas:

Criando suas contas nos serviços que serão utilizados

Para quem ainda não tem conta no GitHub, basta fazê-la aqui. A sua conta do GitHub será utilizada também para acessar o Travis-CI.

image19

Vou assumir aqui que você já tem seu repositório no GitHub criado e com seu código por lá, para acelerar um pouco as coisas.

No Travis-CI, agora é hora de ativar seu repositório, para que o mesmo seja escutado. Para isso, basta clicar no “+”.

image09

Depois pode ser que seja necessário sincronizar seus repositórios, caso eles não estejam aparecendo.

image05

Com os repositórios já sincronizados, basta ativar o desejado:

image12

Um dos principais arquivos que dará vida ao seu projeto na nuvem é o .travis.yml. É nele que estarão as instruções necessárias para o build, upload de cobertura de código e deploy no heroku. Vamos incrementá-lo aos poucos, começando pelo básico.

Como vou usar Gradle e Oracle Java 1.8 para o projeto de exemplo, teríamos um .travis.yml no seguinte formato:

language: java
jdk:
- oraclejdk8
before_cache:
- rm -f $HOME/.gradle/caches/modules-2/modules-2.lock
cache:
  directories:
  - "$HOME/.gradle/caches/"
  - "$HOME/.gradle/wrapper/"

Prontinho! Agora é só commitar o .travis.yml para o seu repositório que os commits subsequentes serão escutados pelo Travis-CI, que executará o build.

image15

Aí, é só acompanhar o build do seu projeto por lá.

O próximo passo é configurar seu projeto para vermos as análises estáticas e cobertura de código.

Você precisará importar o projeto, usando o  próprio GitHub:

image11-700x511

image02-1 (1)

Agora o Codacy vai analisar um a um os commits feitos no repositório. Pode ser que demore um pouco – tudo dependerá do volume do seu repositório. Mas no final da análise você terá no dashboard do projeto algumas métricas, como podemos ver abaixo:

image16

Ué? Parece que ainda estamos sem cobertura de código… Então, vamos consertar isso aí!

O Codacy.com aceita reports de cobertura de código gerados pelo JaCoCo. Sendo assim, vamos adicionar o plugin, definir e colocar uma dependência no nosso build.gradle para o JaCoCo, conforme abaixo:

...
apply plugin: 'jacoco'
...
jacocoTestReport {
    reports {
        xml.enabled = true
    }
}
check.dependsOn jacocoTestReport
…

Precisamos também adaptar o .travis.yml para comportar a cobertura de código, conforme abaixo:

sudo: required
language: java
jdk:
- oraclejdk8
before_install:
- curl -sL http://bit.ly/jpm4j >jpm4j.jar
- sudo java -jar jpm4j.jar -g init
- sudo jpm install com.codacy:codacy-coverage-reporter:assembly
before_cache:
- rm -f $HOME/.gradle/caches/modules-2/modules-2.lock
cache:
  directories:
  - "$HOME/.gradle/caches/"
  - "$HOME/.gradle/wrapper/"
after_success:
- codacy-coverage-reporter -l Java -r build/reports/jacoco/test/jacocoTestReport.xml  --p

Ps.: dependendo dos classpaths do seu projeto, o valor do parâmetro –prefix pode precisar ser alterado.

Antes de commitar as alterações do build.gradle e do .travis.yml, vamos fazer o setup da cobertura no Codacy.com e definir uma variável de ambiente no Travis-CI.

image04 (1)

image06-1 (1)

Com este valor que foi copiado, vamos criar a variável no Travis-CI, dentro das configurações do projeto:

image18

O nome da variável é CODACY_PROJECT_TOKEN e o valor, bem… é o copiado do Codacy.com

image00-1

Agora, com a variável definida, podemos commitar as alterações feitas no build.gradle e no .travis.yml.

Pronto! Agora é só esperar o fluxo Travic-CI → Codacy.com acontecer e teremos o dashboard do projeto atualizado com a cobertura de código.

image21

Assim, temos CI e análise de código rolando. Vamos mostrar isso no GitHub.

Para tal, basta criar ou alterar o README.md do projeto no GitHub e adicionar as badges:

image17

No Travic-CI você consegue aqui:

image20

E no Codacy.com aqui:

image01-1

Agora você ostentará as badges no seu repositório do GitHub.

Tudo bem até aqui? Se ficou alguma dúvida ou esbarrou em algum passo, deixe um comentário aqui embaixo. Na parte 2 vamos, finalmente, fazer o deploy do projeto no Heroku.

Até lá!

é líder de Capítulo Java na Concrete Solutions, ex-jogador de World of Warcraft recuperado do vício, atualmente jogando Heroes of the Storm e curte brincar com a família de Arduínos em casa.

Ver perfil