Trunk-based development (TBD) is software development strategy where engineers merge smaller changes more frequently into the main codebase and work off the trunk copy rather than work on long-lived feature branches. This development model is often leveraged as part of a continuous integration development workflow.
With many engineers working in the same code-base, it's important to have a strategy for source-control and how individuals work together. To avoid overriding each other's changes, engineers create their own copy of the codebase, called branches. Following an analogy of a tree, the master copy is sometimes called the mainline or the trunk. The process of incorporating the changes of an individual's copy into the main master trunk is called merging.
To understand how trunk-based development, it's useful to first look at the alternative strategy, feature branch development.
In feature branch development, individual software developers or teams of engineers do not merge their new branch until a feature is complete, sometimes working for weeks or months at a time on a separate copy.
This long stretch of time can make the process of merging difficult because the trunk or master branch has likely changed due to other engineers merging their code changes and version control gets difficult. This feature branching can result in a lengthy code review process when looking to create a release branch to be deployed. Often resulting in many different pull requests having to be analyzed to resolve merge conflicts.
Trunk-based development takes a more continuous delivery approach to software development, and branches are short-lived and merged as frequently as possible. The branches are smaller because they often contain only a part of a feature. These short-lived development branches make the process of merging easier because there is less time for divergence between the main trunk and the branch copies.
Thus, trunk-based development is a methodology for releasing new features and small changes quickly while helping to avoid length bug fixes and "merge hell". It is a growing popular devops practice among agile development teams, and is often paired with feature flags or feature toggles to ensure that any new features can be rolled back quickly and easily if any bugs are discovered.
The practice of feature flagging (pioneered by Martin Fowler), or wrapping new features in code which can be remotely toggled on and off, is one common development process that software engineers employ to help to implement trunk-based development while reducing the risk of introducing bugs into the code.
Because trunk-based development involves working in a single branch in the production environment, feature flags provide a way to introduce new features and changes into the code in a controlled fashion, and quickly allows them to be turned off if any bugs are discovered.
Feature flags can also be used to roll out features slowly, to a small portion of a project's user base rather than having one big launch, which helps limit the blast radius of any potentially buggy source code.
Optimizely is the world's leading platform for Progressive Delivery and Experimentation. Optimizely Full Stack offers a full range of developer tools such as feature flags, feature rollouts, feature variables, and a/b testing that enable trunk-based development and launching new code quickly, while minimizing the risk.
And for developers looking to get started with just feature flags, Optimizely Rollouts offers unlimited feature flagging capability in a dozen of the most popular languages and libraries out there. Get started with trunk-based development today and accelerate your product development with Optimizely!