Scaling a monorepo with 100+ engineers
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 called Design Systems Newsletter in which she writes about design systems and frontend engineering.
Any team, especially teams that are working in a monorepo where a hundred plus engineers are merging things all at the same time and things are maybe highly coupled with each other... if those types of teams start seeing that their main branch is breaking once a day or more, I think that's probably time to consider using a tool like Aviator.
Challenge
Amplitude's growing engineering team faced frequent mainline branch breaks and conflicts, requiring constant intervention from their frontend infrastructure team. Before Aviator, their initial solution was to use GitHub Actions for early morning rebases which proved costly and inefficient. However, this resulted in broken changes being introduced into the mainline branch due to outdated code and conflicting changes when multiple engineers merged pull requests simultaneously. Even the frontend infrastructure team frequently needed to triage and fix mainline issues, which the team attempted to solve with costly GitHub Actions running early morning rebases.
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.
Mae Capozzi
My manager at the time had been thinking about merge queue solutions. I think he proposed, I think GitHub has sort of like a merge queue tool and he was kind of comparing that with Aviator and ultimately chose Aviator for like benefits beyond the merge queue. Especially we've been really loving stacked PRs.
Mae Capozzi
Integration
Aviator StackedPRs enables Amplitude's developers break up large pull requests, keeping code reviews manageable.
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
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
Any team, especially teams that are working in a monorepo where hundreds, hundred plus engineers are merging things all at the same time and things are maybe highly coupled with each other... if those types of teams start seeing that their main branch is breaking once a day or more, I think that's probably time to consider using a tool like Aviator.
Mae Capozzi
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.
Join us at The Hangar
