loading...

What is the "best" merge request flow?

koen028 profile image Koen Hendriks πŸ’» ・1 min read

We all have been there where we want our merge request to be checked but no one is responding because they are either busy or don't check their messages. What do you do in these situations?

Time to merge

Who has the power to approve your teams merge request? Do you check each others code within a team or do you only let the other team check your code to prevent tunnel vision?

Who is the lucky one to pick up? First come first serve, randomly assigned or do you communicate within the team to share the work load?

How do you deal with your project manager looking at you weird once you tell him you had to check 20 merge request all day and that's why you couldn't finish a story?

Can you expect the person who left feedback to check again immediately after you applied the feedback?

What do you think?

I would love to hear some of your answers to these questions. What kind of processes do you have in place to prevent frustration around merge requests and their approvals?

Seal of approval

Discussion

pic
Editor guide
Collapse
opensussex profile image
gholden

Software development is a communication process. I see most issues are caused because people don't talk to each other. Or if they do, they don't actually talk about the things that matter. This is often caused when "teams" are not really working as a team, but as a group of individuals working on their own.

Most merge problems have been solved by team cohesion.

Collapse
cassandraspruit profile image
Cassandra Spruit

If everyone's too busy or don't check their messages enough to approve a pull request, that's probably an indicator of other problems on a team.

Here's some tips:

Team members are too busy
This is actually a bit of hard one since "too busy" is a bit nebulous and - let's face it - all too common.

  • Is this because of a bottleneck? Do you require a manager or a specific person to sign off? If that's the case, is it really necessary? Can it be shifted off to another person or pushed later in the development cycle?

And sometimes the answer is no - so maybe ask that person to set aside time a scheduled time during the day/week so they don't pile up. Beginning or end of the day before people get into their day works well.

  • Are people busy because they are...well, busy? The scheduling trick works for groups of people too. During some heavy crunch times where everyone's bogged down, we've had to move a "team review time" where everyone who possibly could took a half hour to do code reviews and such. It also helps out with expediting feedback since everyone's available.

Team members don't check their messages

  • If this is pretty common or if it's just one person in particular, you need to talk to your team about communication expectations.
  • It also could be just human nature. You ping the team and let them know (or you have a service that does it) and your team just kinda ignores it because they're in the middle of something and they forget about it. Set a reminder for yourself an hour later (or whatever is reasonable) to remind the team that the PR still needs a review. Keep doing it until someone takes responsibility. Be annoying.

The same applies for feedback. Sometimes PRs can be a messy back and forth business. Usually the person who picked up the code review should be the one to respond.

But to answer the question, I found this to be a good flow:

  • Someone puts in a PR. They notify their team. I don't think I've ever heard of other teams checking code, but that's also because teams generally own the code they change to begin with. Cross-team integration is an art of it's own.
  • Team member responds that they'll pick it up. This is usually a "whoever's available, first come, first serve" sort of thing. I've had teams set a rule that you can't pick up new tasks without clearing out reviews. That's kind of a team-by-team sort of basis on how formal you want to be with it.
  • If every thing is good, PR is approved. QA usually approves it during this point as well, but your mileage may vary.
  • Person who puts in the PR to begin with hits the merge button. I know this sounds like a formality, and 95% of the time, it is. Buuuut that 5% there's something that changes between the PR creation and approval and that one last sanity check has saved me at least a dozen critical bugs.
  • Generally this is a day or two long process. If it starts to drag past three, that's asking for trouble and merge headaches.
Collapse
quii profile image
Chris James

What kind of processes do you have in place to prevent frustration around merge requests and their approvals?

Commit to master. Not joking.

Collapse
bergamin profile image
Guilherme Taffarel Bergamin

We have two system analysts in our team who can accept a merge request into master. That's a mere formality as they have no code expertise. We opted to not let devs do it just as a security measure towards proper versioning and release control.

They will accept the merge request and trigger build and deploy of the production channel.

Developers work in the develop branch until a release is created and sent to test, working in fixes directly in the release while new stuff can be added to develop for the following version already.

These merges that don't involve master can be accepted by the developers themselves.

Collapse
quii profile image
Chris James

That sounds dreadful

Thread Thread
bergamin profile image
Guilherme Taffarel Bergamin

Why, though? It is almost as if devs could commit directly to master, but with this extra step, we can guarantee some order in an environment that is very prone to people sending any proper versioning to hell and losing track of what is being tested or what can be released, etc.

Take a look into these two graphs:

tinyurl.com/thssnpx

Graph 1 is what a common gitflow looks like. My goal is to get my team to work with graph 1.
Graph 2 is what I got so far since I got in the project in the last few months.

Sorry for it not being in English. Quick translation:

Each of the main branches are an environment deployed separately. Jenkins is reading these guys, but it doesn't have to be this way.
M - Master: Production. Only receive merges from release branches, but can be the origin of hotfix branches
E* - Mirror: Same code as production, but with DB from the day before
H* - Release Candidate: The key users test the changes here and aprove them or not
T* - Test: The test team tests the changes here and aprove them or not
D - Develop: This is the origin of every feature branches and the origin of release branches.
B - Hotfix: urgent stuff that can't wait for a release
F - Feature: new stuff or bugs that aren't that urgent. These are your every day issues
R - Release: this is the features package planned to be released next.

*These aren't really needed. You can deploy the RELEASE branch directly in the proper environment.

After you have a good amount of stuff in DEVELOP, you can create a RELEASE and this is what you will give your testers to test. After test, this is the branch you will send your key users as a release candidate. All fixes in the release both from testing and from the users are made directly in it. Meanwhile, you can keep developing the following release into DEVELOP and it will not mess with your current release candidate.

After all set, today we merge into MIRROR just as a prediction of what it will look like in production. Normally that wouldn't really be needed.

All that to say that the merge request into master is the smallest part of all this. By then, the version to be delivered will already be very well tested and there is no point in actually reviewing the whole thing again.

The merge request into master is really only accepted by the system analyst because developers are humans and humans sometimes tend to try shortcuts that can and will mess with everything.

Giving devs only the DEVELOP branch to play with, it is guaranteed that what is being done will eventually be part of a release that will be tested.

Thread Thread
ramonpoli profile image
Ramon Polidura

I agree that you don't need graph 2, graph 1 looks good and is very similar to what we do.

Collapse
jamietwells profile image
jamietwells

Totally agree, it's the only sensible way to develop in my opinion. Everything else is just extra process that slows you down and leads to problems.

Collapse
isherwood profile image
Clint Buhs

The answer depends heavily on team structure and release process (SDLC), but I'd follow with two questions: Why do you have so many pull requests each day? Are pull requests considered important by the team? In other words, does each developer recognize that stagnant pull requests are essentially a hindrance to progress?

Collapse
koen028 profile image
Koen Hendriks πŸ’» Author

Absolutely true! Lets work with some hypotheticals:

Q: Why do you have so many pull requests each day?

A: We work with multiple teams on a handful of projects.

Q: Are pull requests considered important by the team?

A: With code quality as a high priority within the company and having a team consisting out of juniors that are working hard on improving their code quality. I would say yes the team currently considers the pull requests as important.

Q: Does each developer recognize that stagnant pull requests are essentially a hindrance to progress?

A: This one is tricky but lets say you have some mixed responses within the team. Some would say the code quality is very important to them but with the deadlines in mind they don't feel like they can afford having to wait on pull requests to be checked for very long. Where others say that they will win time in the end by having pull request to be checked so they won't have to spend time on bugs or unreadable code later on.

How do you look at this situation? And what have you experienced yourself? Do you have a preferred way regardless of the situation?

Collapse
ramonpoli profile image
Ramon Polidura

I agree and we have a similar problem with PR being stagnant with a big bottle neck with hotfixes in the release branch. So it really comes to team work and hold off creating new pull requests if you have some to review yourself

Collapse
amosshapira profile image
Amos Shapira

The issues you raise point to team problems (I know I'm frustrated with slow reviews in a tiny team), but just putting a potential technical help out there - get everyone on the team to install this: github.com/realyze/CanvaBoy

Collapse
annihil profile image
a

I personally use git push origin master --force --no-verify

Collapse
troywitthoeft profile image
Collapse
nerdsvilleceo profile image
Joshua Santos

It's ok to force push if on your own branch, so I think the comic is a bit inaccurate

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

What is the best way to raise children?

  • there is more than one way to do it
  • there is not one way that works well no matter what your context is

Same for how your team works with code.

Forget about "best practices".
Focus on understanding better what your problems are.

Everything else will follow

Collapse
bergamin profile image
Guilherme Taffarel Bergamin

Take best practices as a guideline. If something doesn't work well, adapt to your reality.

For example, the project I've been working for the last 6 months had a chaotic repository. We have old devs that came from SVN and TFS that would create a branch from master for working on their issues and then merge into environment specific branches (such as test and release candidate) and after the user approves the change in the release candidate channel, it goes back to master. No version definition at all, no definition of what is a release, no tags, no nothing.

The issue branches staid there forever and issues were managed through, I kid you not, an excel file the PM has in her laptop.

We have over a hundred applications being developed by people who have been working there for over 15 years. It is difficult to change some minds.

But at some point I were the only developer in this specific project, so what I did was to act first and ask questions later. I murdered all merged branches (thanks GitLab for this magic button) and decided this project was going to be a POC for using a custom version of gitflow and issues on GitLab.

But this kind of conceptual change should be gradual, so we still have master, develop, release_candidate and mirror branches. That's one for each environment because that's what Jenkins is reading right now (mirror is same code as master and the environment has a copy of production database from the day before).

Now testers know what to test and we don't have to send them an email telling them what was done because we have it well documented in GitLab issues.

Testers are not ignored by arrogant developers any more because they now can open issues on GitLab and we can decide the importance of things as a team during a sprint planning meeting every 2 weeks. That's very important because the PM and the system analysts don't have knowledge of the tech used in the project. Refactoring works aren't ignored by the PM any more as well.

All this to say that best practices are very important. Even more if your process is still not very mature. Best practices also work as a way to make the learning curve for new employees less steep because there is a higher chance of them studying about or working with those instead of your very unique practice.

Just don't take best practices like a law. Take them as a guideline is what I say.

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

Hello, what I propose to do is exactly what you are also doing:

1) First invest time to think about what are the real issues in your particular context
2) Then find out what people finding similar issues have done in the past

I am against "best practices" that start at step 2) and forget the first step.

People end up cargo culting what Google and Facebook and Netflix to solve their problems, forgetting that, well they are not Facebook and Google.