How should a delivery pipeline be structured for a large monorepo where most changes affect a small part of the system?

The structure

Change-aware execution, staged by cost.

1. A dependency graph of the repository, so the pipeline knows which components a change can affect. This is the foundation — without it, every change pays for every test.

2. Stages ordered by cost and feedback value: - Static analysis and format checks — seconds, on everything. - Unit tests for affected components — a minute or two. - Component and integration tests for affected components. - Contract verification for affected providers. - End-to-end tests for critical journeys, on merge rather than on every push.

3. Aggressive caching at every layer — dependency caches, build outputs, container layers, test fixtures — with layer ordering stable-to-volatile, since getting it backwards means a source change re-resolves all dependencies.

4. Remote caching shared across developers and CI, so a build already performed anywhere is not repeated.

5. Merge queues for a busy trunk, testing the combination that will actually exist rather than each change against an older base.

The properties that matter

• Deterministic selection. If the graph is wrong, a change breaks something the pipeline did not test. The selection logic must be conservative and its correctness verified by periodic full runs.
• A full run on a schedule, catching what selection missed and detecting drift in the graph.
• Cancel superseded runs, since only the latest commit on a branch usually matters.
• Priority classes — a release build, a merge-blocking build and a nightly are not equal, and FIFO under burst queues the most urgent behind the least.

The security structure

Trust separation is architectural, not a setting. Builds from external contributions run without deployment credentials; only trusted-branch builds after review receive them. And the pipeline definition itself must come from the trusted branch — otherwise a contributor who edits the workflow bypasses every other control.

The metric

Time to actionable feedback at the developer-experienced percentile, plus the proportion of pipeline time spent on components the change could not affect — which is the direct measure of whether selection is working.