Fala galera, beleza?

Você ainda roda, de forma manual, bons e velhos scripts para por sua aplicação em produção? É chato ter que alterar os arquivos de configuração toda vez que precisa modificar o ambiente? Que tal descomplicar e deixar tudo isso automatizado de verdade? Tá parecendo venda de produto pirata né? Hehehe… Mas é só um post sobre integração contínua!

Vamos falar um pouco sobre como fazer integração contínua por meio do Travis-CI e realizando o deploy no Heroku. Como exemplo, vamos utilizar um sisteminha de Tarefas feito com Spring Boot e a camada de visão com AngularJS. Em um futuro não muito distante, falarei um pouco sobre as maravilhas do Spring Boot, mas, hoje, vamos focar nessa danada de integração contínua.

Integração Contínua

O que é? O que come? Para que serve? Veja no novo post do Gabriel Feitosa =)

Muita gente ainda se pergunta no que a integração contínua pode auxiliar no processo de entrega, mesmo se ainda trabalhar com a velha forma cascata  (sim, infelizmente ainda hoje tem muita gente entregando software assim).

Geralmente, associamos a integração contínua somente as metodologias ágeis. Afinal, foi por causa da necessidade de disponibilizar os softwares de maneira rápida, contínua e com qualidade, que se tornou indispensável integrar o que é produzido ao que é entregue.

Uma pergunta para responder em nossas cabeças: quando fazemos um bom trabalho, gostamos de ter um feedback/elogio do nosso chefe, ou não? Pois é, o nosso software também é sentimental. A integração contínua é a maneira mais prática de dar um feedback instantâneo para nosso sistema e, sem ser egoístas, para nós mesmos.

Funciona assim, faço meu código, depois dou o commit no repositório, o processo de build é iniciado, os testes são executados e, se houver falhas, elas serão expostas. Simples, rápido e sem dor. Opa, vão ficar sabendo que comitei sem rodar os testes, isso não é legal!!! Mas é CLARO que é legal meu amigo, já imaginou se você envia esse seu código para homologação e na hora do usuário testar ele não funciona ou se vai direto para produção? Seria muito pior, não?

Para nosso exemplo, vamos usar um repositório no Github. O Travis-CI irá escutar este repositório e sempre que houver mudança executará o processo de build e fará o deploy no Heroku.

Travis-CI

Como mencionei acima, o Travis será nossa aplicação de integração contínua. Ele é gratuito para projetos públicos, caso você queira usá-lo para projetos privados, porém, é necessário pagar. Tem uma documentação muito rica que pode ser vista aqui.

Uma vez logado, vamos informar ao Travis qual o repositório do Github ele escutará. Para isto, dentro do dashboard vamos adicionar um novo repositório, conforme imagem abaixo:

Adicionar novo repositório ao travis

Em seguida, você será redirecionado para a tela do seu profile, onde você poderá escolher qual repositório irá escutar. Neste exemplo, a integração será realizada no repositório gabrielfeitosa/ci-spring-boot.

Para que o Travis saiba o que fazer com os fontes do repositório, vamos precisar criar um arquivo na raiz do nosso projeto chamado .travis.yml. Este arquivo conterá os passos que deverão ser seguidos para realização da integração contínua.

1
2
3
4
5
6
7
8
language: java
jdk:
 - oraclejdk8
deploy:
 provider: heroku
 api-key: 
  secure: $HEROKU_API_KEY
 app: ci-spring-boot

No gist acima, informamos que a linguagem que o projeto usa é Java 8. O Travis já disponibiliza um provider, de forma nativa, para realizarmos o deploy no Heroku. Para liberar o acesso ao Heroku, precisamos informar a nossa chave de acesso api-key>secure e qual o nome da app.

Perceba que estou utilizando uma variável de ambiente para informar qual a minha chave de acesso ao Heroku. Vamos criar uma variável de ambiente, para isso basta ir nos settings e adicioná-la, conforme figura abaixo:

Configuração do repositório no Travis

As configurações do Travis estão feitas, viu como foram simples? Todo commit que for feito iniciará o processo de integração contínua. No dashboard você poderá acompanhar o log do build da sua aplicação.

Agora, vamos ver como é fácil configurar o Heroku para que o deploy possa ser realizado.

Heroku

Para quem não conhece, o Heroku é um PaaS que pode ser utilizado para expor seu sistema na web. Ele pode ser usado de forma gratuita ou pode-se optar pelos planos pagos.

Para iniciar, vamos logar/criar uma conta. Depois, dentro do dashboard  vamos criar uma nova app. Para criar o processo é bem simples, basta informar o nome da aplicação e selecionar a região em que ela será executada:

Criar nova app no heroku

O nosso ambiente de desenvolvimento utiliza o banco de dados em memória h2. Porém, o Heroku não dá suporte e ele não é recomendado para ser utilizado em produção. Lembre-se, o Heroku será o nosso servidor de produção. Então, vamos adicionar o banco de dados Postgresql a nossa aplicação.

Na tela de informações da nossa aplicação, vamos adicionar o Postgresql. Basta informar o nome do add-on e selecioná-lo, conforme tela abaixo:

Adicionando postgresql a aplicação no Heroku

Pronto! A configuração está concluída, foi simples não? Agora, só mais algumas observações:

  • Ao adicionar o Postgresql, a variável de ambiente DATABASE_URL é automaticamente criada. Ela será utilizada nas configurações de acesso ao banco de dados da nossa aplicação.
  • É necessário criar o arquivo Procfile na raiz do projeto, ele conterá as informações que serão utilizadas pelo Heroku para fazer o deploy.
  • Na figura acima, perceba que há uma linha com o comando web: java -Dserver.port=$PORT -jar target/ci-spring-boot-0.0.1-SNAPSHOT.jar -Dspring.profiles.active=prod. Esse comando é o que está dentro do Procfile.
  • Perceba que estou utilizando o parâmetro -Dspring.profiles.active=prod. Ele será usado pelo Spring para utilizar o profile prod. Esse profile pode ser visto no arquivo src/main/resources/application-prod.properties.

[Spring Boot] O Spring Boot é um baita projeto da galera do Spring, que vem para auxiliar e facilitar o processo de configuração da aplicação, estabelecendo configurações defaults. Não quis entrar em detalhes, pois em breve farei um post exclusivo sobre o tema. Abaixo, os profiles que utilizei no projeto. Dentro de src/main/resources há 3 arquivos de configuração do Spring Boot:

  1. application.propertie: usei unicamente para definir qual o profile padrão (dev);
  2. application-dev.properties: possui as configurações do profile dev;
  3. application-prod.properties: possui as configurações do profile prod; Então, sempre que quisermos executar o sistema com um profile diferente do padrão, temos que passar o parâmetro spring.profiles.active para que o Spring sobrescreva o valor default a ser utilizado. Há ainda um 4º arquivo de propriedades que é o utilizado nos testes: src/test/resources/application.properties.

Uma vez que todos esses passos forem feitos, nosso sistema terá o deploy realizado a cada commit. Se tudo ocorrer bem, o nosso sistema poderá ser acessado na url https://ci-spring-boot.herokuapp.com. Perceba que o Heroku disponibiliza a url com o mesmo nome da app criada, nesse caso ci-spring-boot .

Só para recapitular, sempre que fizermos um commit, _o Travis irá compilar nosso código e rodar os testes. No exemplo, criei um teste de integração só para exemplificar. Em seguida, se tudo ocorrer conforme esperado com os testes, a aplicação será enviada ao Heroku para ser exposta na _web.

Agora diz aí, foi fácil ou não foi?

Há uma porção de ferramentas de integração contínua no mercado, como o jenkins e o wercker. Também há outros PaaS bem populares na comunidade, por exemplo o OpenShift, Google App Engine e o AWS.

O código fonte do exemplo pode ser visto no repositório gabrielfeitosa/ci-spring-boot.

Por hoje é só galera.

Abraços e até a próxima!