Compare trunk-based development to feature-based approaches
The repo-centric trunk-based development model can be a good fit for teams adept enough to maintain a codebase. But it means taking the road less traveled.
In an effort to get rapid, business-responsive software code to production, organizations must determine if trunk-based development fits their needs -- or if it's just a detrimental fad. But, to answer that question, enterprise IT must take a step back and evaluate its developers' workflows and capabilities.
Software developers tend to work on features, which they merge into the primary branch of the application repository to create releases. They rely on pull requests to synchronize changes with the rest of the team. The problem with this approach to building software is that it can lead to complete development disorder when feature requests grow and the number of independent branches and merge points increases accordingly. A project can easily grow from dozens of feature requests to hundreds. Developers lose control of the project, merge and integration activities cripple code releases, and the software's quality and stability degenerates.
The opposite approach defines specific releases and assigns teams to work on the features for said release. However, release-based approaches freeze development teams into long-term schedules that run contrary to continuous development and fail to track business priorities.
Trunk-based development presents an alternative. The trunk contains the main codebase for a project. Developers merge changes back into this main trunk daily, rather than work on features or bug fixes that merge into the trunk upon completion. This approach keeps the trunk up to date. Trunk-based development enables developers to create longer branches, where they constrain the scope of changes with toggles that control user visibility. Branches also spin off the trunk for individual releases, but these release branches are not likely to create major merge issues, as code typically integrates back to the trunk daily.
Many teams see trunk-based development as an attempt to trade agility and responsiveness to business needs for less work in change control. Detractors point out that these daily converges still require merges. They argue that this approach -- when daily trunk merges replace long-lived feature sprints -- ignores poor project management and feature definition.
Let's look at the individual parts involved in trunk-based programming.
Branches and repositories
Repository version control works differently with trunk-based development than continuous and other approaches, but you still need repositories. Developers must be able to pull code to create feature branches, which are called local branches.
Local branches represent feature development, and releases generate remote branches that assemble ready code and hotfixes. So, development teams can release at any time, and merges do not create incompatibility problems.
Trunk-based development is completely compatible with GitOps, wherein the IT team converges everything associated with a software code version -- configuration data, parameters for operation and more -- in the repository. The main trunk code is stabilized at least daily thanks to the merge, which makes it easier to maintain a single source of information than other forms of development.
Feature toggles
Critical to trunk-based development, toggling enables developers to make features and synchronize them with the main trunk, but keep them out of production until ready. The old and new code associated with a feature coexist in the live deployment, with new code toggled off -- kept hidden.
If a team uses a release schedule, it can group new feature releases into its itinerary. An integration testing process aligns feature developments with production trunk code and validates their functionality. Then, the features merge into the trunk.
Development workflow decisions
For most organizations, the right development workflow comes down to the expansiveness of the scope of features.
If a feature amounts to a modest change in code with fairly limited scope of impact, and if feature requests come at least weekly, feature-based development can enable the team to respond quickly to business needs. The limited scope of feature development minimizes merge problems. When feature priorities drive development, integration and release processes, teams can release quickly.
Trunk-based development shines when features have a lot of variable implementation complexity, or they are implemented as shared microservices for multiple applications. This approach is a major risk, however, if a development team lacks the process discipline to ensure trunk code is properly maintained and updated. A fault in trunk code threatens everything, and is too much of a price to pay to simplify code merges.
The final factor here is critical. The main thrust of development, including continuous and rapid development, has been a Git-based feature-stream model -- not trunk-based development. GitOps and other innovations evolved from that approach, and are now at the forefront of how tools and practices progress for development teams. Trunk-based development largely emerged from the experiences of social networks and applications with simpler features; enterprise apps typically have more heavy-duty features that incorporate databases, accounting, CRM and more.
If code merges are complicated or error-prone, fix your development management practices -- regardless of the workflow management approach.
The transition to a trunk-based approach takes some effort, as is the shift from trunk-based development to flow-, release- or feature-based methods. Determine your ideal choice at the outset to avoid a flip-flop later on.
