In fast-paced mobile app development, some teams seek methodologies that optimize efficiency, collaboration, and delivery. Trunk-based development has emerged as an approach, providing a framework for continuous integration and faster releases. In this blog post, we will delve into the world of trunk-based development and explore its benefits and challenges in the context of mobile app development.
What is trunk-based development?
I tend to call it a git branching strategy. Simplifying it, you have just one branch (eg. master) called trunk (or mainline) and everything gets merged into it. No release branches, no develop, no feature branches and so on. Instead of creating feature branches for individual tasks, developers continuously integrate their code into the shared trunk. The focus is on small and frequent commits, allowing the team to collaborate closely and maintain a highly stable codebase. Continuous integration and automated testing are critical components of trunk-based development to ensure that changes do not introduce regressions.
When implementing trunk-based development you might need to go wider
Implementing trunk-based development in mobile might require adjustments to existing workflows. In my opinion, there are some prerequisites:
- CI/CD pipeline needs to be set up and working,
- you need to have tests (will get into more details later),
- you need to have feature flags to protect unfinished features from leaking to users,
- you need to trust your teammates.
One source of truth
One of the core principles of trunk-based development is the concept of “one source of truth.” With all developers working on the master, there is no divergence in codebase versions. This reduces the chance of conflicts and makes it easier to track changes. What’s more, you don’t need to spend time thinking if the quickfix branch was merged into master and develop. Everything is on master. That’s your truth.
Release cycle
Most of the time, it’s easier to release a new version of the app. You just create a Release Candidate from main, you tag the commit that you made the RC from and voilá, you are good. Simple as that. You don’t have to create a release branch from develop, then merge it to master etc. One branch to rule them all.
Things might go a little bumpy when you spotted a bug in the previous version, and the trunk is already 20 commits further. What about such a situation? There is an easy way. If you don’t want to spend time running regression tests on all new commits, you just have to create a hotfix branch, from the commit you previously tagged. Fix the bug and run the CD pipeline from it. Once the version is done, merge it back to the trunk branch.
Feature flags
In the context of trunk-based development, feature flags play a crucial role in enabling controlled feature rollouts and A/B testing. However, as this is an extensive topic, we will discuss it in detail in another blog post.
Conflicts everywhere
Working on a shared trunk can sometimes lead to conflicts, especially when multiple developers are modifying the same files simultaneously. However, with proper communication, frequent integration, and small code changes, these conflicts can be minimized.
Definitely, the number of conflicts is smaller than when using GitFlow. Especially when you have long-lived branches.
To review, or not to review?
In the world of software development, code reviews have become a standard practice. Originally, pull requests were supposed to assure good code quality, knowledge sharing, and catching potential issues before they make it into the codebase. But does it work like this? Isn’t it that sometimes it’s about code formatting, missing brackets or typos. Do you always get the feedback that you want? Don’t you feel that sometimes PR slows you down?
In dynamic development, some teams choose to take a different approach and skip formal pull requests.
From my experience, that could work in mature teams. It can be considered as a pragmatic choice. It allows developers to maintain a fast and agile development process without unnecessary overhead. If a developer spots a bug or has an improvement to implement, they can confidently make the changes directly to the shared trunk.
I am not trying to say that you should remove PR. If you would like to get a 2nd opinion of your code, make a pull request and ask your teammates for the review. Otherwise, just merge it to master!
However, it is essential to recognize that this approach might not be suitable for all teams. The decision to skip pull requests should be made with careful consideration of the team’s dynamics and seniority. If you are struggling with code quality or you don’t have a mature team, you probably have different things to fix before you skip PRs.
Is there anything special about mobile?
In my opinion development cycle, of mobile is slightly different than the web. We have to maintain more versions of the app, as users might not update their apps right away.
That affects trunk-based development in mobile. Especially the feature flags part and testing after RC is published to stores. Otherwise, it’s just normal trunk-based development. 😇
Conclusion
Trunk-based development is a different approach than we were thought. It speeds up the development and makes it more dynamic. However, that might be a big step for you and your team. You should think about the pros and cons, and discuss it with your team. Once you are done, just test it! If it does not work for you, you can simply take a step back and revert to the old flow.