3 ms·

We currently use short-lived feature branches, merged via Pull Requests (+ review / automated testing) into the main development line. This way, we can communic

by cygned 10y ago

We currently use short-lived feature branches, merged via Pull Requests (+ review / automated testing) into the main development line. This way, we can communicate changes in a detailed manner before they are added to the product and make sure there is no unfished or bad code in the main branch. (The dev team is small, 5-8 devs). I don't see (yet?), what benefits TBD would provide in such a setup.

einrealist 10y ago
With TBD you can reduce the overhead of coordination between committers. Edit for clarification: "Branching in code", á la Feature Toggles is much better, because everything around it can be automated. With CVS branches, you shift that process into an earlier development stage where you need more human collaboration. So TBD can shift the focus of collaboration to things that matter more: the code.
- icebraining 10y ago
  Why can't you automatically merge all the branches for testing? Sure, sometimes it won't cleanly merge, but then again, features behind toggles won't always work well together.
  - qwer 10y ago
    I once wished this were possible too, but in reality it isn't. With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release. Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-picking branches to merge really is much much worse.
    - icebraining 10y ago
      And with n feature flags, aren't there also n! permutations to test, that is, each combination of enabled/disabled? If you say no, because you just test features as they get manually enabled, why can't you do the same by manually selecting branches to be merged?
      - einrealist 10y ago
        Yes, that complexity does not go away. But you only need one delivery pipeline, with one test/staging environment. Toggling and running acceptance tests against the variations can be automated, but is viable when done manually.
      - susam 10y ago
        With n feature flags, there are 2^n possibilities to test.
- cygned 10y ago
  I am very concerned that feature toggles add unnecessary complexity to the code. With Lisp Macros, for example, that would actually be quite elegant but in a language like JavaScript, we'd end up with a bunch of if'a here and there, wouldn't we? One might simplify it a bit with a different architecture, though.
  - sydd 10y ago
    Long lived branches add complexity too, it's just hidden in GIT. The main issue with feature branches are merge conflicts: they are the most evil operation one can imagine. First you have your code, that you understand. Then you have others code that you have no idea what it does, so first you need to understand it. This might take hours when done properly. Usually people skim over this part BC it's boring. This leads to superficial merges that leads to very very evil and hard to find bugs. And these bugs are super hard to find in git logs, since the merge commit is 2 or more people's code. Whereas the alternative, feature toggles are much better: first you don't need one for every small thing, add them to bigger features that take weeks to implement. With a team of ~10 developers you should not need more than 2 at one time (if you have more the management is at fault). Then feature toggles enforce modularity: by principle you should use them in as few places as possible, this will make the interface between the new feature and your current app as small as possible. This is a good thing!
nickthemagicman 10y ago
I like this best. It enables you to build your feature and then squash the commits into one idempotent feature commit which keeps commit clutter out of the git logs. Just keeping your branch rebased daily, one will have minimal problems even on big teams. I personally love developing on my own branch and having the freedom to experiment without messing stuff up.
glenjamin 10y ago
The linked website includes this workflow under their definition of trunk-based-development. As long as your branches are short-lived and make it into the main line rapidly, it appears to be considered equivalent. I've seen some commentators say that this doesn't pass their bar for TBD, but I think it's effectively the same thing. The site does call out "GitHub flow" as being slightly different, but that's because GitHub's description of their model includes deploying the branch to production before merging to master.
- paul_h 10y ago
  Couldn't have said it better myself :)

by cygned 10y ago

einrealist 10y ago

With TBD you can reduce the overhead of coordination between committers. Edit for clarification: "Branching in code", á la Feature Toggles is much better, because everything around it can be automated. With CVS branches, you shift that process into an earlier development stage where you need more human collaboration. So TBD can shift the focus of collaboration to things that matter more: the code.

icebraining 10y ago
Why can't you automatically merge all the branches for testing? Sure, sometimes it won't cleanly merge, but then again, features behind toggles won't always work well together.
- qwer 10y ago
  I once wished this were possible too, but in reality it isn't. With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release. Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-picking branches to merge really is much much worse.
  - icebraining 10y ago
    And with n feature flags, aren't there also n! permutations to test, that is, each combination of enabled/disabled? If you say no, because you just test features as they get manually enabled, why can't you do the same by manually selecting branches to be merged?
    - einrealist 10y ago
      Yes, that complexity does not go away. But you only need one delivery pipeline, with one test/staging environment. Toggling and running acceptance tests against the variations can be automated, but is viable when done manually.
    - susam 10y ago
      With n feature flags, there are 2^n possibilities to test.
cygned 10y ago
I am very concerned that feature toggles add unnecessary complexity to the code. With Lisp Macros, for example, that would actually be quite elegant but in a language like JavaScript, we'd end up with a bunch of if'a here and there, wouldn't we? One might simplify it a bit with a different architecture, though.
- sydd 10y ago
  Long lived branches add complexity too, it's just hidden in GIT. The main issue with feature branches are merge conflicts: they are the most evil operation one can imagine. First you have your code, that you understand. Then you have others code that you have no idea what it does, so first you need to understand it. This might take hours when done properly. Usually people skim over this part BC it's boring. This leads to superficial merges that leads to very very evil and hard to find bugs. And these bugs are super hard to find in git logs, since the merge commit is 2 or more people's code. Whereas the alternative, feature toggles are much better: first you don't need one for every small thing, add them to bigger features that take weeks to implement. With a team of ~10 developers you should not need more than 2 at one time (if you have more the management is at fault). Then feature toggles enforce modularity: by principle you should use them in as few places as possible, this will make the interface between the new feature and your current app as small as possible. This is a good thing!

nickthemagicman 10y ago

I like this best. It enables you to build your feature and then squash the commits into one idempotent feature commit which keeps commit clutter out of the git logs. Just keeping your branch rebased daily, one will have minimal problems even on big teams. I personally love developing on my own branch and having the freedom to experiment without messing stuff up.

glenjamin 10y ago

The linked website includes this workflow under their definition of trunk-based-development. As long as your branches are short-lived and make it into the main line rapidly, it appears to be considered equivalent. I've seen some commentators say that this doesn't pass their bar for TBD, but I think it's effectively the same thing. The site does call out "GitHub flow" as being slightly different, but that's because GitHub's description of their model includes deploying the branch to production before merging to master.

paul_h 10y ago
Couldn't have said it better myself :)