Solving The Pull Request Problem With Continuous Merge

Fact: the state of pull requests is broken and we finally have the data to prove it. In our latest LinearB Labs episode, we reveal the information that has led us to the inevitable conclusion that pull requests have become a massive source of toil, bottlenecks, and a huge barrier to shipping.

Better yet, two people who have been thinking about how to attack this dev workflow issue, Dan Lines and Ori Keren of LinearB, are ready to actually propose a solution: continuous merge.

The next step in CI/CD, continuous merge is the concept of creating lanes where pull requests can be merged based on their risk. Plain and simple, pull requests should not all be treated the same.

The first step in continuous merge proposed in the episode is the dev tool GitStream, which automates and optimizes merging pull requests based on risk and level of attention required.

A game-changing conversation, this episode is the first time you might hear about continuous merge, but it certainly won’t be the last.

Episode Highlights

• (3:10) A history of CI/CD
• (10:15) The #1 undiagnosed problem in developer experience
• (15:00) What's happening industry-wide in VSM
• (18:32) Giving devs a better tool: Continuous Merge
• (24:09) Not all PRs should be treated the same
• (28:21)  75-80% of all PRs have no changes being made 
• (34:40) What is GitStream?

Episode Excerpts

What Is GitStream?

Dan: We have a new product. It's called GitStream. It's like super, super cool. Lots of teams using it and there's a few features that I'm going to go over here that relate to all of the problems that we've been talking about, bottlenecks that developers are going through, the toil that they’re experiencing. The first thing about GitStream is it's totally programable. We've been talking about rules. We're actually using what we call .cm files. This is a file that you can describe the characteristics of the changes, like the size of the change, the coverage of the change, security of the change. And when you're able to describe these different criteria or these different characteristics of a PR, you can then put them into lanes of different actions. Some of them should be auto approved, for example. Okay, it's just a change to documentation. Let's approve that with GitStream. Other ones like we've said, hey, maybe it is a really, really big PR and it needs a particular person to review it. It has to have, you know, the service only review. This allows you flexibility to do that. So now every team- and of course something we learned, every team and project is different and that's why you need this flexibility. All programable to create your own rules.

Ori: Yeah, some of our customers are saying, you know, this product is still in POC mode. So maybe I don't need- like, it's still not out in production. Maybe I don't need any PR review, so you can have rules like... right? If it's in this repository and these two developers are like POC mode just automatically merge and now things are not by...

Dan: Yeah. Every repo is different. Every maturity level of the project is different. So now you know, we give a few basic rules out of the box, but every team can program, you know, however they want to classify and take action on PRs. Now the other interesting aspect of it, Conor, that you were getting to, is that there's an IDE extension. So if you're using VS Code, there's an extension there that can be installed. And while you're developing as a developer, you can see what lane you're fitting into and you can see what you need to do to get to lane A, B, or C. So, for example, let's say that the fast lane criteria is 100% of my changes need to have unit test coverage. Well, you know that our plugin will say something like yeah, you know, you're 90% of the way there, but you haven't achieved this fast lane yet. Here's where you have to do to get there. Oh, now I'm incentivized to do the right thing. So I can get my code merged faster. And I think that's like the last, like important, extremely important aspect of a CM solution. You have to give the developers visibility while I'm coding.

Not All PRs Are Equal

Dan: What I see happening when I talk to developers and development teams is all changes right now... So changes to the code base are being treated like they're all exactly the same and they're not exactly the same. So as an industry right now, most of the time we're saying regardless of the change, so regardless of the size of the change, the risk of the change, the service that it's changing, the repo that it's in, we're going to go through the same review process. Usually, it's something like, I'm going to open a PR, I might assign the PR to at least one person, or I might ask in a Slack channel, can someone review this PR? They're going to pick that PR up when they're ready. Of course, they're already working on something completely different. They're going to have to change what they're doing. Come to my PR, a few asks back and forth. I'm changing code, I'm updating it, and eventually, it gets merged. That's the process that let's say 95% of teams are going through today. And we feel that if we're able to, and this is what we've been able to do now, treat these peers or treat these changes differently based on a few factors. We can unlock that bottleneck.

Additional Video and About Interact

Also, you are invited to join engineering leaders from Shopify, Stripe, Slack, and more at Interact on October 25th. This is a free, virtual, community-driven engineering leadership conference featuring over 25 of the most respected minds in development, all selected by the thousands of engineering leaders in the Dev Interrupted community.