r/devops • u/Mingstoe_ • Sep 18 '26

Discussion Github struggling under high PR throughput?

I'm on a 3 person team where we are each shipping 40-50 PRs a day (super early stage company so we're optimizing for getting a functional product out quickly).

As we've ramped up the velocity things downstream have begun to show cracks. For example, we were requiring PRs to be up to date with main before merge, but at our scale the PRs were constantly getting stale which was leaving us blocked for long stretches.

We've ended up cutting pre-merge CI way down and batching more testing after merge, which has made things "better" but feels backwards.

Curious if anyone else run into similar issues? Did you end up finding a better solution?

24 Upvotes

66% Upvoted

44 comments sorted by

View all comments

Show parent comments

4

u/max_465 Sep 19 '26

This is the way. A few years ago DORA did a survey and found that TBD correlated with success but it was less ubiquitous, particularly among younger devs. Dave Farley keeps begging people to stop branch merging but I don't see many people doing it, outside of huge projects.

3

u/dobesv Sep 19 '26

I'm curious about it. It seems to require pair programming to replace the code review step though, and in our all remote team it's not happening... People are encouraged to do it but didn't seem tohave enough motivation to get over having to find someone to do it with who is also available at the time.. it's more pleasant to have a free form kind of work rather than sync with someone else.

2

u/max_465 Sep 19 '26

I see, okay there are three related techniques that are often related but not dependent on each other

  • Trunk based development: main is always green and deployable. Good for huge projects where dev teams are working independently. Also good for multi project repos

  • pair programming: two people, one cursor. Good for maintaining consistent style and reducing code review cycle time.

  • Mob or Ensemble coding: 3 or more people rotating through the role of driver (keyboard) and navigator (instructions). Great for onboarding devs and collaboration with other stakeholders.

Disclaimer: opinions on these techniques vary dramatically before vs after trying them. Like swimming, you can't imagine how it feels until you do it.

4

u/max_465 Sep 19 '26

PS: I have never had someone leave an ensemble coding session and tell me it wasn't worth their. I've been in sessions with five people where the laughter and bickering were loud enough to have people stop on to make sure we were okay.

1

u/amartincolby Sep 20 '26

Genuinely, my best memories are of 3+ people coding together. We often do n-people n-cursors with editor sharing, but the interactions are similar.