Testando a novidade Github Actions

Jorge Junior
Nov 7 · 5 min read

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.

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

É 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

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.

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.

Tech at Quero

Blog do time de Tecnologia da Quero Educação — A EdTech que mais cresce no Brasil

Jorge Junior

Written by

Desenvolvedor @ Quero Educação

Tech at Quero

Blog do time de Tecnologia da Quero Educação — A EdTech que mais cresce no Brasil

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade