to be honest: We are adopting a comparable approach by emphasizing the “clean as you code” methodology from SonarCloud. As is often the case in live scenarios, situations are seldom entirely black or white.

I believe that refraining from integrating your code (whether it’s from the trunk or to the trunk) for an entire month is precisely what leads to the drawbacks of feature-branch development. Even if you’re tackling a substantial piece of work, it’s logical to ensure that it continues to incorporate changes from other developers. There must be a way to break down this work into smaller increments, even if they don’t immediately “add value” to the user, and commit them back to the trunk. Having code isolated for such an extended period appears to be a potential recipe for disaster.

Absolutely! You’re witnessing modifications made by other developers practically in real-time. This ensures that not only are you staying current with the codebase, but the entire team is essentially engaged in continuous code review.

Trunk-based development excels with smaller tasks (and the majority of our tasks tend to be on the smaller side). It’s like saying, “You have four hours for this feature, go ahead and push it.”

However, as tasks grow larger (in the context of a cohesive unit of work, spanning perhaps a month or two), that’s when branch-based development starts to become a more sensible choice.

Consider this: if we’ve truly achieved continuous integration, does it fundamentally matter if we consolidate a few commits and merge them into the master through a pull request?

In my experience with a FinTech project, our deployment frequency averaged once a week because we lacked genuine continuous integration. We had insufficient confidence in our test suite, no established methods to validate potential production issues, lacked metrics, feature switches, and faced limited enthusiasm to hit the deploy button.

Upon significantly enhancing our continuous integration practices, the fear of deployment diminished. This alone led to a substantial increase in both deployment and merging frequencies. Initially, mandatory reviews for every new change were in place, hindering the encouragement of small changes. Recognizing this, I made reviews optional, focusing on them only for risky changes or when requested by the PR owner.

Post the continuous integration improvement, we experienced a significant boost, achieving several merges and deployments per day with reduced defects. Having the entire change consolidated in one place, such as a pull request, also streamlined the review process for me.

Our team, which consists of about 15 engineers, has been using TBD extensively for several years. It seems to strike an optimal balance between maintaining active repositories and ensuring a controlled development flow. More details on this approach can be found at https://trunkbaseddevelopment.com/#scaled-trunk-based-development.

I’m curious to hear your thoughts on this style of development and whether, in your experience, TBD has evolved beyond its original definition.