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?
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?
Top comments (17)
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.
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.
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.
Team members don't check their messages
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:
Commit to master. Not joking.
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.
That sounds dreadful
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.
I agree that you don't need graph 2, graph 1 looks good and is very similar to what we do.
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.
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?
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?
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
I personally use
git push origin master --force --no-verifyMonster
images.app.goo.gl/cJhp4uT7jW24EqsZ8
It's ok to force push if on your own branch, so I think the comic is a bit inaccurate
What is the best way to raise children?
Same for how your team works with code.
Forget about "best practices".
Focus on understanding better what your problems are.
Everything else will follow
#discuss Are "best practices" overrated?
Jean-Michel Fayard (fr/en/es/de) γ» Sep 27 γ» 2 min read
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.
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.