CI/CD · Ship safely, repeatedly

How do you run CI efficiently in a monorepo?

Hardmonorepoaffected buildsremote cacheUpdated Oct 2026
Quiz this track

Short answer

Build a dependency graph of projects, run only affected tasks and their dependents, use a remote cache, and parallelize across the graph. Keep changes atomic and ownership clear so the graph stays accurate.

In a monorepo, running every project test on every change is too slow and too expensive. The alternative is to compute what a change affects and run the minimum correct set of tasks, including dependents that consume a changed package.

  • Model project dependencies explicitly so affected analysis is reliable
  • Run tasks for changed projects and everything that depends on them
  • Share a remote cache so one CI run can reuse outputs from another
  • Parallelize across the task graph while respecting dependencies
  • Use CODEOWNERS or equivalent to route review and ownership
  • Keep lockfiles and workspace configuration consistent across the repo
sh
npx nx affected --target=test --base=origin/main --head=HEAD
npx nx affected --target=build --base=origin/main --head=HEAD --parallel=4
Affected analysis is only as correct as the dependency graph. A missing edge can silently skip a dependent project, so treat graph changes and generated configuration as reviewed code.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How does affected analysis decide what to run?
  2. 2What is a remote build cache?
  3. 3How do you handle a shared library change?
  4. 4What breaks monorepo CI correctness?

Say it in the interview

I model the repository as a dependency graph and run only the projects affected by a change, plus their dependents. A remote cache lets CI reuse outputs across runs and machines, and task orchestration parallelizes independent work. The graph has to be accurate, because a missing dependency edge means a skipped test. I also keep ownership and review routing clear so a large repository does not become a free-for-all.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.