Scaling a monorepo with 100+ engineers
January 31, 2025
- Team Size
- 203
- Structure
- Monorepo
- CI Runtime
- ~
- Deploys
- Continuous
- Featured integration
- MergeQueue
Mae Capozzi
Mae Capozzi is a senior software engineer with a focus on design systems and frontend infrastructure. She is the co-founder of Dedicated Co and she runs a newsletter Design Systems Newsletter in which she writes about design systems and frontend engineering.
Challenge
Amplitude's growing engineering team faced frequent mainline branch breaks and conflicts, requiring constant intervention from their frontend infrastructure team. Before Aviator, their solution was to use GitHub Actions for early morning rebases, which proved costly and inefficient. This also resulted in broken changes being introduced into the mainline branch due to outdated code and conflicting changes when multiple engineers merged pull requests simultaneously.
Mae Capozzi
As the number of engineers at Amplitude increased, this problem was happening more often. And it was pretty common that the front end infrastructure team would have to jump in and try to triage the issue and figure out either how to fix it or find out who the right person was to fix it. Amplitude's growing engineering team faced frequent mainline branch breaks and conflicts, requiring constant intervention from their frontend infrastructure team. Before Aviator, their solution was to use GitHub Actions for early morning rebases, which proved costly and inefficient. This also resulted in broken changes being introduced into the mainline branch due to outdated code and conflicting changes when multiple engineers merged pull requests simultaneously.
Integration
Aviator StackedPRs enables Amplitude's developers to break up large pull requests, keeping code reviews manageable.
My manager at the time had been thinking about merge queue solutions. We compared GitHub's merge queue tool with Aviator and ultimately chose Aviator for the benefits beyond the merge queue. We've been really loving stacked PRs.
I like having the confidence that when I merge my code, if it's passed the checks, it's because it's actually passed the latest checks with the latest code. It saves me a lot of time trying to triage why the main branch isn't working or is broken. I just appreciate not having that on my plate anymore.
Mae Capozzi
My manager at the time had been thinking about merge queue solutions. We compared GitHub's merge queue tool with Aviator and ultimately chose Aviator for the benefits beyond the merge queue. We've been really loving stacked PRs.
Impact
Amplitude's engineering leadership evaluated different merge queue solutions, including GitHub's native offering. They ultimately chose Aviator because it:
- Eliminated costly GitHub Action runs
- Reduced mainline branch breaks
- Decreased time spent on issue triage
- Improved developer confidence in merges
Mae Capozzi
I like having the confidence that when I merge my code, if it's passed the checks, it's because it's actually passed the latest checks with the latest code. It saves me a lot of time trying to triage why the main branch isn't working or is broken. I just appreciate not having that on my plate anymore. Amplitude's engineering leadership evaluated different merge queue solutions, including GitHub's native offering. They ultimately chose Aviator because it:
Feature highlight
For a team with 100+ engineers working in a monorepo, visibility into the merge process proved crucial. Aviator's merge queue visualization gave developers clear insight into PR status and merge order, eliminating confusion and reducing coordination overhead.
As one engineer noted, when developers ask "why hasn't my PR been merged yet?", they can now simply check the dashboard to understand their place in the queue.
Mae Capozzi
As one engineer noted, when developers ask "why hasn't my PR been merged yet?", they can now simply check the dashboard to understand their place in the queue.