Iterate Software Faster with Trunk-based development
Trunk-based development can be chosen over Gitflow when we need to increase productivity and speed of software iteration.
When discussing Trunk-based development with other developers I have come across controversies and opposing opinions. I am one of those people who like this concept over Gitflow because we can increase productivity and speed of software iteration by simplifying the process of merging new code into the repository.
Trunk-based is a branching model where we only have one branch (trunk) as mainline development and a single source of truth. Any changes we make will be merged into the trunk branch. When we will release the software we will make a branch release by checkout the trunk branch. With Trunk-based development we can get feedback from the team faster. We can avoid the usual merge problems we face when using Gitflow. Each developer will also get the latest version of the code running in production.
In this article, we will try to discuss Trunk-based development in more detail, and clear up some misconceptions about this topic. When implementing Trunk-based development we need to change the mindset and some adjustments when branching. So let’s first discuss the basic differences between Trunk-based and Gitflow.
Trunk-based vs Gitflow
Trunk-based and Gitflow are two different approaches to managing the source code of the software. Both also have different ways of implementing Continuous Integration and Continuous Delivery. However, the two concepts are similar, when we have mastered one of them there should be no problems learning the other.
Gitflow
Gitflow is a branching model for Git created by Vincent Driessen. This concept is very popular because it makes it easier for us to collaborate and easy when teams start scaling. We have to remember quite a lot of commands, to make things easier we can use the help of the git extension to automate some parts.
How Gitflow works?
- The developer will create two branches, master and development.
- All changes when developing a feature will be merged to the development branch, the master branch is used when you want to release
- When a bugfix occurs we will do 2 pull requests to development and master
- To do a rollback we can use the revert operation menu on the repository that is used
Trunk-based
Unlike Gitflow when implementing Trunk-based development we will merge every small change made to the trunk branch. One thing to note is that the CI process will continue to be carried out to ensure these changes don’t break existing functionality. Thus we must make these small changes compatible with the existing system and ready to be released at any time.
How Trunk-based works?
- Developers only use one branch (trunk) as mainline development
- All changes when developing features will be merged trunk
- Any changes will be pulled from the trunk
- When a bugfix occurs, we will do a trunk pull request and then create a new release from that branch
- To rollback we will checkout the new branch using the commit hash where we revert the changes.
Benefits
Reduce Complexity
One of the main benefits of Trunk-based development is the reduced complexity of merging multiple branches into one.
Avoid merging hell
By implementing Trunk-based development we can avoid the merge hell commonly found in Gitflow. This condition can occur because we combine two different change codes with the same work location. This can create unexpected bugs, become blocked when you want to deploy, and increase the level of stress because you have to fix the merge conflict.
Increase speed of delivery
According to the State of Devops 2021 report issued by Google, high-performing organizations are more likely to have implemented Trunk-based development. Developers will work on small batches and merge to trunk frequently. Teams will also get the latest changes more easily.
Shortening the feedback loop
Changes that are merged into the trunk must be releasable. We can avoid merging multiple branches before they can be released. The bugfix process is also easier, we just need to fix it on the trunk branch and then create a new release.
Best Practices
Develop in small batches
Any changes made must be immediately merged to the trunk. Developers must immediately merge even though the features being developed have not yet been completed, other than that it is necessary to pay attention to make sure the merged changes to the trunk must be releasable and don’t break the existing system.
Synchronous code Review
One of the main concepts in implementing Trunk-based development is as soon as possible to merge all changes into trunk, to achieve this of course we need to change the way we do code reviews. Try to keep code reviews synchronous and create feedback loops as fast as possible, avoiding pull requests waiting several days to merge to trunk as much as possible.
Automation Test Before Merge
Before merging changes to trunk, make sure the code passes the automation test. If we use github we can enable protected branches so that all tests must be passed before we can do pull requests. With the help of this automation test, we can reduce the potential for changes that can break the existing system.
Fast build system
Iteration speed is an important factor in Trunk-based development, one of the important components in it is the build system. We have to make the system build as fast as possible so that it doesn’t become a barrier when we want to merge. This is a difficult challenge, but don’t worry because many tools that can be used, such as Bazel which was created by Google to solve this problem.
Feature Flags
We can use feature flags to set which code is ready to be released into production. We can set these feature flags when the software is built or can also be controlled during run-time using additional tools like LaunchDarkly or GrowthBook. With feature flags we can also implement a canary release, which is to open a new feature to a group of users before it is released on a massive scale.
Conclusion
Trunk-based development is the right solution if we want to increase the release speed and software iteration, every change can be obtained by other developers faster. But before implementing make sure our team already has a strong foundation such as automation tests, fast build systems, synchronous code reviews and smaller user stories.
Make sure the branch trunk is always green, we can take advantage of automation tests and intensive code reviews. Problems will arise when the trunk branch is dirty because fixing the branch is quite painful. At first it took effort to make the transition, but as time went on the team should get used to it.
In the next article I plan to discuss more about Trunk-based development from release strategy, CI/CD setup to feature flags usage. If you find this article useful, don’t forget to share this article. Thank you.
