I’ve struggled a long time with what has become common notation – the “PR”. When I first heard it used, I learned that it was a term used in GitHub but I could never remember what it meant – didn’t match my mental model, so I’d have to look it up again and again.
It is an event that takes place in software development when a contributor/developer is ready to begin the process of merging new code changes with the main project repository. The name “pull request” came from the idea that someone is requesting the project to pull changes from their feature branch.
It’s also referred to as a merge request which makes way more sense to me since that is what is really happening, so now I mentally change PR to merge request and I’m good.
However, I was reading The 2022 State of Testing in DevOps Report by mabl, and got confused all over again when I saw these following charts.
So, when did Pull Requests (request to merge) become a stage in a SDLC? Especially as a stage for executing functional tests. A PR (when accepted) will trigger a build (Continuous Integration) which will run some of the tests – perhaps all. It’s not the PR itself, right?
And how are bugs found in a PR? This chart makes no sense to me at all. I possibly could see bugs being found during the merge with the main branch, but the request itself – no. JUST no.
I think to myself, if I’m confused, what happens to the rest of the world. The terms we use and how we use them, are important.
As I was writing this blog post, I noticed a twitter conversation about PRs started by Matt Wynne. I won’t reiterate the conversation, but it sounds like I’m not the only person with some issues with how the term is being used.
Check out this conversation https://twitter.com/mattwynne/status/1641540417773801478 if you want to see more differing opinions on the subject.
4 comments on “When did PR (pull request) become a stage?”
Why wouldn’t it be considered a stage?
At least in my environment, pull requests are gates – it’s a period between when you think you are done to when you actually are done with a piece of work. Once a PR is opened (not merged) it triggers a lot of other activities that blocks merging – final code review, static analysis and execution of test code against the candidate branch. As a result, this “gate” can last quite a while so it’s not unreasonable to call it a stage.
I think that building is a stage – coding and testing until it’s been deployed and at a minimum passes a smoke test. Until then, it’s still under construction. In my opinion, merge requests are an activity that happens during the building stage. There are many activities (such as the ones you’ve mentioned) until a story is Done. Bugs that are found during development should be treated as part of development. It shouldn’t matter whether it’s during coding or merging – the reason for merging more often.
Hmmm….
I can see why reporting bugs found on a PR might look strange, but if some of the gates in the PR are maintained by another team (in a more siloed environment) it could make sense.
I would say that the main reason I’m not as against this category is that outside of bug-finding, treating the PR gate as a stage makes sense – a lot of metrics are done per state, and tasks can remain there for way too long (so tasks staying at this “stage” are a good hint), once we treat this as a stage, it is simpler to treat is as such in all contexts.
As with everything, context is important. A red flag for me, is that merge requests aren’t happening on a regular basis – pushing out integration. That tells me that perhaps a team needs to fix a different problem. Working with other teams is tricky sometimes, but agreeing on priorities, and removing or mitigating those dependencies, is what I would try to fix vs making ‘merging’ a stage. There is no one thing that “works in all contexts.” My only suggestion is too look at why you may be having that problem, and are you solving the right problem with gates.