# O Que É Fan-Out / Fan-In em Pipelines de CI?

> Fan-out divide o trabalho em muitos jobs paralelos; fan-in reúne os resultados em um só. Aprenda este formato central de pipeline e como ele acelera o CI.

Source: https://latchkey.dev/pt/learn/ci-cd-concepts/what-is-fan-out-fan-in  
Updated: 2026-06-25

Fan-out divide um estágio em muitos jobs paralelos; fan-in espera todos eles e junta os resultados. Juntos, eles permitem que o CI vá para o largo em busca de velocidade e depois estreite para um único veredito.

Fan-out/fan-in é o formato fundamental de um pipeline paralelo. É como você reduz o tempo de relógio distribuindo o trabalho entre jobs, terminando ainda assim com um único resultado agregado que serve de gate.

## Fan-out

Um único ponto do pipeline se ramifica em muitos jobs independentes que rodam concorrentemente - dividindo uma suíte de testes em shards, buildando vários targets ou executando uma matrix. Cada ramo é isolado e progride em seu próprio runner.

## Fan-in

Depois do trabalho paralelo, um único job depende de *todos* os jobs do fan-out e roda apenas quando eles terminam. Ele agrega as saídas - mesclando relatórios de teste, combinando coverage ou simplesmente atuando como o gate que só fica verde se todo ramo passou.

```needs: collects the fan-out
jobs:
  test:
    strategy: { matrix: { shard: [1, 2, 3, 4] } }
  report:
    needs: test   # fan-in: waits for all shards
```

## Por que usar

- Velocidade: N shards paralelos terminam em cerca de 1/N do tempo serial.
- Um único gate de fan-in dá um pass/fail claro para todo o estágio.
- A agregação (coverage, relatórios) acontece em um só lugar.

## Armadilhas

Fan-out multiplica os minutos faturáveis e pode inundar um pool de runners, causando enfileiramento. O job de fan-in é um ponto de sincronização - ele só é tão rápido quanto o ramo mais lento, então uma divisão desbalanceada (um shard muito mais pesado que os demais) desperdiça o paralelismo. Balanceie os shards.

## FAQ

### What is What is Fan-Out / Fan-In in CI Pipelines??

Fan-out/fan-in is the fundamental shape of a parallel pipeline. It is how you cut wall-clock time by spreading work across jobs while still ending with one aggregated, gating result.

### Fan-out?

A single point in the pipeline branches into many independent jobs that run concurrently - splitting a test suite into shards, building several targets, or running a matrix. Each branch is isolated and progresses on its own runner.

### Fan-in?

After the parallel work, a single job depends on *all* of the fanned-out jobs and runs only once they complete. It aggregates their outputs - merging test reports, combining coverage, or simply acting as the gate that is green only if every branch passed.

### Pitfalls?

Fan-out multiplies billable minutes and can flood a runner pool, causing queueing. The fan-in job is a synchronization point - it is only as fast as the slowest branch, so an unbalanced split (one shard far heavier than the rest) wastes the parallelism. Balance the shards.

---

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