Você tem então seu projeto open source no Github e quer deixá-lo disponível para uso enquanto ele evolui. Isso é muito importante porque o quanto antes ele é utilizado, novas funcionalidades são testadas, bugs são encontrados, mais rápido o software melhora a cada dia. Os usuários podem ter novidades, que agreguem valor, constantemente, e os colaboradores do projeto podem ter o feedback necessário na mesma velocidade. Você pode até não saber o nome, mas o que você quer é implementar um processo de integração e entrega contínuas no ciclo de desenvolvimento do seu software, prática de quem adota DevOps.
O Github se integra a vários serviços distintos de integração contínua. Eles podem ser vistos em http://bit.ly/2yx6k9h. No exemplo dado aqui hoje vamos optar pelo Travis CI, gratuito para projetos open source. O projeto é o Logistics, uma aplicação Java EE (agora EE4J) que roda no Wildfly e usa um banco de dados MongoDB.
O Travis CI requer um arquivo no repositório, chamado .travis.yml. Um exemplo básico dele e mais informações para começar a usar o serviço podem ser visualizados em Getting started. Vamos conferir agora o que o .travis.yml do projeto Logistics instrui o Travis CI a fazer, sempre que um push é feito. Detalhes de como personalizar o processo pode ser conferido em Customizing the Build.
language: java
sudo: required
install: true
services:
- docker
addons:
sonarcloud:
organization: "gustavomcarmo-github"
jdk:
- oraclejdk8
script:
- mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar
- docker build --tag=esignbr/logistics .
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.sonar/cache'
after_success:
- "curl -T logistics-ear/target/logistics-ear-1.0-SNAPSHOT.ear -u $FTP_USER:$FTP_PASSWORD ftp://esign.com.br/appservers/wildfly-10.0.0.Final/standalone/deployments/"
- docker login -u="$DOCKER_USERNAME" -p="$DOCKER_PASSWORD"
- docker push esignbr/logistics
Definindo a linguagem de programação
É o primeiro passo, logo na linha inicial. No caso do projeto Logistics, é Java, mas poderia ser Python ou NodeJS. Nas linhas 12 e 13, é possível ainda especificar qual JDK será utilizada. Para compilar a aplicação, é necessária a versão 8.
Gerando os artefatos Java
Para implantar a aplicação Logistics no Wildfly, geramos o arquivo EAR, contendo o JAR do módulo backend do projeto (logistics-ejb) e o WAR do módulo frontend (logistics-web). Para isso, usamos o Maven, responsável essencialmente pela compilação, pela execução dos testes unitários e pelo empacotamento (package) necessário para a entrega. O Maven permite também a utilização de plugins, que estendem sua funcionalidade. Na linha 16 instruímos o Travis CI a executar o Maven (mvn) passando como parâmetro as tarefas a serem desempenhadas por ele.
Avaliando a qualidade do código
O Travis CI tem integração com o SonarCloud, instância do SonarQube na nuvem, disponível para avaliar projetos open source. O SonarQube é uma excelente ferramenta para analisar continuamente a qualidade do código Java e também de outras linguagens de programação. Ela tem uma funcionalidade chamada Quality Gate, que permite que critérios específicos de qualidade sejam definidos para considerar a aplicação apta para entrega. O Quality Gate usado pelo projeto Logistics é o default da ferramenta.
Para integrar ao Travis CI, primeiro é preciso se registrar no SonarCloud e criar um token de autenticação lá. Nas linhas 8 a 10 é configurado o addon do SonarCloud. Observe que é informada a organização que o identifica no serviço, mas não o token. O token é informado no Travis CI como variável de ambiente (SONAR_TOKEN), para não ficar explícito no arquivo .travis.yml.
Uma vez plugado o SonarCloud, basta instruir o Travis CI a rodar a análise do código fonte. Como estamos usando o Maven, e o plugin do SonarQube para o Maven, basta passar como parâmetro para o comando mvn a tarefa sonar:sonar.
Além disso, é preciso analisar a cobertura dos testes unitários, pois é critério de qualidade definido no Quality Gate padrão do SonarQube. Neste caso, usamos o JaCoCo, e seu plugin para o Maven, que executamos anteriormente à análise do SonarQube, ao passar org.jacoco:jacoco-maven-plugin:prepare-agent para o comando mvn.
Mais sobre a integração do SonarCloud ao Travis CI pode ser visto em Using SonarCloud with Travis CI. Os resultados das análises do código fonte da aplicação Logistics realizadas pelo SonarQube podem ser visualizados em https://sonarcloud.io/dashboard?id=br.com.esign%3Alogistics.
Gerando a imagem Docker
Uma alternativa à geração do EAR, que precisa ser implantado numa instância do Wildfly específica, é gerar a imagem Docker da aplicação com o Wildfly e a própria aplicação já embutidos. Neste caso, a aplicação e tudo que ela depende pra ser executada é empacotado junto numa imagem. Para rodar a aplicação, basta então rodar a imagem numa máquina que tiver o Docker instalado.
Para construir a imagem da aplicação Logistics, usamos como base a imagem jboss/wildfly, aplicamos a configuração necessária para acesso ao MongoDB, e implantamos o EAR gerado, conforme definido no Dockerfile. A construção é realizada na linha 17 do arquivo .travis.yml, a partir do comando docker build. A execução de comandos Docker é possível com a utilização do serviço informada nas linhas 5 e 6 e definindo o sudo como required, como aparece na linha 2. Mais informações de como usar o Docker no Travis CI podem ser visualizadas em Using Docker in Builds.
Entregando efetivamente o software
Após analisada a qualidade do software e gerados os artefatos necessários, a entrega pode efetivamente ocorrer. No arquivo .travis.yml, isso é definido em after_success (linha 24).
Primeiramente, o EAR é colocado via FTP no diretório de deployments do Wildfly que fica no nosso domínio (esign.com.br), como pode ser observado na linha 25. As credenciais para acesso ao nosso servidor são por questões de segurança obtidos de variáveis de ambiente. Com este deploy automático, estamos sempre disponibilizando a versão mais nova da aplicação em http://www.esign.com.br/logistics.
Por último, subimos para o Docker Hub a imagem Docker, como pode ser verificado nas linhas 26 e 27. As credenciais para login no Docker Hub são por questões de segurança também obtidos de variáveis de ambiente (linha 26). Com o push automático (linha 27), a última versão da imagem, com a última versão da aplicação, estará sempre disponível para download e execução em máquinas com Docker. O repositório da imagem no Docker Hub é https://hub.docker.com/r/esignbr/logistics.
Otimizando o tempo de build
O Travis CI permite ainda algumas configurações que fazem diminuir o tempo de build. Na linha 3 do .travis.yml, por exemplo, é desabilitada a etapa de resolução das dependências, quando normalmente muitos downloads acontecem. Além disso, com a definição do uso de cache (linhas 19 a 22), o Travis CI sabe onde buscar as dependências outrora baixadas, eliminando assim o download desnecessário.
À medida que o software cresce, é normal que o tempo de build aumente. Não são apenas mais linhas de código, mas novos testes unitários são realizados. De toda forma, é preciso acompanhar e controlar o tempo de build, para manter todo o processo saudável. Não se esqueça que o objetivo é ter feedbacks rápidos. Caso aumente demais, considere dividir o projeto. No caso do Logistics, os builds podem ser vistos em https://travis-ci.org/esign-consulting/logistics.
Conclusão
Esperamos que com este post você consiga implantar um pipeline de entrega do seu projeto open source. Mais do que isso, que você possa evoluí-lo e compartilhá-lo com a comunidade e conosco também. Nunca se esqueça que compartilhando nossas soluções é que mantemos sempre forte o movimento open source.
