5 ms·

This is content marketing for a feature flagging tool called “Bucket.” I’m a big fan of trunk-based development, although I prefer its original name: continuous

This is content marketing for a feature flagging tool called “Bucket.” I’m a big fan of trunk-based development, although I prefer its original name: continuous integration. (Sadly, that name has been coopted by tool vendors.) A better alternative to feature flags is keystone interfaces. It’s very simple: build your new feature without wiring it up to the UI (or API). Test it using automated tests that bypass the UI. When it’s ready, wire it up, manually confirm that the automated tests didn’t miss anything, and release.

0xbadcafebee 2y ago
Not that it makes a ton of difference, but technically trunk-based development refers more to the branching model, while continuous integration is a larger concept combining specific tooling, methods, branching, etc. You can do continuous integration with other branching models[1]. Unless a team tries hard to stick to strict CI, they usually end up with long-lived feature branches, long integration cycles, and clumsy, irregular deployments to irregular environments. So many teams still don't "get" CI, and end up wasting a shitload of time. [1] https://www.martinfowler.com/articles/continuousIntegration.html#StylesOfIntegration https://www.martinfowler.com/articles/continuousIntegration....
- jdlshore 2y ago
  The article you referenced specifically says that “trunk-based development” is a synonym for “continuous integration.” Please see the section titled “What is the difference between continuous integration and trunk-based development?”
  - kspacewalk2 2y ago
    That's a nice bit of history, but that is no longer common usage. Terminology has a life of its own, it isn't owned by those who first use it.
  - 0xbadcafebee 2y ago
    Martin's only saying that because the idea of CI came first, and he "doesn't want to rudely erase the work of Kent Beck". Trunk-based development has the branching model in the name. CI doesn't; it refers to a method to integrate code, and a whole lot of practices, tools, etc. In practice, most people don't even use the trunk model for their CI. Most people use feature branches and PRs. They still use everything else from CI, except for the single-branch. What should we call that, then? Not-quite-CI CI? It's simpler to refer to the general idea as "CI", even if it doesn't use a single branch. If you want to refer to the strict single-branch method, "trunk-based development" makes it clear.
    - steveklabnik 2y ago
      GitHub does have a setting in their branch rulesets to enforce linear history, it's kinda nice. But I agree with you that most people don't use it.
tharkun__ 2y ago
Never mind the content marketing of the "article". Use whatever tool you want to. If all you have is `if env==dev|staging`, that's enough, no need for "Bucket" or whatever. In general terms though: If you build your feature without wiring it up to the UI it means that you never integrate until the last moment. That way, you can't actually test a user interaction in an actually integrated fashion. This is really bad, because you will find all the integration problems at the very last moment. Basically when you're about to give it to your customers. Feature flagging combats that. It allows you to test the entire solution from the point of an actual customer, without exposing it to an actual customer.

0xbadcafebee 2y ago

Not that it makes a ton of difference, but technically trunk-based development refers more to the branching model, while continuous integration is a larger concept combining specific tooling, methods, branching, etc. You can do continuous integration with other branching models[1]. Unless a team tries hard to stick to strict CI, they usually end up with long-lived feature branches, long integration cycles, and clumsy, irregular deployments to irregular environments. So many teams still don't "get" CI, and end up wasting a shitload of time. [1] https://www.martinfowler.com/articles/continuousIntegration.html#StylesOfIntegration https://www.martinfowler.com/articles/continuousIntegration....

jdlshore 2y ago
The article you referenced specifically says that “trunk-based development” is a synonym for “continuous integration.” Please see the section titled “What is the difference between continuous integration and trunk-based development?”
- kspacewalk2 2y ago
  That's a nice bit of history, but that is no longer common usage. Terminology has a life of its own, it isn't owned by those who first use it.
- 0xbadcafebee 2y ago
  Martin's only saying that because the idea of CI came first, and he "doesn't want to rudely erase the work of Kent Beck". Trunk-based development has the branching model in the name. CI doesn't; it refers to a method to integrate code, and a whole lot of practices, tools, etc. In practice, most people don't even use the trunk model for their CI. Most people use feature branches and PRs. They still use everything else from CI, except for the single-branch. What should we call that, then? Not-quite-CI CI? It's simpler to refer to the general idea as "CI", even if it doesn't use a single branch. If you want to refer to the strict single-branch method, "trunk-based development" makes it clear.
  - steveklabnik 2y ago
    GitHub does have a setting in their branch rulesets to enforce linear history, it's kinda nice. But I agree with you that most people don't use it.

tharkun__ 2y ago

Never mind the content marketing of the "article". Use whatever tool you want to. If all you have is `if env==dev|staging`, that's enough, no need for "Bucket" or whatever. In general terms though: If you build your feature without wiring it up to the UI it means that you never integrate until the last moment. That way, you can't actually test a user interaction in an actually integrated fashion. This is really bad, because you will find all the integration problems at the very last moment. Basically when you're about to give it to your customers. Feature flagging combats that. It allows you to test the entire solution from the point of an actual customer, without exposing it to an actual customer.