Trunk-Based Development Collapses at Scale

Trunk-based development has its share of religious adherents. They argue for its simplicity: developers merge small, frequent changes into a single main branch, also known as the "trunk." This model indeed works wonders for small, co-located teams with a high degree of trust.

In that context, frequent merges minimize long-lived branch conflicts and can support rapid CI/CD. However, as soon as you scale to hundreds or thousands of developers, multiple teams, and globally distributed offices, trunk-based workflows encounter severe limitations.

At the enterprise scale, TBD can strain coordination, testing, and governance processes. While TBD may suit small, agile teams, it is unsuitable for large-scale, distributed enterprise development, especially for complex systems such as ERP, banking, HCM, or payroll. In a massive organization, allowing everyone to freely commit directly to a single branch quickly becomes untenable.

When hundreds of developers merge continuously, the main branch is in a state of constant flux. Developers must constantly rebase or merge updates to avoid breaking builds. The promise of "merge hell" elimination, evangelized by TBD proponents, only holds if the teams are small. A large codebase with many interdependencies cannot be forced into neat feature toggles, as advocated by the TBD.

Even the AWS DevOps prescriptive guidance concedes that trunk-based development is well-suited to smaller teams. It lists notable drawbacks at scale, including limited isolation of work and increased code churn:

• Limited isolation – Because all developers work on the same branch, their changes are immediately visible to everyone on the team. This can lead to interference or conflicts, causing unintended side effects or breaking the build. In contrast, feature-based development isolates changes better so that developers can work more independently.

• Increased pressure on testing – Trunk-based development relies on continuous integration and automated testing to catch issues quickly. However, this approach can put a lot of pressure on the testing infrastructure and requires a well-maintained test suite. If the tests aren't comprehensive or reliable, it can lead to undetected issues in the main branch.

• Less control over releases – Trunk-based development aims to keep the code base in a continuously releasable state. While this can be advantageous, it might not always be suitable for projects with strict release schedules or those that require specific features to be released together. Feature-based development provides more control over when and how features are released.

• Code churn – With developers constantly integrating changes into the main branch, trunk-based development can lead to increased code churn. This can make it difficult for developers to keep track of the current state of the code base and might cause confusion when trying to understand the effect of recent changes.

• Requires a strong team culture – Trunk-based development demands a high level of discipline, communication, and collaboration among team members. This can be challenging to maintain, particularly in larger teams or when working with developers who are less experienced with this approach.

• Scalability challenges – As the size of the development team grows, the number of code changes being integrated into the main branch can increase rapidly. This can lead to more frequent build breaks and test failures, making it difficult to keep the code base in a releasable state.

A large codebase takes time to build and test. If dozens of commits per hour trigger a complete build, the CI pipeline becomes a bottleneck. The build may not be quick enough to meet the demand of rapid-fire commits, requiring developers to wait for hours, maybe even days. In the enterprise, suites of regression tests and QA can be far slower than the cadence assumed by TBD. Rolling back a broken mainline commit amid thousands of developers is also painful, as it propagates errors across many workspaces.

Trunk-based dev assumes a high-trust culture where any developer's commit is immediately safe. In large organizations, this is rarely true. Enterprises typically require code reviews, approvals, and gating. Simply merging to the trunk bypasses many of those controls. Enterprises typically rely on module owners or release managers to vouch for code quality. Without such gating, a single bad commit can destabilize the entire product and erode confidence in a global team.

Keeping the trunk constantly releasable often forces incomplete features behind toggles. While feature flags solve some problems, at the enterprise scale, they introduce their own set of issues. As Devid Herber notes:

As the system scales, the complexity of managing these flags grows exponentially. Over time, unused or forgotten flags can accumulate, leading to codebase clutter and potential technical debt. Managing an escalating number of feature flags without proper tools and strategies can become cumbersome, leading to an increased risk of errors.

As applications also grow in size and complexity, the sheer volume of feature flags can lead to difficulty tracking or managing each flag's lifecycle and ensuring that feature flags do not conflict with each other or existing system functionalities, which is critical to maintaining system stability and performance.

Performance degradation may also arise as the sheer number of feature flags can lead to increased load times and resource consumption. Hence, there is a need to regularly audit and clean up old or unused flags to prevent clutter and potential technical debt.

In the enterprise context, projects rely on staging or release branches for auditability, controller rollouts, and the isolation of hotfixes. Again, AWS guidance cited above notes that TBD workflows offer less control over releases and are not suitable where governance is key.

In contrast, classic GitFlow or release-branch models allow features to be batched and certified before cutover. Even if TBD is a purist ideal, branching strategies mirror what is more natural in practice.

In other words, at the enterprise scale, TBD amplifies coordination and trust issues. It requires an exceptionally high level of automation, discipline, and developer maturity -- conditions rarely found at scale in the enterprise across federated teams. Without these conditions in place, continuous mainline commits devolve into merge conflicts, unstable builds, buried release features, and feature flag clean-up hell.

The Linux Kernel Hierarchical Model

The Linux kernel, although open-source, serves as a good example of what a large, distributed project looks like, even in the enterprise. With over 4000 active contributors annually and hundreds of subsystems, Linux does not follow TBD. Instead, it uses a multi-tiered workflow:

• Developers send their patches to the subsystem maintainers. Each subsystem has maintainers who review, accept, and apply patches to that sub-tree. Maintainers, in other words, curate their domain. The chain of trust means each maintainer implicitly vouches for the quality of code they approve;

• Linux follows a rigid release cycle. After a stable release, Linus Torvalds opens a two-week "merge window" for the next version. During this period, all features are merged. After the window closes, the branch is frozen and tagged as a release, and only bug fixes flow until the final release. Effectively, the "trunk" acts as a temporary integration branch for a fixed interval, not an always-open mainline. Major feature work must be staged in sub-trees ahead of time, not dropped unpredictably into the main;

• Before even reaching the mainline, changes get tested in "Linux-next" trees. This multi-layer staging is essential for sanity when thousands of people contribute. By contrast, a pure trunk-based model skips these safeguards;

• When a maintainer accepts code, they become responsible for it. This high-trust bar is feasible in a self-governing OSS community but may not be easily reproducible in the private sector with rotating personnel.

Linux model, therefore, is almost the diametric opposite of TBD. It is a rolling release process built on hierarchical feature branches and gatekeeping. This shows that massive distributed development demands structure and clear ownership of domains. These mechanisms resolve scale issues that TBD simply cannot.

The Enterprise Business Software Model

There is industry evidence that large enterprises working on complex business software follow workflows more closely related to Linux than to TBD. Enterprise projects often have feature streams per region or product line, not a single mainline commit. These industries demand rigorous versioning and cutover procedures that pure TBD does not provide. Even the SAP community notes that TBD setups quickly collapse under real-life complexity.

I see how small fintech startups may embrace TBD at scale; they, too, will need to rely on long-lived branches for audit and risk control. Large financial institutions operate under strict compliance and risk policies. Their core banking and payment systems involve multiple release trains (e.g., nightly integration, quarterly releases, regulated fixes). For example, internal DevOps at a global bank might use a gated promotion model (Dev → Test → Prod branches) akin to classic release management rather than an open trunk.

Even companies shipping large packaged software often maintain separate branches for major versions and hotfixes. In these settings, feature branches per project or client are commonplace. A telling sign is that many large teams still describe GitFlow or other multi-branch models as their default. In short, branching allows teams to isolate significant changes (such as multi-month features in SAP or PeopleSoft) without impacting unrelated work – a luxury lost under a strict trunk-only policy.

In each case, the sheer number of modules, interdependencies, and stakeholders makes trunk-based commits impractical. Coordinating a successful build of an entire SAP suite or a bank's payment switch on every code change would grind the delivery pipeline to a halt. Instead, these enterprises rely on layered branches, integrations, and release managers – the very opposite of an all-open trunk.

Some Final Thoughts

In summary, TBD can be a marvelous tool for small, agile teams with simple codebases and high trust. In those contexts, fewer branches and rapid integration minimize overhead and speed delivery. However, enterprise-scale development is a fundamentally different beast. With hundreds of developers, globally dispersed teams, and mission-critical systems, TBD's assumptions break down.

A prudent CTO will recognize that one-size-fits-all DevOps slogans do not guarantee success. Trunk-based development is not a panacea, and pushing it at a massive scale without addressing trust, coordination, and test-infrastructure requirements can introduce more chaos than it cures. When an architecture spans continents and compliance zones, branching models that allow for compartmentalized work, backed by strong CI/CD pipelines and transparent processes, are usually more sustainable. In short, embrace trunk-based commits with care: they work wonders for close-knit teams, but they introduce serious scalability challenges for large, complex enterprises.

In my practice, I advocate for TBD at an early stage of the project with a small team. Once the MVP reaches production and requires a stricter release cycle, I adopt release branching.

In the release branching model, work occurs on feature branches. When a release is imminent, a new release branch is cut. Only bug fixes are included in the release branch. Future releases require separate branches and have a formal hotfix flow. Release branches can be deployed to environments incrementally to production, whereas TBD teams must use complex feature flags for staged rollouts. Auto-merge tools ensure that bug fixes applied to release branches are reflected in subsequent releases and the main integration branch.

In my experience, the velocity of TBD projects versus release-branched ones converge as the project size and team grow. Where TBD slows down due to friction in communication and coordination, the release branching model becomes more effective.