TUBA (Trunk-Based Batch Release Flow) is a software version control workflow designed for teams that want the benefits of continuous integration along with quality-controlled, coordinated releases. TUBA blends the simplicity of Trunk-Based Development with the stability of release management, allowing multiple feature branches to be tested and reviewed independently. These features and fixes are then bundled into short-lived integration branches, enabling reliable, low-risk releases without sacrificing development speed or collaboration.
Key Principles
- Develop from main: All work starts from the
mainbranch, ensuring up-to-date base commits. - Batch via 'next-release': Features and fixes are merged into a short-lived release integration branch (e.g., nr/v5.0.1).
- Test as a bundle: All CI, QA, and UAT happens in the release branch, not on main.
- Single release event: Once verified, the release branch is merged back to main in one commit.
- Clean as you go: The release branch is deleted after the merge to keep history clean.
Develop from main
Trunk-Based Development is a Git workflow where developers work in small, short-lived branches that are frequently merged into a single main branch (the "trunk") (Hamman, 2020). This promotes continuous integration, fast feedback, and smoother collaboration by ensuring that every change starts from the latest production-ready codebase.
According to Potvin and Levenberg (2016), this approach is a core principle at Google, where it has proven effective in eliminating the "painful merges" caused by outdated branches. With everyone building on a consistent foundation, changes become immediately visible and usable by all, supporting a unified and continuously integrated codebase.
Batch via 'next-release'
Batching changes like features and fixes via a short-lived next-release branch (e.g., nr/v5.0.1) enables teams to coordinate small sets of fixes and features into a single, well-defined release. This branch acts as a temporary integration point, allowing for focused QA, UAT, and staging without disrupting the stability of main.
The batch size and release cadence is planned by the team. Ideally, the target is a release every 2–3 days in order to maintain a close alignment with trunk-based development.
Test as a bundle
By testing and validating a small group of changes together, teams can reduce deployment friction while preserving rapid iteration. This permit a balance between continuous integration and coordinated delivery, keeping releases fast, traceable, and reliable.
While not always referred to by the exact terms "batch testing" or "batch release", the practice of bundling and validating a group of changes is a widely discussed concept in release management and continuous delivery literature. For example, Google's "Site Reliability Engineering" book discusses release processes that involve bundling changes (Niall Richard Murphy et al., 2016). Reinertsen (2009) heavily emphasizes the economic benefits of working in small batches, which inherently requires testing those batches.
Single release event
The concept of a "single release event", once a dedicated release branch is verified, is common in well-established software development and release methodologies, like Trunk-Based Development with release branches or Continuous Delivery/DevOps.
After successfully passing all validation checks, the release branch is merged back into the main branch in one atomic commit. This single action simultaneously updates the release number and creates a corresponding tag.
This approach ensures a clean and streamlined history and consistency. Moreover, it significantly simplifies the tracking of all integrated changes clarifying what went into each official release. Beyond a tidy commit history, this strategy offers improved auditability of everything that went into that specific release and, where allowed, easier rollbacks.
Clean as you go
Deleting the release branch after merging helps keep the repository tidy and easier to navigate. It prevents clutter from accumulating over time with outdated branches reducing confusion about which branches are active or needed. Moreover, it also reinforces the idea that each release is self-contained and finalized.
From a human perspective
Beyond the technical advantages, TUBA also supports team morale and satisfaction. When changes are shipped in small regular batches, contributors see their work reach production quickly. This creates a tangible sense of progress and achievement. Developers are more motivated when they can connect their daily tasks to real outcomes, rather than waiting weeks (or months) for their code to be released (Kim, Behr and Spafford, 2013). This fast feedback loop fosters a sense of ownership, encourages accountability, and reduces the frustration often associated with long release cycles (Farley, 2020). The regular rhythm of batch releases gives teams clear goals to work toward, strengthening collaboration and reinforcing the value of incremental, high-quality contributions (Humble and Farley, 2011).
Novel but not new
TUBA may sound like a novel version control strategy, and in name, it is. However, the principles behind it are far from new. In fact, long before Git became popular, Subversion users learned the hard way how difficult manual merging could be, especially before merge tracking was introduced in SVN version 1.5. As a result, most teams, including those I have worked with, committed directly to /trunk or used very short-lived branches (C. Michael Pilato, Collins-Sussman, and Fitzpatrick, 2008). It may be possible that this long-standing habit implicitly endorsed what we now call trunk-based workflows.
Nowadays, DevOps guides still preach the same trunk discipline born from Subversion-era pain. In other words, today's recommendations merely re-articulate the branch-avoidance lessons developers learned years ago from SVN developers.
Therefore, while the principles are not new, TUBA offers a clear name for this increasingly popular hybrid approach, and its potential as a recognized model is significant because:
- The acronym is simple and the musical metaphor subtly reinforces the idea of coordination and harmony across parts
- It laid out clear, actionable rules and a visual release structure
- It sits between the extremes of pure TBD (merge-to-main always) and Gitflow (heavy, long-lived branches).
- It works for open-source communities, startups, and large-scale engineering orgs.
Conclusion
TUBA offers a practical and disciplined software version control workflow tailored for teams that value both speed and stability. By combining the fast feedback and simplicity of trunk-based development with structured release batching, TUBA enables continuous integration without sacrificing coordinated delivery. Its core principles, developing from main, batching testing as a bundle through short-lived release branches, performing single release events, and cleaning up after release, promote clarity, traceability, and operational efficiency. As a result, teams can ship software more frequently, with higher confidence and reduced friction, aligning well with modern DevOps and continuous delivery practices.
References
C. Michael Pilato, Collins-Sussman, B. and Fitzpatrick, B.W. (2008) Version Control with Subversion. ‘O’Reilly Media, Inc.’ Available at: https://svnbook.red-bean.com/ (Accessed: 24 June 2025).
Farley, D. (2020) The Impact of Continuous Delivery | Dave Farley’s Weblog, Davefarley.net. Available at: https://www.davefarley.net/?p=314 (Accessed: 24 June 2025).
Humble, J. and Farley, D. (2011) Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Upper Saddle River, Nj: Addison-Wesley.
Hamman, P. (2020) Trunk Based Development, trunkbaseddevelopment.com. Available at: https://trunkbaseddevelopment.com/ (Accessed: 24 June 2025).
Kim, G., Behr, K. and Spafford, G. (2013) The Phoenix project: A novel about IT; devops; and helping your business win. S.L.: It Revolution Press.
Niall Richard Murphy et al. (2016) Site Reliability Engineering - Release Engineering. 'O'Reilly Media, Inc.' Available at: https://sre.google/sre-book/release-engineering/ (Accessed: 24 June 2025).
Potvin, R. and Levenberg, J. (2016) 'Why Google stores billions of lines of code in a single repository', Communications of the ACM, 59(7), pp. 78–87. Available at: https://doi.org/10.1145/2854146.
Reinertsen, D.G. (2009) The principles of product development flow : second generation lean product development. Redondo Beach, Calif.: Celeritas.