Neste artigo vamos falar um pouco sobre essa ferramenta sensacional, o Github Actions e como funciona esta integração de repositório de fontes com CI | CD.
A busca de soluções rápidas para automação tende a aumentar no mercado de desenvolvimento e essa solução com certeza vai te surpreender.
Artigo escrito pelos zuppers Lucas Marcelino Vieira e Guillaume Falourd.
Afinal, o que é Github Actions?
O Github Action (GHA) é uma ferramenta Open Source que permite automatizar, personalizar e executar fluxos de trabalho de desenvolvimento de software diretamente no seu repositório GitHub.
Para isso, é possível usar, criar e compartilhar ações para realizar qualquer trabalho desejado, incluindo CI/CD, bem como combinar ações em um fluxo de trabalho completamente personalizado.
Outra facilidade da plataforma é oferecer uma série de templates em um marketplace. Assim, basta adicionar suas variáveis de ambiente ao template que o Github Actions fará o resto para você. Mas não se preocupe que vamos falar mais sobre isso a seguir.
Essa poderosa ferramenta foi lançada em beta no final de 2018 e liberada de forma geral em 13 de novembro de 2019. Vale lembrar que desde 2018 a Github pertence à Microsoft.
Suporte a qualquer Sistema operacional, Cloud e linguagens
O Github Action suporta todas as grandes plataformas de cloud do mercado (Azure, GCP, AWS, Hashicorp etc.), assim como sistema operacionais com suas principais distros (distribuições).
Além disso, também possui suporte para diversas linguagens de desenvolvimento como Java, Ruby, Python, Go, Rust, .Net entre outras.
Tudo sobre workflows no Github Actions
Os workflows (fluxos de trabalhos) são escritos no formato YAML (um formato de serialização de dados legíveis por humanos) e devem ser adicionados no diretório .github/workflows do repositório onde o usuário deseja executar ele.
Nota: É possível ter quantos workflows (arquivos .yml) se desejar neste diretório, cada um podendo ser responsável por uma operação diferente.
Arquivos no formato YAML
Os arquivos YAML tem uma sintaxe relativamente simples e funcionam por indentação. Para entender como escrever um workflow, é importante entender a relação entre os diversos elementos que compõem esse arquivo.
- Um workflow é composto de uma lista de jobs que podem ser executados em paralelo ou sequencialmente.
- Um job é composto de uma lista de steps (etapas).
- Um step é composto de um conjunto de comandos autônomos que realizam uma ação.
Nota: É possível criar as suas próprias ações ou usar ações criadas pela comunidade de GitHub.
Nota: A documentação do Github Action é muito completa em inglês e está sendo traduzida em português seguindo o mesmo formato.
Mas como o Github Action funciona?
O Github Action é orientado por eventos, onde cada evento pode acionar (trigger) automaticamente um ou mais workflows.
A lista completa dos eventos que podem acionar um workflow podem ser encontrados aqui. É possível, por exemplo, iniciar um workflow após cada push, pull request ou comentário, para uma branch específica ou para todas, e é customizável.
Como explicado antes, cada workflow é composto de uma lista de jobs, onde cada job vai ser executado através de um runner.
O runner é um servidor que tem o aplicativo do executor de GitHub Actions instalado. Você pode usar um runner hospedado por GitHub (ubuntu, macOS ou windows) ou você pode hospedar o seu próprio (self-hosted).
Exemplo de workflow
Segue abaixo um exemplo de workflow extraído da documentação do Github:
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1
- run: npm install -g bats
- run: bats -vTraduzindo o que está acontecendo neste workflow:
- O nome do workflow é learn-github-actions (é o nome que vai aparecer na interface gráfica do Github quando for rodar o workflow).
- A palavra on é uma palavra reservada que indica qual tipo de evento vai acionar o workflow. Neste caso está sendo informado apenas push, sem nenhuma customização. Portanto, esse workflow iniciará após cada push no repositório.
- A palavra jobs também é uma palavra reservada, que indica que a partir dessa linha iniciará a lista dos jobs que serão executados pelo workflow.
- A linha após o jobs aqui representa o job id (check-bats-version), que é o identificador do job (também é possível configurar o nome do job e o id podendo ser usado para referenciar esse job em outro lugar no arquivo).
- Abaixo do job-id está informado o runner usado através da palavra reservada runs-on. É possível usar mais de um runner se queremos executar nosso workflow em mais de um sistema operacional.
- Vem depois a palavra reservada steps, indicando que a partir dessa linha iniciará a lista das etapas que serão executadas pelo job.
- Finalizando o arquivo, são apresentadas 4 etapas, duas usando ações disponibilizadas pelo Github (através da palavra reservada uses) e duas outras com comandos personalizados executados através da palavra reservada run.
- actions/checkout@v2 é uma ação permitindo ao workflow fazer um checkout do repositório, permitindo que, por exemplo, seja possível acessar os arquivos e diretórios do repositório.
- actions/setup-node@v1 é uma ação permitindo instalar o node no runner.
- o comando npm install -g bats instala o bats no runner.
- o comando bats -v retorna a versão do bats instalada no runner.
Em outras palavras, esse workflow vai, após cada push no repositório, usar o runner (ubuntu-latest) para instalar o bats usando node e retornar a versão do bats que foi instalada.
Cadeias de fluxos de trabalhos já presentes na plataforma
Como falamos no começo deste artigo, o GitHub Actions possui muitas cadeias de trabalhos e automações já existentes que você pode utilizar e aplicar em seus fluxos de trabalho.
Assim, além de novos insights para suas squads, você segue boas práticas das melhores empresas de desenvolvimento.
Na nossa opinião, esse conceito de unificar repositórios com automações só tende a crescer e é possível ver uma lacuna no mercado para as bigs techs investirem nessa centralização.
Inclusive, confira algumas opções disponíveis de templates aqui.
Construindo uma ação
Agora que você já sabe bastante coisa sobre o GitHub Actions, que tal vermos um exemplo prático?
Abaixo realizei a construção de um exemplo bem simples onde é feita a construção de uma imagem docker baseada no repositório de fontes, a linguagem utilizada é o YAML.
O próprio template pré-definido já traz as opções adicionais e opções que devem ser preenchidas. Simples, fácil e rápido.
name: Docker Image CI
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Build the Docker image
run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)Custos para adequação em repositórios privados
O grande benefício do Github Actions em comparação com outras plataformas já existentes como o Jenkins, por exemplo, é o fato dele ser open source.
Mas pense comigo, se pudermos ter uma ferramenta mais rápida e que amplie o desenvolvimento das squads, o investimento cairia por si só, não acha?
O Github Actions tem uma cotação para free tier na utilização, ou seja, só irá começar a pagar quando exceder isso.
Com o plano gratuito você tem direito a usar até 2000 minutos de workflow rodando por mês nos repositórios privados e essa quantidade de minutos é ilimitada para repositórios públicos. Para entender mais a respeito, acesse a política de preço do Github.
Conclusão
Esperamos que esse artigo tenha deixado claro a inovação e relevância do GitHub Actions. E se quiser aprender mais sobre essa ferramenta é só ficar ligado nos canais da Zup que frequentemente trazemos lives e outros artigos sobre ele.
Inclusive, temos um vídeo muito bacana falando sobre o Github Actions e como é possível executar fórmulas do Ritchie CLI, projeto open source mantido pela Zup, usando a ferramenta.
Ficou com alguma dúvida ou tem uma sugestão para falarmos sobre o GitHub Actions? Então é só comentar aqui embaixo!
Referências
Página oficial do GitHub Actions
