Keeping builds green at scale
summary
Companies adopt a merge queue that replays PRs on the latest main to prevent implicit conflicts; simple queues work for small teams with ~30 minute CI but sequential merges can take ~5 hours. Large teams use batching (size 4) and automatic bisection to cut CI runs and merge time roughly by a quarter (assumes ~10% failure rate), or use multi-queue / affected targets (Bazel-style) to parallelize by build target. Other tactics include optimistic queuing (faster but more CI runs), predictive scoring of PRs, handling flaky tests, and stack PRs plus Aviator integrations.
AI-written summary · about
chapters (13)
- 0:00Introduction and context
- 1:04Mono vs poly repos
- 2:28Why merging is hard
- 4:55Merge queues explained
- 7:28Solving congestion with batching
- 9:18Optimistic queuing
- 11:47Predictive modeling for PRs
- 12:49Multi-queue in monorepos
- 14:53Pre and post merge testing
- 15:13Poly repo dependency issues
- 16:38Stack PRs for code reviews
- 17:44Managing flaky tests
- 18:26Q&A
related talks
14mMerge Queue
35mMQ: merge-queue
26mA State of Continuous Merge: The Secret to More Productive Dev Teams
42mThe solution of merge hell in monorepo
01h 10mCreating efficient, convenient and reliable CI
25mMaximize CI/CD efficiency using AI and a vertically integrated stack
35mOpenShift CI: What if we stopped retesting everything all the time?
20mMaximize development efficiency with expert CI/CD strategies