DevOps10 min de leitura

Integração Contínua (CI): Automatizando Testes com Github Actions

Pipeline de CI completo para Node.js: cache de dependências, jobs paralelos para lint/test/typecheck, services para banco de dados de teste, matrix strategy e Branch Protection Rules.

12 de agosto de 2026

Integração Contínua (CI) é a prática de verificar automaticamente cada mudança de código antes de integrá-la à branch principal. O objetivo é detectar problemas o mais cedo possível — quando ainda é barato corrigir. Um bug encontrado em um PR leva 5 minutos para corrigir; o mesmo bug em produção pode levar horas e impactar usuários reais.

O GitHub Actions transformou CI em algo acessível: gratuito para repositórios públicos, 2.000 minutos/mês gratuitos para privados, e configurado diretamente no repositório via arquivos YAML. Neste artigo vamos montar um pipeline profissional com cache de dependências, jobs paralelos, banco de dados de teste via services, e proteção de branch.

Conceitos Fundamentais do GitHub Actions

Workflow — arquivo YAML em .github/workflows/. Define quando e o que executar.
Trigger (on) — evento que dispara o workflow: push, pull_request, schedule, workflow_dispatch (manual)
Job — unidade de execução isolada. Cada job roda em uma VM separada (runner). Jobs são paralelos por padrão.
Step — tarefa dentro de um job. Executados sequencialmente dentro do job.
Action — passo reutilizável do marketplace (ex: actions/checkout, actions/setup-node)
Runner — a VM onde o job roda. ubuntu-latest é a opção mais comum e gratuita.

Pipeline Básico com Cache

ci.yml

1name: CI
name: CI
2

3on:
on:
4  push:
  push:
5    branches: [main, develop]
    branches: [main, develop]
6  pull_request:
  pull_request:
7    branches: [main, develop]
    branches: [main, develop]
8

9# Cancela runs anteriores do mesmo PR (economiza minutos)
# Cancela runs anteriores do mesmo PR (economiza minutos)
10concurrency:
concurrency:
11  group: ${{ github.workflow }}-${{ github.ref }}
  group: ${{ github.workflow }}-${{ github.ref }}
12  cancel-in-progress: true
  cancel-in-progress: true
13

14jobs:
jobs:
15  ci:
  ci:
16    name: Lint, Typecheck e Testes
    name: Lint, Typecheck e Testes
17    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
18

19    steps:
    steps:
20      - name: Checkout
      - name: Checkout
21        uses: actions/checkout@v4
        uses: actions/checkout@v4
22

23      - name: Configurar pnpm
      - name: Configurar pnpm
24        uses: pnpm/action-setup@v4
        uses: pnpm/action-setup@v4
25        with:
        with:
26          version: 9
          version: 9
27

28      - name: Configurar Node.js
      - name: Configurar Node.js
29        uses: actions/setup-node@v4
        uses: actions/setup-node@v4
30        with:
        with:
31          node-version: 22
          node-version: 22
32          # Cache do pnpm store — evita baixar dependências em cada run
          # Cache do pnpm store — evita baixar dependências em cada run
33          cache: 'pnpm'
          cache: 'pnpm'
34

35      - name: Instalar dependências
      - name: Instalar dependências
36        # --frozen-lockfile: falha se o lockfile estiver desatualizado
        # --frozen-lockfile: falha se o lockfile estiver desatualizado
37        # Garante que o CI usa exatamente as versões do pnpm-lock.yaml
        # Garante que o CI usa exatamente as versões do pnpm-lock.yaml
38        run: pnpm install --frozen-lockfile
        run: pnpm install --frozen-lockfile
39

40      - name: Typecheck
      - name: Typecheck
41        run: pnpm typecheck
        run: pnpm typecheck
42

43      - name: Lint
      - name: Lint
44        run: pnpm lint
        run: pnpm lint
45

46      - name: Testes unitários
      - name: Testes unitários
47        run: pnpm test --coverage
        run: pnpm test --coverage
48

49      - name: Upload de cobertura para Codecov
      - name: Upload de cobertura para Codecov
50        uses: codecov/codecov-action@v4
        uses: codecov/codecov-action@v4
51        with:
        with:
52          token: ${{ secrets.CODECOV_TOKEN }}
          token: ${{ secrets.CODECOV_TOKEN }}
53          files: ./coverage/lcov.info
          files: ./coverage/lcov.info

Jobs Paralelos: Reduzindo o Tempo do Pipeline

Quando lint, typecheck e testes são sequenciais, um falha na etapa anterior bloqueia as outras e você não sabe quais outros problemas existem. Com jobs paralelos, todos rodam simultaneamente e você vê todos os erros de uma vez:

ci.yml (jobs paralelos)

1jobs:
jobs:
2  typecheck:
  typecheck:
3    name: TypeScript
    name: TypeScript
4    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
5    steps:
    steps:
6      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
7      - uses: pnpm/action-setup@v4
      - uses: pnpm/action-setup@v4
8      - uses: actions/setup-node@v4
      - uses: actions/setup-node@v4
9        with: { node-version: 22, cache: 'pnpm' }
        with: { node-version: 22, cache: 'pnpm' }
10      - run: pnpm install --frozen-lockfile
      - run: pnpm install --frozen-lockfile
11      - run: pnpm typecheck
      - run: pnpm typecheck
12

13  lint:
  lint:
14    name: ESLint
    name: ESLint
15    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
16    steps:
    steps:
17      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
18      - uses: pnpm/action-setup@v4
      - uses: pnpm/action-setup@v4
19      - uses: actions/setup-node@v4
      - uses: actions/setup-node@v4
20        with: { node-version: 22, cache: 'pnpm' }
        with: { node-version: 22, cache: 'pnpm' }
21      - run: pnpm install --frozen-lockfile
      - run: pnpm install --frozen-lockfile
22      - run: pnpm lint
      - run: pnpm lint
23

24  test:
  test:
25    name: Jest
    name: Jest
26    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
27    needs: [] # Não depende de nada — roda em paralelo com typecheck e lint
    needs: [] # Não depende de nada — roda em paralelo com typecheck e lint
28    steps:
    steps:
29      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
30      - uses: pnpm/action-setup@v4
      - uses: pnpm/action-setup@v4
31      - uses: actions/setup-node@v4
      - uses: actions/setup-node@v4
32        with: { node-version: 22, cache: 'pnpm' }
        with: { node-version: 22, cache: 'pnpm' }
33      - run: pnpm install --frozen-lockfile
      - run: pnpm install --frozen-lockfile
34      - run: pnpm test --coverage
      - run: pnpm test --coverage
35

36  # Job de build depende dos três anteriores
  # Job de build depende dos três anteriores
37  build:
  build:
38    name: Build
    name: Build
39    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
40    needs: [typecheck, lint, test] # Só roda se os três passarem
    needs: [typecheck, lint, test] # Só roda se os três passarem
41    steps:
    steps:
42      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
43      - uses: pnpm/action-setup@v4
      - uses: pnpm/action-setup@v4
44      - uses: actions/setup-node@v4
      - uses: actions/setup-node@v4
45        with: { node-version: 22, cache: 'pnpm' }
        with: { node-version: 22, cache: 'pnpm' }
46      - run: pnpm install --frozen-lockfile
      - run: pnpm install --frozen-lockfile
47      - run: pnpm build
      - run: pnpm build

Services: Banco de Dados Real nos Testes de Integração

Testes de integração que testam a camada de repositório precisam de um banco de dados real. O GitHub Actions suporta service containers — instâncias Docker que sobem junto com o job:

integration-tests.yml

1jobs:
jobs:
2  integration:
  integration:
3    name: Testes de Integração
    name: Testes de Integração
4    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
5

6    # Containers de serviço que ficam disponíveis durante o job
    # Containers de serviço que ficam disponíveis durante o job
7    services:
    services:
8      postgres:
      postgres:
9        image: postgres:16-alpine
        image: postgres:16-alpine
10        env:
        env:
11          POSTGRES_USER: test
          POSTGRES_USER: test
12          POSTGRES_PASSWORD: test
          POSTGRES_PASSWORD: test
13          POSTGRES_DB: testdb
          POSTGRES_DB: testdb
14        ports:
        ports:
15          - 5432:5432
          - 5432:5432
16        # Aguarda o PostgreSQL estar pronto antes de prosseguir
        # Aguarda o PostgreSQL estar pronto antes de prosseguir
17        options: >-
        options: >-
18          --health-cmd pg_isready
          --health-cmd pg_isready
19          --health-interval 10s
          --health-interval 10s
20          --health-timeout 5s
          --health-timeout 5s
21          --health-retries 5
          --health-retries 5
22

23      redis:
      redis:
24        image: redis:7-alpine
        image: redis:7-alpine
25        ports:
        ports:
26          - 6379:6379
          - 6379:6379
27        options: --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5
        options: --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5
28

29    env:
    env:
30      # Variáveis de ambiente para os testes
      # Variáveis de ambiente para os testes
31      DATABASE_URL: postgresql://test:test@localhost:5432/testdb
      DATABASE_URL: postgresql://test:test@localhost:5432/testdb
32      REDIS_URL: redis://localhost:6379
      REDIS_URL: redis://localhost:6379
33      JWT_SECRET: test-secret-only-for-ci
      JWT_SECRET: test-secret-only-for-ci
34      NODE_ENV: test
      NODE_ENV: test
35

36    steps:
    steps:
37      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
38      - uses: pnpm/action-setup@v4
      - uses: pnpm/action-setup@v4
39      - uses: actions/setup-node@v4
      - uses: actions/setup-node@v4
40        with: { node-version: 22, cache: 'pnpm' }
        with: { node-version: 22, cache: 'pnpm' }
41      - run: pnpm install --frozen-lockfile
      - run: pnpm install --frozen-lockfile
42

43      - name: Rodar migrations
      - name: Rodar migrations
44        run: pnpm typeorm migration:run
        run: pnpm typeorm migration:run
45

46      - name: Testes de integração
      - name: Testes de integração
47        run: pnpm test:integration
        run: pnpm test:integration

Matrix Strategy: Testando em Múltiplas Versões

Para pacotes npm ou projetos que precisam suportar múltiplas versões do Node.js, use strategy.matrix para rodar o job em paralelo com versões diferentes:

compatibility.yml

1jobs:
jobs:
2  test:
  test:
3    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
4    strategy:
    strategy:
5      # Não cancela todas as versões se uma falhar
      # Não cancela todas as versões se uma falhar
6      fail-fast: false
      fail-fast: false
7      matrix:
      matrix:
8        node-version: [20, 22, 23]
        node-version: [20, 22, 23]
9

10    name: Node.js ${{ matrix.node-version }}
    name: Node.js ${{ matrix.node-version }}
11    steps:
    steps:
12      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
13      - uses: actions/setup-node@v4
      - uses: actions/setup-node@v4
14        with:
        with:
15          node-version: ${{ matrix.node-version }}
          node-version: ${{ matrix.node-version }}
16      - run: npm ci
      - run: npm ci
17      - run: npm test
      - run: npm test

Secrets e Variáveis de Ambiente

Nunca coloque chaves de API, senhas ou tokens diretamente no YAML. Use GitHub Secrets (Settings → Secrets and variables → Actions):

Usando secrets no workflow

1jobs:
jobs:
2  deploy:
  deploy:
3    runs-on: ubuntu-latest
    runs-on: ubuntu-latest
4    steps:
    steps:
5      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
6

7      - name: Deploy para VPS
      - name: Deploy para VPS
8        env:
        env:
9          # Secrets são mascarados nos logs — nunca aparecem em texto puro
          # Secrets são mascarados nos logs — nunca aparecem em texto puro
10          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
11          VPS_HOST: ${{ secrets.VPS_HOST }}
          VPS_HOST: ${{ secrets.VPS_HOST }}
12          VPS_USER: ${{ secrets.VPS_USER }}
          VPS_USER: ${{ secrets.VPS_USER }}
13        run: |
        run: |
14          echo "$SSH_PRIVATE_KEY" > /tmp/key.pem
          echo "$SSH_PRIVATE_KEY" > /tmp/key.pem
15          chmod 600 /tmp/key.pem
          chmod 600 /tmp/key.pem
16          ssh -i /tmp/key.pem -o StrictHostKeyChecking=no $VPS_USER@$VPS_HOST \
          ssh -i /tmp/key.pem -o StrictHostKeyChecking=no $VPS_USER@$VPS_HOST \
17            'cd /app && git pull && pm2 restart all'
            'cd /app && git pull && pm2 restart all'
18

19      # Variáveis públicas (não secretas) ficam em vars.*
      # Variáveis públicas (não secretas) ficam em vars.*
20      - name: Notificar Slack
      - name: Notificar Slack
21        env:
        env:
22          SLACK_CHANNEL: ${{ vars.SLACK_DEPLOY_CHANNEL }}
          SLACK_CHANNEL: ${{ vars.SLACK_DEPLOY_CHANNEL }}
23          SLACK_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
          SLACK_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}

Branch Protection Rules: Tornando o CI Obrigatório

O CI só é efetivo se você não puder fazer merge sem ele passar. Configure em Settings → Branches → Add rule:

Branch name pattern: main (ou main,develop)
Require status checks to pass before merging: habilite
Status checks: selecione os jobs do seu CI (ex: TypeScript, ESLint, Jest)
Require branches to be up to date before merging: habilite para evitar merges desatualizados
Do not allow bypassing the above settings: habilite para que nem admins possam ignorar

Use concurrency no workflow para cancelar runs anteriores do mesmo PR automaticamente. Sem isso, abrir um PR e fazer 3 commits em sequência dispara 3 runs simultâneos — desperdiçando minutos de CI. Com cancel-in-progress: true, apenas o run mais recente continua.

Conclusão

Um pipeline de CI bem configurado muda a cultura de uma equipe: o medo de fazer merge some quando você sabe que qualquer regressão será detectada automaticamente em minutos. Jobs paralelos reduzem o tempo de feedback, services permitem testes realistas contra bancos reais, e Branch Protection Rules garantem que nenhum código quebrado chega ao main. O custo é apenas o tempo de escrever o YAML uma vez.