5 ms·

What exactly is a drawback of Trunk-based development for developers?

convolvatron 4y ago
not allowed to integrate with other people's work in progress without a trip through main. also dont know how you are supposed to put out maintenance releases.
- atrandom 4y ago
  Branch from a tag, make or cherry pick the fix, tag, deploy.
- fallbackboy 4y ago
  I don't think it's a great idea to integrate with other work in progress, living on another feature branch. As far as maintenance releases go, strategies for resolving this are well documented here https://trunkbaseddevelopment.com/branch-for-release/#fix-production-bugs-on-trunk https://trunkbaseddevelopment.com/branch-for-release/#fix-pr....
- stetrain 4y ago
  You can follow the core of trunk based and still work together with another person on a shared feature branch if that is needed. I have found benefits though to structuring your WIP in a way that it can be merged into the trunk with minimal risk of breaking existing stuff. This is a mindset change around favoring adding new modules / components / endpoints without clobbering working code, especially for larger projects where the code is going to come in over the course of many releases. Maintenance releases are done by going back to the tag or branch for your current prod release, making a new release branch from it, and pulling in whichever commits are needed.
jdlshore 4y ago
For that matter, what is the benefit of TBD for managers? It’s a development technique—specifically, a rebranding of continuous integration, because that name was coopted by tool vendors.
- osigurdson 4y ago
  I think it is good for book sellers and conference speakers. Particularly the Uncle Bob types that love simple and dogmatic ideas.
ironmagma 4y ago
Proliferation of feature flags, especially old ones, leads to combinatorial explosion of behaviors.
- sverhagen 4y ago
  Does it help to add removal of feature flags to the definition of done of your epics? Then isn't it much the same as staying on top of any kind of tech debt?
  - ironmagma 4y ago
    It is much the same, which is to say, doesn't get done.
    - MiyamotoAkira 4y ago
      So the problem is not the feature flags. If the code/system doesn't get improved bit by bit (is ok to have technical debt), then, whatever the technique, you are going to end in a bad place.
      - ironmagma 4y ago
        Except that most technical debt does not suffer from combinatorial explosion. Feature flags do.
        sverhagen 4y ago
        Isn't it only combinatorial explosion if you need to maintain and test all those permutations. But those feature flags have a default value that they get stuck at. So the real remaining problem is pretty much: dead code. Which, again, that's "just" a common type of technical debt. But hey, I am not arguing for feature flags. No, Sir, please no.
        Klaster_1 4y ago
osigurdson 4y ago
Trunk based development, while fashionable today does have some theoretical downsides. Imagine a feature toggled code base in the limit - no actual functionality, just partially baked features behind toggles. The end result is a series of branches manifested in the code itself - with no actual "mainline" as nothing has ever been completed. I'm pretty sure that would not be awesome. Of course, a branched code base in the limit is similarly never merged which obviously is terrible as well. My main point is don't follow trends, instead simply do what what makes sense - that might mean feature toggles, branches or some combination. Stay awake, be creative and avoid dogmatism: sometimes things are better out than in, other times better in than out.
- civilized 4y ago
  A single code base with half-baked code under feature toggles seems different from "a series of branches manifested in the code itself". Branches would mean there can be different versions of the same half-baked feature that need to be reconciled. Are you saying that people in this thought experiment would go so crazy with feature toggles that they'd develop several different versions of the same feature, each with different toggles?
  - osigurdson 4y ago
    This hypothetical is fairly broad but it is certainly possible to have a branch per feature (i.e. a feature branch).
    - civilized 4y ago
      Yes it's possible for feature branches to look a bit like feature flagged code, but other than that, the administrative and organizational implications seem very different. The most obvious being, it's a lot easier to see everything when it's in one place.
      - osigurdson 4y ago
        The hypothetical is the code is half baked, never completed and obsolete. In TBD, work is required to remove it. If using a branch, nothing needs to be done.
dgb23 4y ago
I think it’s quite a reasonable method. But there’s no one size fits all. Advocates of methodology will often speak in absolute terms. Plus their way of doing thinks is sometimes presented as a big magical revelation. This article is actually not like that, it reads like a historical summary. It’s of course good to sometimes think about other ways of doing things. But in the end the way you’re using version control should reflect your requirements and development practice and not the other way around. We do 1 main branch plus tagging. That’s it. It’s simpler for us and it’s a motivator to write code that works _now_. But if we ended up in feature flag hell we would probably reconsider or simply branch off. Just be pragmatic about it. There are of course companies with predefined rules about these things. I can’t speak to that.
drewcoo 4y ago
If you have . . . - a merge process that happens on CI - and that takes some time, running checks on the merge branch with main merged into it to effectively test what main will be - and you want to make sure that there's no contention, so you finish one merge before testing the next then you effectively have a merge lock in CI. And that can lead to merge convoys where lots of merges to main line up and take a long time.

not allowed to integrate with other people's work in progress without a trip through main. also dont know how you are supposed to put out maintenance releases.

atrandom 4y ago
Branch from a tag, make or cherry pick the fix, tag, deploy.
fallbackboy 4y ago
I don't think it's a great idea to integrate with other work in progress, living on another feature branch. As far as maintenance releases go, strategies for resolving this are well documented here https://trunkbaseddevelopment.com/branch-for-release/#fix-production-bugs-on-trunk https://trunkbaseddevelopment.com/branch-for-release/#fix-pr....
stetrain 4y ago
You can follow the core of trunk based and still work together with another person on a shared feature branch if that is needed. I have found benefits though to structuring your WIP in a way that it can be merged into the trunk with minimal risk of breaking existing stuff. This is a mindset change around favoring adding new modules / components / endpoints without clobbering working code, especially for larger projects where the code is going to come in over the course of many releases. Maintenance releases are done by going back to the tag or branch for your current prod release, making a new release branch from it, and pulling in whichever commits are needed.

jdlshore 4y ago

For that matter, what is the benefit of TBD for managers? It’s a development technique—specifically, a rebranding of continuous integration, because that name was coopted by tool vendors.

osigurdson 4y ago
I think it is good for book sellers and conference speakers. Particularly the Uncle Bob types that love simple and dogmatic ideas.

ironmagma 4y ago

Proliferation of feature flags, especially old ones, leads to combinatorial explosion of behaviors.

sverhagen 4y ago
Does it help to add removal of feature flags to the definition of done of your epics? Then isn't it much the same as staying on top of any kind of tech debt?
- ironmagma 4y ago
  It is much the same, which is to say, doesn't get done.
  - MiyamotoAkira 4y ago
    So the problem is not the feature flags. If the code/system doesn't get improved bit by bit (is ok to have technical debt), then, whatever the technique, you are going to end in a bad place.
    - ironmagma 4y ago
      Except that most technical debt does not suffer from combinatorial explosion. Feature flags do.
      - sverhagen 4y ago
        Isn't it only combinatorial explosion if you need to maintain and test all those permutations. But those feature flags have a default value that they get stuck at. So the real remaining problem is pretty much: dead code. Which, again, that's "just" a common type of technical debt. But hey, I am not arguing for feature flags. No, Sir, please no.
        Klaster_1 4y ago

osigurdson 4y ago

Trunk based development, while fashionable today does have some theoretical downsides. Imagine a feature toggled code base in the limit - no actual functionality, just partially baked features behind toggles. The end result is a series of branches manifested in the code itself - with no actual "mainline" as nothing has ever been completed. I'm pretty sure that would not be awesome. Of course, a branched code base in the limit is similarly never merged which obviously is terrible as well. My main point is don't follow trends, instead simply do what what makes sense - that might mean feature toggles, branches or some combination. Stay awake, be creative and avoid dogmatism: sometimes things are better out than in, other times better in than out.

civilized 4y ago
A single code base with half-baked code under feature toggles seems different from "a series of branches manifested in the code itself". Branches would mean there can be different versions of the same half-baked feature that need to be reconciled. Are you saying that people in this thought experiment would go so crazy with feature toggles that they'd develop several different versions of the same feature, each with different toggles?
- osigurdson 4y ago
  This hypothetical is fairly broad but it is certainly possible to have a branch per feature (i.e. a feature branch).
  - civilized 4y ago
    Yes it's possible for feature branches to look a bit like feature flagged code, but other than that, the administrative and organizational implications seem very different. The most obvious being, it's a lot easier to see everything when it's in one place.
    - osigurdson 4y ago
      The hypothetical is the code is half baked, never completed and obsolete. In TBD, work is required to remove it. If using a branch, nothing needs to be done.

dgb23 4y ago

I think it’s quite a reasonable method. But there’s no one size fits all. Advocates of methodology will often speak in absolute terms. Plus their way of doing thinks is sometimes presented as a big magical revelation. This article is actually not like that, it reads like a historical summary. It’s of course good to sometimes think about other ways of doing things. But in the end the way you’re using version control should reflect your requirements and development practice and not the other way around. We do 1 main branch plus tagging. That’s it. It’s simpler for us and it’s a motivator to write code that works _now_. But if we ended up in feature flag hell we would probably reconsider or simply branch off. Just be pragmatic about it. There are of course companies with predefined rules about these things. I can’t speak to that.

drewcoo 4y ago

If you have . . . - a merge process that happens on CI - and that takes some time, running checks on the merge branch with main merged into it to effectively test what main will be - and you want to make sure that there's no contention, so you finish one merge before testing the next then you effectively have a merge lock in CI. And that can lead to merge convoys where lots of merges to main line up and take a long time.