What is trunk-based development?
Trunk-based development (TBD) is a git branching strategy where developers collaborate in a single branch called ‘trunk’ and make smaller changes more frequently. In this case, developers rarely branch and should they do, the branches are usually short-lived, typically lasting no more than a few hours.
Thus, the underlying idea behind this strategy is to limit long-lasting branches and as a result avoid what is referred to as ‘merge hell’. Instead, the process of trunk-based development revolves around the concept that features should always be in a state ready for release.
How is this done exactly? Put simply, each developer splits the work they do in smaller batches and merges into the trunk or mainline so they commit directly into the trunk without the use of branches. This means that there is only one branch where developers directly commit known as the trunk.
Trunk-based development and CI/CD
Trunk-based development is required for and a key enabler of continuous integration and continuous delivery. Because developers are making changes multiple times a day to the trunk and any branches are merged as frequently as possible, they are adhering to the practice of continuous integration. This makes the process of releasing new features quicker, hence making continuous delivery possible.
So, in this sense, trunk-based development creates the environment necessary for continuous integration as commits occur multiple times a day. In other words, it creates the conditions necessary for continuous integration.
The two concepts are so intertwined that sometimes one can be used in lieu of another as they both adhere to the same idea of continuously integrating to the trunk. Or alternatively, you need trunk-based development to implement continuous integration.
When to implement trunk-based development?
Trunk-based development usually works best when you have a team of experienced, senior developers as this kind of workflow gives them the autonomy they need to get the job done.
However, it’s less recommended when you have a team of junior developers whose work you need to monitor closely. It is also not highly recommended if you are running an open source project where you might need stricter control over any changes made since in this kind of project anyone can contribute.
Product maturity is another factor to consider in the decision to use trunk-based development. If the product is just starting out, the priority is usually to get it up and running in no time. Meanwhile, for a more mature product, you might want to monitor any changes closely, lest you lose a great amount of money depending on how much your well-established product is worth. In this case, you might want to consider feature branching.
Trunk-based development is often combined with feature flags - or feature toggles, so any new features can be deployed as soon as they are ready and rolled back easily in case of bugs.
Benefits of trunk-based development
Escape from merge hell
Unlike feature branching, branches in trunk-based development are short-lived, lasting no more than a few hours. This eliminates the risky task of merging long-lived branches that have split from the trunk leading to less conflicts or what we referred to earlier as ‘merge hell’. This leads us to the second advantage of TBD.
Less merge conflicts
By implementing continuous integration, developers push their changes to the shared branch at least once a day, so the likelihood of merge conflicts is significantly reduced.
This is because developers are not waiting for long periods of time to integrate their changes making it easier to resolve any conflicts that may arise. Any bugs become easier to spot and likely to be fixed quicker ensuring a smooth integration into the mainline.
Additionally, as usually there are no branches so developers push code directly into the trunk thereby discarding the need and hassle of merging long-lived branches.
Quicker feedback
Continuously integrating changes to the trunk allows for continuous improvements to be made to features as developers are able to validate their changes with that of their colleagues.
This is unlike feature branching where each developer works independently within a branch and any changes made within that branch would only be seen after merging into the main branch, which may take days or even weeks.
Consequently, trunk-based development offers greater visibility allowing developers to ensure that their changes are aligned and work seamlessly with other recent commits.
Quick releases
Quicker feedback naturally leads to quick releases. Committing changes to the trunk on a regular basis leads to more efficient release management and more frequent deployments. With a continuous stream of work being integrated into the trunk and continuous small changes to the feature being released bring a more stable release. This release would then be ready for deployment at any given moment in time.
In a fast-paced environment, rolling out constant updates and upgrades to features is a given. Trunk-based development is indispensable to get these releases out faster and not just any release but a high-quality release with significantly less bugs. Therefore, new features reach the end-user much faster. Basically, use trunk-based development when time is of the essence.
Use with caution
Trunk-based development is not without its weaknesses. When you have developers constantly adding changes to trunk, you end up in a constant state of churn. It is important to ensure that developers are regularly pulling from the trunk so that they don’t end up tripping over one another while adding new commits.
As mentioned earlier, there are also instances where implementing trunk-based development is not prudent. In this case, developers should consider other development methods such as feature branching.
Keep reading: how trunk-based development stacks up against other Git branching strategies
To sum it up
In the end, the benefits of this technique far outweigh its weaknesses. Choosing the right method for managing source code depends on what is right for your team. However, if you’re looking to deliver high quality releases to your customers while promoting efficient collaboration between developers then the simple strategy is to implement this practice within your business.
