# O Que É um CI Server?

> O que é um CI server? Aprenda o que faz um servidor de integração contínua, como ele coordena builds e runners, um exemplo e por que fica no coração do CI/CD.

Source: https://latchkey.dev/pt/learn/ci-explained/what-is-a-ci-server  
Updated: 2026-06-26

Um CI server é o sistema que observa seu repositório, dispara pipelines em mudanças e coordena as máquinas que fazem build e testam seu código.

O CI server é o orquestrador da integração contínua. Ele escuta mudanças de código, decide qual trabalho executar, despacha esse trabalho para os runners e coleta os resultados, transformando um conjunto de scripts em um processo automatizado e observável.

## O que ele faz

Um CI server detecta eventos, como um push ou pull request, procura a definição de pipeline para o repositório e agenda os jobs resultantes. Ele entrega esses jobs a máquinas de execução (runners), acompanha seu progresso, agrega logs e resultados e reporta o status de volta ao desenvolvedor, muitas vezes como um check no pull request.

## Servidor versus runner

Vale separar dois papéis. O CI server é o cérebro que agenda e coordena; o runner é o músculo que de fato executa o build e os testes. Um servidor tipicamente despacha trabalho para muitos runners para que os jobs possam rodar em paralelo. No GitHub Actions, o serviço hospedado pelo GitHub é o servidor e os runners fazem o trabalho.

## Um exemplo

Um desenvolvedor abre um pull request. O CI server vê o evento, lê o arquivo de workflow e enfileira um job para fazer build e testar a mudança. Ele atribui o job a um runner disponível, transmite os logs de volta e, quando o runner termina, marca o check do PR verde ou vermelho.

## Por que é central

O CI server é o ponto único que amarra as mudanças de código à verificação automatizada. Sem ele, builds e testes seriam rodados manualmente, de forma inconsistente. Com ele, cada mudança é verificada da mesma forma, automaticamente, com um resultado visível. Sua confiabilidade e a velocidade de seus runners moldam diretamente quão agradável o CI se sente.

## Runners hospedados versus autogerenciados

Muitos serviços de CI oferecem runners hospedados para que você não gerencie máquinas, mas esses podem ser lentos ou caros em escala. Plataformas de runner gerenciado como a Latchkey fornecem runners mais rápidos e confiáveis que se conectam ao mesmo CI server, melhorando a parte do sistema que os desenvolvedores mais sentem.

## Applying this to your pipeline

- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

## FAQ

### What is What is a CI Server??

The CI server is the orchestrator of continuous integration. It listens for code changes, decides what work to run, dispatches that work to runners, and collects the results, turning a set of scripts into an automated, observable process.

### What it does?

A CI server detects events, such as a push or pull request, looks up the pipeline definition for the repository, and schedules the resulting jobs. It hands those jobs to execution machines (runners), tracks their progress, aggregates logs and results, and reports status back to the developer, often as a check on the pull request.

### Server versus runner?

It is worth separating two roles. The CI server is the brain that schedules and coordinates; the runner is the muscle that actually executes the build and tests. One server typically dispatches work to many runners so jobs can run in parallel. In GitHub Actions, the GitHub-hosted service is the server and runners do the work.

### An example?

A developer opens a pull request. The CI server sees the event, reads the workflow file, and queues a job to build and test the change. It assigns the job to an available runner, streams back logs, and once the runner finishes, marks the PR check green or red.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt