Integração contínua com Travis CI

Uma das lições que aprendi durante minha carreira foi o quão importante é realizar entregas com qualidade e em tempo razoável. Quanto mais tempo você passa com sua feature branch em sua máquina, maior será a probabilidade de ter dor de cabeça ao realizar o merge com a branch principal do projeto.

Outra lição aprendida foi a necessidade de garantir que a branch principal do projeto não possua código “quebrado” e tenha condições de ser entregue em produção a qualquer momento (aqui a gente começa a entrar no conceito de Continuous Delivery).

A Integração Contínua (CI) é um daqueles conceitos que procura salvar seu time dele mesmo, e convenhamos, todos nós erramos e isso é natural. Não vou discorrer em detalhes sobre o que é CI, até porque há boas chances de você estar aqui por saber do que se trata. Mas caso não saiba, melhor eu sugerir este ótimo material aqui, que aborda CI/CD. Em troca, que tal você voltar pra cá e terminar de ler o meu artigo?

Estamos vivendo uma excelente época no desenvolvimento open source, que nos permite desenvolver, testar e entregar software gratuitamente ou a custos reduzidos. É o caso do Travis CI, que oferece seu serviço gratuitamente para projetos open source. Com este artigo busco demonstrar o quanto é simples configurar CI em seu repositório com Travis.

Autorizando Travis

Assumindo que você já tenha seu projeto em repositório público no Github, acesse o Travis e clique em Sign in with Github. Após autorizar o acesso, você poderá escolher quais repositórios deseja integrar ao Travis para realização do CI.

Configurando o projeto

Antes de mais nada, um aviso aos navegantes: CI só faz sentido se seu projeto possuir testes. Tendo o requisito atendido, você precisará criar um arquivo na raiz do projeto chamado .travis.yml possuindo estrutura semelhante a essa:

language: java
jdk: openjdk8

before_script:
- chmod +x gradlew

script:
- ./gradlew build

after_success:
- ./gradlew jacocoTestReport coveralls

O exemplo acima foi extraído deste projeto meu, o swagger-ready-spring-boot , que se encontra no Github.

A estrutura mínima consiste em definir a linguagem que é utilizada no projeto e qual script deve ser executado para realizar a build e execução dos testes. No caso acima, um projeto Java utilizando JDK8 e Gradle, eu tive que definir um comando anterior à execução do script, para tornar o wrapper do Gradle executável.

Perceba também que no meu exemplo eu executo uma etapa após a execução do script, que consiste em gerar um relatório do jacoco com cobertura de testes e envio para o coveralls (assunto que tratarei em outro artigo).

Para entender o que mais você pode fazer e como configurar pra projetos desenvolvidos em outras linguagens, leia a documentação.

Builds a cada Pull Request

Acessando o Travis, clique em Settings logo junto ao nome do repositório do seu projeto. Verifique suas configurações e altere como desejar, mas sugiro que você utilize uma configuração semelhante a essa:

Com isso, a cada push em branch e a cada push em PR aberto, será iniciada build no Travis e ao final você terá o feedback se a build está sendo realizada com sucesso ou falhando. No Github você terá esse feedback no Pull Request no início das verificações:

Ao final, você terá segurança para realizar o merge:

No meu caso, há mais verificações além do Travis CI (por isso o 6 successful checks), como cobertura de testes e qualidade de código utilizando outras ferramentas. Pretendo escrever outros artigos abordando estas ferramentas em breve.

Por hoje é isso. Caso tenha alguma crítica ou sugestão, utilize a caixa de comentários abaixo, seu feedback é muito bem vindo.