Skip to content
Latchkey

O Que É um CI Runner? Managed vs Self-Hosted Explicado

Um runner é simplesmente o computador que executa seus jobs de CI. O tipo que você escolhe determina a velocidade, a confiabilidade e o custo do seu pipeline.

A integração contínua precisa de algum lugar para efetivamente executar o trabalho - checkout, build, teste, deploy. Essa máquina é o "runner". Ele pega um job na fila, executa cada passo, reporta o status de volta e (geralmente) é destruído depois.

Runners hosted

Seu provedor de CI fornece VMs efêmeras sob demanda. Elas são fáceis e não exigem manutenção, mas você paga por minuto, tem tamanhos de máquina fixos e começa em cold start a cada vez. Builds pesados ou especializados podem ser lentos ou caros.

Runners self-hosted

Você roda o agente do runner nas suas próprias máquinas. Você controla o tamanho, as ferramentas e o cache, e pode ser mais barato em escala - mas você é responsável pelo patching, escalonamento, limpeza e pelos problemas de confiabilidade (o disco enche, os runners ficam obsoletos) que acompanham uma infraestrutura de longa duração.

Runners managed

Uma plataforma de runners managed dá a você controle e economia no estilo self-hosted sem operar a frota você mesmo. O provedor cuida do provisionamento, escalonamento, cache e limpeza. Os melhores adicionam recursos de confiabilidade por cima - por exemplo, recuperando-se automaticamente de falhas transitórias e de recursos para que jobs instáveis não quebrem seu build.

De onde vem o custo

  • Minutos cobrados enquanto os jobs rodam (e ficam na fila, em algumas configurações).
  • Cold starts e instalações lentas de dependências que inflam cada job.
  • Re-runs causados por falhas transitórias - pagando duas vezes pelo mesmo job.
  • Runners superdimensionados usados "por precaução".

Principais conclusões

  • Um runner é a máquina que executa jobs de CI.
  • Hosted = fácil, mas cobrado por minuto e com tamanho fixo; self-hosted = controle, mas você o opera.
  • Runners managed dão controle + economia sem o fardo de operações.
  • Re-runs por falhas transitórias são um custo oculto e evitável.

Guias relacionados