GitHub Actions: pipelines de CI/CD com matrix builds e ambientes customizados

O que é GitHub Actions e como funciona

CI/CD nativo integrado ao repositório

GitHub Actions é a plataforma de automação nativa do GitHub que permite criar workflows acionados por eventos do repositório - push, pull request, release, cron schedule ou chamadas via API. Cada workflow é um arquivo YAML armazenado em .github/workflows/ e versionado junto com o código. Essa integração elimina a necessidade de servidores de CI externos para a maioria dos casos, reduz o overhead de configuração e garante que a automação evolui junto com o código. Actions tem runners gratuitos para repositórios públicos e um tier generoso de minutos mensais para repositórios privados.

Workflow syntax - YAML, triggers, jobs, steps

A anatomia de um workflow Actions

Um workflow é composto por três camadas: triggers definem quando o workflow roda (on: push, on: pull_request, on: schedule); jobs são unidades de execução paralela ou sequencial com needs para definir dependências; steps são comandos individuais dentro de um job - scripts shell ou actions reutilizáveis. Cada job roda em um runner isolado e limpo. Steps dentro de um job compartilham o mesmo runner e filesystem, permitindo que um step compile o código e o próximo execute os testes no artefato gerado. A sintaxe declarativa torna o pipeline legível e auditável por todo o time.

Runners - hosted vs self-hosted

Onde os workflows executam

GitHub oferece runners hospedados (ubuntu-latest, windows-latest, macos-latest) que são ambientes efêmeros recriados do zero a cada job. São convenientes mas têm limitações de hardware e não têm acesso à rede interna da empresa. Self-hosted runners são máquinas que você controla, registradas no GitHub e disponíveis para receber jobs. Eles são necessários quando o pipeline precisa acessar recursos internos (bancos de dados, registries privados), requer hardware específico (GPU, ARM) ou quando o custo de minutos GitHub se torna proibitivo em projetos de alto volume. Self-hosted runners devem ser isolados e não compartilhados entre repositórios públicos e privados por razões de segurança.

Actions marketplace - reutilizando ações prontas

Ecossistema de automação compartilhada

O GitHub Marketplace tem milhares de actions prontas para tarefas comuns: checkout de código (actions/checkout), configuração de linguagens (actions/setup-node, actions/setup-dotnet), deploy em clouds (aws-actions/configure-aws-credentials, azure/login), análise de segurança (github/codeql-action) e muito mais. Actions são referenciadas por nome e versão (uses: actions/checkout@v4) e podem aceitar inputs e retornar outputs. Para actions críticas de segurança, sempre pin pela hash do commit em vez da tag - tags podem ser sobrescritas maliciosamente em ataques de supply chain. Actions próprias podem ser criadas em JavaScript, TypeScript ou como containers Docker.

Secrets e variáveis de ambiente seguras

Gerenciando credenciais em workflows

Secrets são valores criptografados armazenados no GitHub e injetados como variáveis de ambiente nos runners sem aparecer nos logs. Eles podem ser definidos no nível do repositório, ambiente (environment) ou organização. Environments adicionam proteção extra: requerem aprovação manual de revisores específicos antes de um job acessar os secrets daquele ambiente, criando um gate de segurança para deploys em produção. Variáveis de ambiente regulares (vars.*) são adequadas para valores não-sensíveis como URLs de endpoints. Nunca imprima secrets nos logs com echo - o GitHub mascara automaticamente valores de secrets registrados, mas valores derivados podem vazar.

Matrix builds - testando em múltiplas versões

Paralelismo inteligente no pipeline

A estratégia matrix permite executar o mesmo job com combinações diferentes de variáveis em paralelo. Um exemplo clássico é testar uma biblioteca em múltiplas versões do Node.js ou .NET simultaneamente. A configuração strategy: matrix: node: [18, 20, 22] cria três jobs paralelos, cada um executando com uma versão diferente. Matrizes podem ser bidimensionais - combinando versão de linguagem com sistema operacional - gerando dezenas de combinações de teste com uma única definição. O parâmetro fail-fast controla se a matriz inteira é cancelada quando um job falha ou se os demais continuam até o fim.

Artifacts e cache entre jobs

Persistindo dados entre execuções

Artifacts permitem que um job compartilhe arquivos com jobs subsequentes ou com o usuário via download. O job de build faz upload do artefato compilado; o job de teste faz download e executa. Isso garante que o mesmo binário seja testado em múltiplos ambientes sem recompilar. Cache é diferente de artifact: persiste entre execuções diferentes do workflow para acelerar steps lentos como npm install ou dotnet restore. A action actions/cache usa uma chave derivada de um hash do arquivo de dependências (package-lock.json, *.csproj) e invalida automaticamente quando as dependências mudam, rebalanceando economia de tempo e risco de cache stale.

Deploy com GitHub Actions - exemplos reais

Do código para produção via workflow

Deploys profissionais com GitHub Actions seguem o padrão: build e push da imagem Docker para ECR ou GHCR com a tag do SHA do commit; atualização do manifesto Kubernetes ou task definition ECS com a nova tag; notificação ao time via Slack ou Teams. Para deploys em servidores com SSH, usa-se appleboy/ssh-action para executar comandos remotos. O deploy para produção deve estar em um environment com required reviewers: nenhum push acidental em main chega a produção sem aprovação explícita. Combinar Actions com ArgoCD é uma prática comum - o workflow atualiza o manifesto no Git e o ArgoCD aplica no cluster.

Boas práticas de segurança em workflows

Protegendo a cadeia de suprimentos de software

Workflows GitHub Actions executam código de terceiros e têm acesso a secrets do repositório, tornando-os um alvo de ataques de supply chain. As práticas essenciais incluem: sempre fazer pin de actions por hash de commit (uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683); usar permissões mínimas com permissions: no topo do workflow; nunca usar pull_request_target em workflows que fazem checkout de código de forks externos; revisar o código de actions antes de usar em produção; e usar CODEOWNERS para proteger arquivos .github/workflows/ exigindo revisão de responsáveis de segurança antes de qualquer alteração nos pipelines.

Conclusão

GitHub Actions como plataforma completa de automação

Continue em: Fundamentos obrigatórios antes de produção.

Vídeos - GitHub Actions e Automação

GitHub Actions do zero - workflows completos

CI/CD com GitHub Actions - build, test e deploy

GitHub Actions segurança - supply chain attacks

Self-hosted runners no GitHub Actions

Matrix builds e paralelismo em Actions

Deploy Kubernetes com GitHub Actions e ArgoCD