4 ms·

I'm pushing for toggles on my team, haven't made a single feature branch in this repo resulting in no merge conflicts (yay). Sofar I'm the only one regularly d

I'm pushing for toggles on my team, haven't made a single feature branch in this repo resulting in no merge conflicts (yay). Sofar I'm the only one regularly doing it without feature branches. Running with the idea that just because you can branch cheap doesn't mean you should. Of course toggles are technical debt to be managed, but so are branches. I've found good practice has been mentioning which toggles are available on the README with their defaults (could be generated)... they should be tracked and removed ASAP. I read a newer article that breaks them down into categories http://www.infoq.com/news/2016/02/featuretoggles http://www.infoq.com/news/2016/02/featuretoggles. Toggles over branches are showing value as we run different variants on staging without having to redeploy different builds, but instead changing a launch variable. It's especially clear with 2+ WIP features. We're using environ with Clojure which doesn't have any fancy runtime toggling, but that'd be another thing to look at.

falcolas 11y ago
The tech debt associated with branches disappears with the completion of the merge request. The tech debt with feature flags doesn't disappear until someone gets around to removing the (now) dead code. Personally, I use both, based on what is best for the feature. Why not, after all?
- harlanji 11y ago
  I love branches in theory, but the main problem has been in practice around CI. It's a nightmare trying to manage a staging environment with feature branches involved... given better tools/a better build pipeline I'd go back. I agree, toggles are basically programs branches compiled in... analogous goto vs if/else control structure. But day-to-day, stakeholders want to test feature X that they've heard is going well but it's not stable enough for develop? Okay, let's [engineering time and $$$]. vs. adding FEATURE_NEWDB=true to the upstart script. We've already got automation engineers helping us out, but until the deployment problem is solved toggles are more practical in our case.
  - falcolas 11y ago
    How hard is it to set your CI to run off a separate branch? Or to run CI for all branches which are checked into a repo (a common option I've seen implemented)

falcolas 11y ago

The tech debt associated with branches disappears with the completion of the merge request. The tech debt with feature flags doesn't disappear until someone gets around to removing the (now) dead code. Personally, I use both, based on what is best for the feature. Why not, after all?

harlanji 11y ago
I love branches in theory, but the main problem has been in practice around CI. It's a nightmare trying to manage a staging environment with feature branches involved... given better tools/a better build pipeline I'd go back. I agree, toggles are basically programs branches compiled in... analogous goto vs if/else control structure. But day-to-day, stakeholders want to test feature X that they've heard is going well but it's not stable enough for develop? Okay, let's [engineering time and $$$]. vs. adding FEATURE_NEWDB=true to the upstart script. We've already got automation engineers helping us out, but until the deployment problem is solved toggles are more practical in our case.
- falcolas 11y ago
  How hard is it to set your CI to run off a separate branch? Or to run CI for all branches which are checked into a repo (a common option I've seen implemented)