Meetup: Managing Feature Toggles in Teams - Paul Börding

Table of Contents

Part I - unleash the potential

1. dynamic

2. used by default

3. per story

PART II - the cleanup

1. tested

2. visible

3. 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

1) 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

2) by default

"Do we need a feature toggle?"

"Always, unless a very good reason not to"

3) 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

1) 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

2) Visible

visible to entire team

stickies still there == technical debt

3) 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