Testando a novidade Github Actions

Como utilizar uma ferramenta de CI/CD para o deploy de aplicações

Como sabemos, há algum tempo o Github nos apresentou a sua ferramenta, o Github Actions. Então, por que não brincar com essa ferramenta e ver o que temos disponível? Foi esta pergunta que me despertou o interesse e gostaria de despertar o mesmo em outros desenvolvedores.

Aqui, criaremos ações na ferramenta do Github para testar e fazer o release da nossa aplicação, usando o Ruby on Rails. Antes de tudo, entendam como release a disponibilização da nossa aplicação no Dockerhub. Além disso, como a etapa de deploy em si é bem específica, ela não será abordada neste artigo, já que depende do serviço que você usa (AWS, Google Cloud, Heroku, etc).

Aplicação Rails utilizada

Sempre tento usar o Docker quando possível para as minhas aplicações, portanto, o objetivo é criar uma aplicação Rails compatível com o Docker. Se você não sabe como criar a sua, dê uma olhada no passo a passo disponibilizado pelo próprio Docker ou, então, no repositório deste projeto.

Acesse aqui para ver como o meu Dockerfile ficou.

Basicamente, criamos um Dockerfile responsável por instalar as dependências do nosso projeto. Nesse caso, configurei para usar a imagem 2.6.3 do Ruby, além de usar um entrypoint.sh para apagar algum arquivo referente ao servidor (server.pid). Vale ressaltar que precisamos desse arquivo já que, quando estamos rodando a aplicação em produção, não usamos o docker-compose.

Criamos também um arquivo docker-compose.yml para facilitar a utilização em ambiente de desenvolvimento. O arquivo docker-compose e entrypoint.sh são os seguintes:

docker-compose.yml

entrypoint.sh

Cuidados ao criar a aplicação

Repare que passamos como DB_HOST como variável de ambiente. Isso é necessário, pois não usaremos toda uma infraestrutura para rodar nossa aplicação, mas apenas um ambiente com Ruby.

Mas e o banco de dados? Vamos usar um container que é disponibilizado pelo Github Actions por meio de um serviço. Isso significa que, ao configurar o arquivo database.yml, devemos ter algo parecido como o seguinte:

database.yml

Com a nossa aplicação configurada, podemos partir para a configuração do Github Actions.

Antes de tudo, como funciona o Github Actions

Assim como as outras ferramentas de CI/CD disponíveis, com o Github Actions, você consegue definir jobs/tasks quando uma alteração/push é realizada no repositório do seu projeto. A ferramenta ainda está em beta e você pode se inscrever para acessá-la aqui.

Com isso dito, vamos à prática!

A primeira coisa que temos que fazer é criar uma pasta na raiz do nosso projeto, chamada .github/workflows. Nessa pasta vamos colocar o nosso arquivo de main.yml contendo nossos jobs/ações.

Escrevendo os jobs

Nomeie esse fluxo e decida quando ele deve ser ativado. No nosso caso, isso acontece em qualquer push para o repositório:

• main.yml

É hora de dar início aos jobs, que são as etapas como um todo do nosso processo de CI/CD. Vamos utilizar um serviço com um container Docker e imagem do Postgres 11 para prover o banco de dados para nossos testes.

Configure o usuário, senha e banco utilizados pelo banco com as variáveis de ambiente POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB.

Também deve-se configurar a porta de um jeito um pouco diferente. Com essa configuração, o ambiente disponibiliza o banco em alguma porta disponível mapeada para a porta 5432 do container, no qual o banco está rodando. Abaixo, deixei o arquivo completo:

main.yml

Etapas do workflow

Com o banco de dados criado, seguimos para o workflow, colocando uma entrada steps em nosso arquivo main.yml e usamos sempre as seguintes configurações:

• uses: Define qual imagem deve utilizar. Na maioria dos casos, eu utilizei a actions/checkout@v1. Para ver o que podemos utilizar, você pode acessar aqui as ações disponibilizadas pelo próprio Github.
• name: Nome de cada etapa.
• with: Algumas ações já vem pré-configuradas, então devemos apenas usar uma imagem e, assim, passar algum valor para definir o que queremos fazer. É para isso que serve a entrada with. Nesse exemplo, utilizo em dois momentos: para dizer qual a versão do Ruby deve ser utilizada e para configurar o usuário e senha do Dockerhub (na etapa de release).
• run: Utilizado para passar comandos a serem executados. Pode-se passar mais de um comando.
• env: Utilizado para definir variáveis de ambiente

main.yml

Repare que temos uma etapa de configuração de banco. Nela, instalamos os bundler, as gems e configuramos o banco. Usamos uma variável de ambiente para dizer qual a porta utilizando uma informação do contexto do serviço do Postgres que criamos. Para isso, usamos o comando ${{ job.services.postgres.ports[5432] }}. Na documentação do Github, dá para saber mais sobre as informações de contexto.

Execução de testes

Com tudo configurado, a etapa de execução de testes é bem simples. Vamos apenas às informações as configurações do banco com variáveis de ambiente e executar o rspec para rodar os testes. Então, é só commitar, dar o push e acessar a aba do Github Actions no seu repositório (se já estiver disponível pra você).

main.yml

Fazendo o release para o Dockerhub

Com tudo funcionando e os testes passando, podemos seguir com o nosso processo — no caso, apenas a etapa de release ou liberação da imagem do projeto para um repositório de imagens (no caso o dockerhub)

Para fazê-lo, vamos criar outro job, chamado release (ou seja, deve ficar no mesmo nível de indentação da etapa build). Para essa action, temos algumas diferenças:

• deve apenas ser executada na branch master.
• deve ser executada somente se a etapa de build (que executa os testes) for feita com sucesso.

Parece um pouco complexo, mas veja que é bem simples aqui:

main.yml

Os detalhes dessa etapa são as duas linhas abaixo, onde informamos que deve ser executada apenas na branch master e somente se a etapa de build for com executada com sucesso (a entrada needs faz isso).

if: github.ref == ‘refs/heads/master’

needs: build

Além disso, também temos a entrada with, que utilizamos para passar as configurações de login do Dockerhub. Usamos os Secrets, que podem ser criados em Settings -> Secrets.

E, pronto! Basta fazer o commit e o push que teremos o workflow funcionando.

Quer trabalhar conosco? Nosso time de Engenharia está com vagas abertas.