Meetup: Managing Feature Toggles in Teams - Paul Börding
Table of Contents Part I - unleash the potential
- dynamic
- used by default
- per story
PART II - the cleanup
- tested
- visible
- short-lived
Q&A
Based on article: https://www.thoughtworks.com/insights/blog/managing-feature-toggles-teams
https://www.meetup.com/ThoughtWorks_Koeln/events/275602752/
A tale of 2 teams both used feature toggles one team :-) other team :-(
Why feature toggles
manual deployment: features may not be ready != continuous delivery
- Dynamic
flippable
easy (“click of a button”)
in seconds
configurable per environment
code is the same toggles may be different
benefits:
-enable feature preview
-emergency switches
disadvantage: -can’t go back in git history to see which were on / off
- by default
“Do we need a feature toggle?”
“Always, unless a very good reason not to”
- per story
BAD example: multiple stories per toggle
If one story is done, you either:
-
enable both -> errors for the unfinished one
-
enable neither -> delay value delivery
benefit:
- deliver value sooner
- no unexpected side effects
- Tested
Keep in mind: smallest possible feature toggle
toggle is always on for all tests on local environment
old test is still there while feature is not done
(Java library Toggles)
when done -> cleanup
remove legacy tests
remove toggle
- Visible
visible to entire team
stickies still there == technical debt
- Short-lived
idea: expiration date
idea: toggles in existence + WIP-limit
too many toggles: cascading complexity
now we can do continuous delivery!
SUMMARY
https://www.thoughtworks.com/insights/blog/managing-feature-toggles-teams
Q&A
Q: do you put feature flags around Unit Tests too. or that all features are ON in test? even conflict ones? new feature -> unit test fails if toggle is off
depending on library, you can scope it per test (default all enabled, specific
Q: If you remove/clean the toggle, you cannot use it to hide/show to users. Isn’t it one of the uses of feature toggles?
different type of toggles: -release toggles -seasonal / long-lived toggles
long-lived toggles should be treated differently
Re: the last question: the different types of toggles https://martinfowler.com/articles/feature-toggles.html#CategoriesOfToggles
Q: we mark the whole test class as legacy with switched off toggle and create a copy of that test class with switched on toggle. So if we want to cleanup the toggle, we can delete the class and not have to look for the specific test methods. What do you think?
might get complex when multiple toggles for the same class
Q: How would you deal with FTs in a scenario where you don’t have one production installation (e.g. a website) but hundreds of customer installations, many of them on-premise?
Don’t know this talk is for continuous delivery, deploying multiple times per day not relevant for this scenario
How to flip dynamic feature toggles, when they needs database migrations, eg. by Liquibase on application start? Are there any Good Practices?
Don’t know
Q:
Q: Can you comment a little bit more on “non-Release Toggles”? Are there good practices for these, too?
non-release toggles -AB testing
I have opinions, but I would have to research.
Q: What if the roadmap to activate a FT in production is not so short-lived? I.e. you are trunk-integrating features that should not be visible until a master epic is complete (meaning several sprints of work ahead)
Does not apply for this approach.
Q: within a microservices architecture, if a feature affects multiple services, how do you keep make sure the state of the toggle is synced? do you use a centralized features API or some UI that switches the toggles for all affected services?
Sounds reasonable
Q: Which Feature Toggle library/tool do you recommend for java
Togglz stores state in database UI for toggling
Q: How would you handle nested features where you have a big feature containing several small ones? The idea is that on Production you would like to deliver the complete feature but on PreLive you want to show off the parts themselfes. Would you recommend to use only the inner toggels or would you suggest to have the main toggle aside from the inner toggles ?
depends on what you’re implementing maybe new endpoint? -> no need for toggle
Q: How do you make sure that the toggle is configured in one place, e.g. when a feature includes changes in the backend and the frontend?
We did toggle only in backend Frontend fetches from backend the state of toggles eg. Java + React eg. Thymeleaf was in backend anyway