Se você desenvolve software e usa GitHub, provavelmente já ouviu falar em GitHub Actions. Lancado em 2019, o GitHub Actions se tornou rapidamente uma das ferramentas de CI/CD mais populares do mundo, permitindo automatizar fluxos de trabalho diretamente no repositório do seu código. Neste guia, vamos desmistificar o GitHub Actions e mostrar como configurar pipelines de integração e entrega continua do zero.
O que é CI/CD?
Antes de mergulhar no GitHub Actions, é importante entender os conceitos de CI e CD:
Integração Continua (CI) e a prática de integrar código ao repositório principal frequentemente, idealmente várias vezes ao dia. Cada integração e verificada por um build automatizado e testes, detectando erros o mais cedo possível. A ideia é simples: quanto mais cedo você detecta um problema, mais fácil e barato e corrigi-lo.
Entrega Continua (CD) estende a CI garantindo que o código esteja sempre em um estado deployável. Após passar pelos testes automatizados, o código pode ser implantado em produção com um clique (ou automaticamente). A entrega continua reduz o risco de deploys grandes e infrequentes, favorecendo entregas pequenas e frequentes.
"Se fazer deploy e doloroso, faca mais frequentemente. A dor vem do tamanho da mudança, não da frequência." — Martin Fowler
Por que GitHub Actions?
O ecossistema de ferramentas de CI/CD e vasto — Jenkins, GitLab CI, CircleCI, Travis CI, Azure DevOps, entre outros. Então por que escolher GitHub Actions? Aqui estão as principais razoes:
- Integração nativa: Se seu código já está no GitHub, não precisa configurar integração com serviços externos. Tudo vive no mesmo lugar.
- Marketplace de Actions: Milhares de actions pre-construídas disponíveis no marketplace, desde deploy na AWS até notificações no Slack.
- Gratuito para open source: Repositórios públicos tem minutos ilimitados de GitHub Actions. Repositórios privados tem uma cota gênerosa no plano gratuito.
- YAML declarativo: Workflows são definidos em arquivos YAML versionados junto com o código, seguindo o princípio de "infrastructure as code".
- Runners variados: Suporte a Linux, macOS e Windows, além da possibilidade de usar self-hosted runners.
- Segurança: Gerenciamento de secrets integrado, OIDC para provedores cloud, e permissões granulares.
Anatomia de um workflow
Um workflow do GitHub Actions e composto por quatro níveis hierárquicos:
| Componente | Descrição | Exemplo |
|---|---|---|
| Workflow | O processo automatizado completo, definido em um arquivo YAML | ci.yml, deploy.yml |
| Trigger (on) | O evento que inicia o workflow | push, pull_request, schedule |
| Job | Um conjunto de steps que executam no mesmo runner | build, test, deploy |
| Step | Uma ação individual dentro de um job | checkout, install, run tests |
Estrutura básica de um arquivo workflow
Os arquivos de workflow ficam em .github/workflows/ no seu repositório. Aqui está a estrutura básica comentada:
O arquivo começa com o name do workflow, seguido pelo bloco on que define os triggers. Dentro de jobs, você define um ou mais jobs, cada um com seu runs-on (sistema operacional) e uma lista de steps. Cada step pode usar uma action do marketplace (com uses) ou executar um comando shell (com run).
Triggers: quando executar o workflow
O GitHub Actions suporta dezenas de eventos que podem disparar workflows. Os mais comuns são:
- push: Executa quando código e pushed para branches específicas. Ideal para CI em branches de desenvolvimento.
- pull_request: Executa quando um PR e aberto, atualizado ou sincronizado. Perfeito para validar código antes do merge.
- schedule: Executa em horarios programados usando sintaxe cron. Útil para testes noturnos, limpeza de recursos ou builds periodicos.
- workflow_dispatch: Permite executar o workflow manualmente pela interface do GitHub. Ótimo para deploys manuais com aprovação.
- release: Executa quando uma release e públicada. Ideal para deploy automático em produção.
Filtros de branches e paths
Você pode refinar os triggers com filtros. Por exemplo, executar o workflow apenas quando ha push na branch main, ou apenas quando arquivos em determinados diretorios são modificados. Isso e extremamente útil em monorepos, onde você não quer executar todos os pipelines para qualquer alteração.
Jobs e paralelismo
Jobs são a unidade de execução do GitHub Actions. Por padrão, jobs em um mesmo workflow executam em paralelo, o que acelera significativamente o pipeline. Você pode criar dependências entre jobs usando a propriedade needs, criando um grafo de execução.
Estratégias de matriz
Uma das funcionalidades mais poderosas dos jobs e a estratégia de matriz. Ela permite executar o mesmo job com diferentes combinações de parametros. Por exemplo, você pode testar seu código em Node.js 18, 20 e 22, simultaneamente em Linux, macOS e Windows — totalizando 9 execuções paralelas com uma única definição de job.
Secrets e variáveis de ambiente
Pipelines de CI/CD frequentemente precisam acessar credenciais, tokens de API e outras informações sensíveis. O GitHub Actions oferece um sistema robusto de gerenciamento de secrets:
- Repository secrets: Acessíveis por todos os workflows do repositório
- Environment secrets: Vinculados a ambientes específicos (staging, production) com regras de aprovação
- Organization secrets: Compartilhados entre múltiplos repositórios da organização
Secrets são criptografados em repouso, mascarados nos logs é nunca expostos em forks (por segurança). Acesse-os nos workflows usando a sintaxe ${{ secrets.NOME_DO_SECRET }}.
Exemplo prático: pipeline completo para aplicação Node.js
Vamos construir um pipeline completo para uma aplicação Node.js com NestJS (como o backend do GalagoWork). O pipeline tera três etapas: lint e testes, build, e deploy.
Etapa 1: Lint e Testes
Nesta primeira etapa, o workflow faz checkout do código, instala as dependências com npm ci (mais rápido e determinisitco que npm install), executa o linter (ESLint) e roda os testes unitarios. Se qualquer etapa falhar, o pipeline para e o PR recebe um status de falha.
Etapa 2: Build
Se os testes passarem, o job de build compila o projeto TypeScript, gera a imagem Docker e a pública no GitHub Container Registry (ghcr.io). Usar o cache de layers do Docker entre builds reduz significativamente o tempo de construção.
Etapa 3: Deploy
O deploy pode ser automático (para staging) ou com aprovação manual (para production). O GitHub Actions suporta ambientes com regras de proteção, permitindo que um reviewer aprove o deploy antes que ele aconteça. Issó combina a velocidade da automação com a segurança da revisão humana.
Otimizando seus workflows
Workflows lentos desperdicam tempo e dinheiro. Aqui estão estratégias para otimiza-los:
Cache de dependências
Use a action actions/cache para armazenar em cache diretories como node_modules, .npm, ou .m2. Isso pode reduzir o tempo de instalação de dependências de minutos para segundos.
Execução condicional
Use a propriedade if para pular steps ou jobs inteiros com base em condições. Por exemplo, execute o deploy apenas na branch main, ou pule testes de integração em PRs de documentação.
Timeouts e concorrencia
Defina timeouts para evitar que workflows travados consumam minutos indefinidamente. Use o bloco concurrency para cancelar execuções anteriores quando um novo push e feito, evitando desperdício de recursos.
Self-hosted runners
Para workloads intensivos ou que requerem hardware específico, considere usar self-hosted runners. Eles executam na sua própria infraestrutura, oferecem melhor performance e não consomem minutos do plano GitHub.
Integrando GitHub Actions com gestão de projetos
O verdadeiro poder do CI/CD aparece quando ele está integrado ao fluxo de gestão do projeto. Com o GalagoWork, por exemplo, commits e pull requests são automaticamente vinculados aos cartões do quadro Kanban. Quando um PR e mergeado e o deploy acontece via GitHub Actions, o cartão correspondente pode ser movido automaticamente para "Concluído".
Essa integração cria uma rastreabilidade completa: da tarefa no quadro ao código no repositório, do teste automatizado ao deploy em produção. O resultado e visibilidade total para toda a equipe, sem esforco manual.
Segurança em pipelines de CI/CD
Pipelines de CI/CD são alvos atrativos para atacantes, pois frequentemente tem acesso a credenciais de produção. Siga estas práticas de segurança:
- Princípio do menor privilegio: Cada workflow deve ter apenas as permissões necessárias. Use o bloco
permissionspara restringir acessos. - Pin actions por SHA: Em vez de usar
actions/checkout@v4, use o SHA completo do commit. Isso previne ataques de supply chain. - Revise actions de terceiros: Antes de usar uma action do marketplace, revise seu código fonte. Prefira actions de publishers verificados.
- Proteja branches: Configure branch protection rules para exigir que checks passem antes do merge.
- Rotacione secrets: Troque credenciais periodicamente e use OIDC quando possível para evitar secrets de longa duração.
- Audit logs: Monitore os logs de execução de workflows para detectar atividades suspeitas.
Padrões avançados
Para equipes maduras, alguns padrões avançados podem elevar o nível dos seus pipelines:
Reusable workflows
Crie workflows reutilizáveis que podem ser chamados por outros workflows, evitando duplicação de configuração entre repositórios. Ideal para organizações com muitos projetos similares.
Composite actions
Agrupe múltiplos steps em uma action customizada que pode ser compartilhada e versionada. Perfeito para encapsular lógica comum como "configurar ambiente Node.js com cache".
Deployment environments
Configure ambientes (dev, staging, production) com regras de proteção, wait timers e reviewers obrigatórios. Isso cria um pipeline de deploy seguro e auditável.
Conclusão
O GitHub Actions democratizou o CI/CD, tornando-o acessível para equipes de todos os tamanhos. Com workflows definidos em YAML, um marketplace rico em actions pre-construídas e integração nativa com o GitHub, não ha mais desculpa para não automatizar seu pipeline de desenvolvimento.
Comece simples — um workflow básico de lint e testes já traz valor imenso. Evolua gradualmente adicionando build automatizado, deploy em staging e, eventualmente, deploy continuo em produção. E lembre-se: o melhor pipeline e aquele que a equipe confia e usa todos os dias.