The blury line between Trunk-Based Development and Continuous Integration

July 18, 2022
If you practice TBD with days-long branches, is it still TBD? I don't know. But it's certainly not continuous integration.

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.

Share this

Related Content

Short-term alternatives to code freezes

Use a code freeze as a reminder that there are still quirks to be worked out, and make an effort to work them out.

New hires means more overhead

Lines of communication go up as team size increases, but that's not all. Consider merge conflicts.

A GitFlow story

A team I recently started working with has been using GitFlow. Until last week.