Blog

Antes de “comprar máquina”: descubra onde está o gargalo

Três coisas deixam CI lento (e quase ninguém mede):

1. Fila: job esperando runner disponível.
2. Download: dependências e imagens baixando toda hora.
3. CPU/IO: build e testes realmente consumindo recurso.

A ordem importa porque, se o problema é fila, só otimizar build não resolve.

1. Concorrência: concurrent e limit (o que muda na prática)

No GitLab Runner, o arquivo config.toml controla quantos jobs um runner consegue processar ao mesmo tempo.

Exemplo de configuração:

concurrent = 4

[[runners]]
  name = "runner-dedicado"
  limit = 2

• concurrent (global) limita quantos jobs no total podem rodar ao mesmo tempo naquele host.
• limit (por runner) limita quantos jobs aquele runner específico aceita em paralelo.

Ajuste com consciência:

• se você aumenta concorrência sem aumentar CPU/RAM, você “só divide a dor”
• para front-end, normalmente é melhor 2–4 jobs bem estáveis do que 8 jobs brigando por memória

2. Cache e artifacts: aceleração barata (e altamente subestimada)

Cache (dependências e build intermediário)

Use cache para:

• node_modules (quando fizer sentido)
• pasta do pnpm store / .yarn/cache
• cache de bundler (ex.: .vite, .next/cache)

Ideia simples: baixar uma vez, reutilizar várias.

Artifacts (saídas do job)

Artifacts são bons para:

• build de front (resultado do dist/)
• relatórios (coverage, testes)
• pacotes a serem implantados

Cuidado: artifacts grandes deixam o pipeline lento de outro jeito (upload/download).

3. Tags de runner: separando o que “precisa” do que “pode”

Separar runners por tags resolve dois problemas:

• jobs críticos não ficam presos atrás de jobs longos
• você evita rodar job “caro” em máquina “barata”

Sugestão prática:

• runner:fast → lint/typecheck/unit
• runner:e2e → Cypress/Playwright
• runner:macos → iOS/macOS
• runner:windows → Windows-only

4. Docker executor: performance + isolamento (com um alerta)

O Docker executor é uma ótima escolha porque cada job roda em container e o ambiente fica reproduzível.

O alerta é segurança: dependendo da configuração (ex.: containers privilegiados), você pode abrir riscos desnecessários. Trate “isolamento” como requisito, especialmente se o runner for compartilhar projetos.

5. Checklist rápido de “ganhos fáceis” (30–60 min)

• habilitar cache (dependências + bundler)
• reduzir downloads (pin de imagens base, registry perto do runner)
• dividir pipeline em jobs menores e paralelizáveis
• limitar concorrência para manter estabilidade
• colocar runner em SSD e rede cabeada
• separar tags (E2E não deveria competir com lint)

Referências úteis

• Advanced configuration (concurrent, limit): https://docs.gitlab.com/runner/configuration/advanced-configuration.html
• Docker executor: https://docs.gitlab.com/runner/executors/docker.html