4 ms·

feature toggles: do you use them? my experience with projects that do trunk based development, i.e. a single branch and time-based releases, is that not all fe

by gghh 11y ago

feature toggles: do you use them? my experience with projects that do trunk based development, i.e. a single branch and time-based releases, is that not all features can be ready when the release bell "rings", and something is necessarily half-baked. So you end up enclosing some code into "if (FEATURE_READY) {...}" so that it's there, but it isn't executed until a few releases later. This carries some problems, like the explosion of the quantity of toggles over time, dead code that nobody cleans up, etc.

phasmantistes 11y ago
As the article states, Chromium uses run-time checks (feature toggles) extensively. This lets half-baked features land and start undergoing testing before the feature is ready to be shown to the world. But we don't say "oh no, this feature isn't ready, let's wrap it in checks". The feature is wrapped in checks from the very first commit, so that everything stays stable on master and on any release branches which are cut from master. Then, when the feature is ready for prime-time, the developers working on it go through and remove the checks. So they don't accumulate in the codebase.
- lmm 11y ago
  Don't you end up with exponentially many combinations to test?
  - aboodman 11y ago
    The feature team is responsible for ensuring their in-progress work is sufficiently tested. This usually means that all their tests are run from the beginning of the features life. So, we don't end up testing every combination of features, but instead the union of all features. With good software design practices we don't usually find bugs that only occur with some specific non-total combination of features. But of course it does happen. The article isn't a way to make provably correct software; it's a way to keep the wheels on a massive, fast-moving project -- barely :).
    - lmm 11y ago
      Sure, which is why I'm interested - I work on a massive, fast-moving (proprietary) project, and team and feature branches are a vital part of the workflow, and merges seem less costly than the risks of feature flags. (Of course, the Knight incident being fresh in our minds, our assessment of those risks might not be entirely objective)

by gghh 11y ago

phasmantistes 11y ago

As the article states, Chromium uses run-time checks (feature toggles) extensively. This lets half-baked features land and start undergoing testing before the feature is ready to be shown to the world. But we don't say "oh no, this feature isn't ready, let's wrap it in checks". The feature is wrapped in checks from the very first commit, so that everything stays stable on master and on any release branches which are cut from master. Then, when the feature is ready for prime-time, the developers working on it go through and remove the checks. So they don't accumulate in the codebase.

lmm 11y ago
Don't you end up with exponentially many combinations to test?
- aboodman 11y ago
  The feature team is responsible for ensuring their in-progress work is sufficiently tested. This usually means that all their tests are run from the beginning of the features life. So, we don't end up testing every combination of features, but instead the union of all features. With good software design practices we don't usually find bugs that only occur with some specific non-total combination of features. But of course it does happen. The article isn't a way to make provably correct software; it's a way to keep the wheels on a massive, fast-moving project -- barely :).
  - lmm 11y ago
    Sure, which is why I'm interested - I work on a massive, fast-moving (proprietary) project, and team and feature branches are a vital part of the workflow, and merges seem less costly than the risks of feature flags. (Of course, the Knight incident being fresh in our minds, our assessment of those risks might not be entirely objective)