Yesterday I wrote about trunk-based development, and got some good responses. One I found particularly thought-provoking, as it touches on the related topic of continuous integration:

I think in both styles of trunk-based development, it is required to merge all work done at least daily to main.

I can see the logic here. After all, the defining charactaristic of TBD is that there is only a single long-lived branch. And if your branches last days or weeks, that seems like a violation.

But to play devil’s advocate, what if you’re merging directly to master, but have weeks worth of work in your working copy? That’s pretty bad. But is it bad because it’s “not trunk-based development?” Maybe.

I don’t really know. I can appreciate both arguments. I think at the end of the day, there’s a blury line, not a sharp one, between trunk-based development and continuous integration. They certainly work well together. And while it’s widely agreed that you cannot do continuous-integration without trunk-based development, there’s more room for nuance when it comes to the question of whether you can do TBD without CI.

But here’s what I do know about the differences between TBD and CI:

Very few teams can successfully learn adopt both practices at the same time. So when I’m coaching teams, I start with TBD, even if they start by using days- or weeks-long branches. I still call this Trunk-Based Development, so long as they no longer have devel or staging or uat branches, for the simple reason that I need to call it something. Once I have the team comfortable with this (which usually takes a few weeks to a couple months), then I start working hard on smaller and more frequent branches, with the goal of multiple integrations per day per developer. I call this continuous integration.