This model uses dedicated end-to-end lanes rather than per-stage worker pools: each lane is a full physical pipeline that carries one commit all the way from build to deploy before it can accept another. A commit waiting in the queue can only start once an entire lane frees up — the capacity constraint is lanes, not individual stages.
lane free? → pull next commit
run build → lint ∥ unit (parallel) → join → UI test → deploy
any stage fails → job topples off the lane, freed early
all stages pass → deployed, lane freed
- Parallel lanes — how many commits can be fully in-flight at once; more lanes raise throughput but each lane still runs its stages one after another.
- Commit rate — arrivals into the shared queue behind the lanes; outrun total lane capacity and the queue at the spawn point grows.
- Failure probability — a failed stage topples that job off the track (watch it fall) and frees its lane immediately, faster than a full successful run — a real dynamic in CI: red builds churn through capacity quickly, green ones hold it longer.
- Orbit the scene by dragging — the floor strips mark the build (blue), lint/unit-test (purple/teal, running as two parallel rails), UI test (amber) and deploy (green) zones shared by every lane.
Real-world relevance: this is how self-hosted GitHub Actions runners or Bitrise/Codemagic build machines are usually provisioned for mobile CI — a fixed pool of full runners, each occupied for a whole workflow run, versus the shared per-stage agent pools used by some Jenkins/GitLab setups.