Why did we remove develop branch in mobile team?

From the title of this article, you already know that in mobile team we did something unusual. Why did we do it? What was motivating us? How did it affect our daily work? Are we happy about it? This article will answer all those questions, so grab your coffee and let's go!
Wednesday, March 30, 2022

Problem statement

Imagine a following situation. You are supposed to release a new version of the app. You seal current version of develop and you create a release/1.2.3 branch. Tester tests it and finds several issues. In meantime, other teammates implemented new features on develop and you can't come back to it. So you do bug fixes on release/1.2.3. The cycle repeats. More bugs are being found and you have to fix them once again. After 2 weeks of fixing you finally release 1.2.3 to production! Congratulations [meme]. But hey, now you need to merge 1.2.3 both to main and to develop. You start merge/rebase and kabooom. Conflicts. Only 57. Last time it was much more as 1.2.2 branch was living for more weeks. Nightmare. And that's what we were facing recently in mobile team.

Context

In mobile team we are responsible both for mobile app and for bff (backend for frontend) API. This means we have to maintain two repositories. It ain't a problem at all. Solving huge number of conflicts every week was the something we wanted to get rid of. On a daily basis we try to simplify stuff. Recently, we are focused on having nice "developer experience" in the team. That's why we decided we need to kill long living branches as they were the problem.

Solution

During one knowledge sharing session (yes, we do have those in Simployer), one team leader (besos Łuki), introduced us to "trunk based development" (TBD). If you don't know what that is, let me explain. Generally it is the opposite of "Gitflow". You have one "trunk" branch that you commit too (either by PR or "directly too master" - up to you to decide). I don't want to get into technical details, if you want to learn more I recommend watching this video.

After giving it a thought we decided it's worth checking how it works. We merged everything to "main" branch and... our life became simpler. Let's list the advantages of this approach

  • Each PR that we do is targeting main branch. If there are conflicts we fix them immediately.
  • main is always up-to-date and we don't have to think to which branch did we commit bugfix
  • we have to maintain only one branch - we have other branches but those are only for development purposes
  • testers have only one branch to check
  • we are ready to make a version with short notice.
  • we are not frustrated by solving conflicts for many hours

Of course, nothing comes free and there are cons as well. Let's take a look at them.

Side effects

Having one branch means that you have one version of code. In theory, you should be able to release it anytime. But how to do it? How to assure that you don't release something that is yet not production ready?

Feature toggles to the rescue

Feature toggle is a mechanism that prevents you from releasing stuff that is not ready yet. When we start developing new feature, we need to wrap it with feature toggle mechanism. Then we can disable that toggle on production. When developing the feature locally you can enable it and work on it. When a tester wants to test it he can turn on the feature on his own and test it.

This means we can safely develop new features. What's awesome it that we have an option to release the app from main branch whenever business wants it.

Mindset

On top of the above, I strongly believe that when having TDB in the team, you might need to adjust the mindset. Having one branch means, that you need to your code is either production ready or hidden behind feature flag. This leads to the situation when you need to be more careful about the stuff you are doing. You don't want to break production when you need to release quick fix.

Conclusion

After reading this you may think what was the reason for writing this article? To me, trunk based development approach is better then github flow. As a leader of mobile team, I've seen that we got easily frustrated when solving big batches of conflicts. Secondly, I feel in mobile world we don't do TBD approach. Maybe some of you after reading this article will give it a go. I am not saying this is an answer to all development/git problems but for us it made our lives simpler. Lastly, this article was written so you can learn more about mobile team and how we work. Maybe one day you would like to join us and it won't surprise that we push "directly to master"…