CI/CD com GitHub Actions: Automatizando Testes, Builds e Deploys com Pipeline Moderna

O que é CI/CD e por que sua equipe precisa disso?

CI/CD (Integração Contínua e Entrega Contínua) é uma prática fundamental da cultura DevOps que transforma a maneira como equipes de desenvolvimento entregam software. Em vez de acumular código por semanas e enfrentar um deploy estressante, a CI/CD automatiza cada etapa — desde a execução de testes até a publicação em produção.

O GitHub Actions é a plataforma nativa de CI/CD do GitHub, que permite criar pipelines diretamente no seu repositório sem depender de ferramentas externas como Jenkins, GitLab CI ou CircleCI. Com ele, você define workflows em arquivos YAML que são executados automaticamente em resposta a eventos como push, pull_request ou agendamentos.

Estrutura de um Workflow no GitHub Actions

Um workflow é composto por três elementos principais: eventos (o que dispara a execução), jobs (as tarefas a serem executadas) e steps (as ações dentro de cada job). Cada job roda em um runner isolado — um ambiente Ubuntu, Windows ou macOS provisionado automaticamente.

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Neste exemplo simples, sempre que um push ou PR for aberto para a branch main, o GitHub Actions faz o checkout do código, instala as dependências e executa os testes. O resultado aparece diretamente na aba Actions do repositório.

Matriz de Testes: Testando Múltiplas Versões

Uma das vantagens do GitHub Actions é a matriz de estratégia (strategy matrix), que permite executar o mesmo job em múltiplas configurações simultaneamente. Isso é ideal para garantir que seu software funcione em diferentes versões de runtime ou sistema operacional.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
        os: [ubuntu-latest, windows-latest]
    runs-on: \${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: \${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Com essa matriz, o pipeline executa 6 combinações diferentes (3 versões do Node × 2 sistemas operacionais) em paralelo. Se alguma versão quebrar, você descobre imediatamente — antes que o código chegue em produção.

Build e Push de Imagens Docker

Após os testes passarem, o próximo passo é construir a imagem Docker e enviá-la para um container registry. O GitHub Actions tem actions oficiais para integração com Docker Hub, GitHub Container Registry e Amazon ECR.

jobs:
  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Login no GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: \${{ github.actor }}
          password: \${{ secrets.GITHUB_TOKEN }}
      
      - name: Build e Push da imagem
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/\${{ github.repository }}:\${{ github.sha }}

Note o uso de needs: test: isso cria uma dependência entre jobs. O job de build só é executado se o job de testes passar. Os secrets (GITHUB_TOKEN) são injetados automaticamente pelo Actions, sem necessidade de configuração manual.

Deploy Contínuo em Produção

O deploy contínuo leva a automação até o fim: após construir e publicar a imagem, fazemos o deploy automático no ambiente de produção. Abaixo, um exemplo de deploy em uma VPS via SSH:

jobs:
  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: \${{ secrets.HOST }}
          username: \${{ secrets.USER }}
          key: \${{ secrets.SSH_KEY }}
          script: |
            docker pull ghcr.io/meu-app:latest
            docker stop app || true
            docker rm app || true
            docker run -d --name app -p 3000:3000 ghcr.io/meu-app:latest

A action appleboy/ssh-action é uma das mais populares do marketplace. Ela se conecta via SSH ao servidor usando chaves armazenadas em secrets e executa os comandos de deploy. Todo esse fluxo — testes → build → push → deploy — acontece em minutos, sem intervenção humana.

Ambientes e Gatilhos Condicionais

O GitHub Actions suporta ambientes (environments), que permitem adicionar proteções extras como aprovação manual antes do deploy em produção. Você também pode usar condicionais com a sintaxe if para controlar quais branches ou tags disparam cada etapa.

deploy-prod:
  needs: build-and-push
  if: github.ref == 'refs/heads/main'
  environment: production
  runs-on: ubuntu-latest
  steps:
    - run: echo "Fazendo deploy em produção..."

A combinação de ambientes com aprovação manual e condicionais por branch permite criar pipelines seguros e graduais: deploys em staging podem ser automáticos, enquanto produção exige aprovação de um líder técnico.

Cache de Dependências: Pipeline 2x Mais Rápido

Um problema comum em pipelines é o tempo gasto instalando dependências do zero a cada execução. O GitHub Actions oferece caching integrado que reduz drasticamente esse tempo.

- name: Cache do npm
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: \${{ runner.os }}-npm-\${{ hashFiles('package-lock.json') }}
    restore-keys: |
      \${{ runner.os }}-npm-

Com o cache, as dependências são restauradas do armazenamento do Actions em vez de baixadas da internet. Para projetos Node.js, isso reduz o tempo de instalação de 2 minutos para meros 10 segundos. O mesmo padrão funciona para Python (pip cache), Ruby (bundler), Go (go mod cache) e virtual environments.

Conclusão

O GitHub Actions democratizou a automação de pipelines, eliminando a complexidade de configurar servidores CI/CD dedicados. Com arquivos YAML versionados dentro do próprio repositório, cada membro da equipe pode visualizar, modificar e melhorar os workflows.

Para começar hoje mesmo, crie a pasta .github/workflows no seu repositório, adicione um arquivo .yml com os exemplos deste artigo e veja a mágica acontecer. A automatização de testes e deploys não é mais um diferencial — é uma necessidade para qualquer equipe que queira entregar software com qualidade e velocidade.