Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019

Interesting. speech Edith Harbaugh, co-founder and CEO of flag feature platform LaunchDarkly. In the beginning, Edith recalls the dark days when she worked for a company where releases were once every year and a half ... and it was fast because a competitor had them every three years:) Then begins the story of the patterns and anti-patterns of their use. But before that, I would like to discuss that the very idea of flags seems very simple: we need to be able to cover some of the functionality in the code with a flag that can be remotely turned on / off. It helps with a few things. TBD works well with feature flags. (trunk based development)And without them, almost not. Release management is getting easier (cell-wise) You can test functionality on part of the audience, such as employees. But here we find ourselves at the junction of two worlds - working with code and releases and experiments. (a/b tests, user segmentation, personalization,)

So let me tell you what Edith said.

Patters and good ways to use flags Feature kill switches - patterns for turning off features in case of problems or in case of load spike

• Marge brunch without conflict - conditionally feature flag - is an enabler for TBD, which I already talked about. Controlled rollout - conditionally rolling out a portion of traffic to a new feature Early access betas for the most loyal/best users To block features for some users (For example, those who only need to be slack.) To test in the sale and reduce the importance of the staging circuit (Edith proposes to kill him altogether.) For subscriptions, where some features are available only by subscription (I think it's a strange case, of course.)
• To turn off old features.

Anti-patterns and joints

• Curved flag names - it just confuses and prevents the use of flags Overused flags are the same flags that are used by different teams in different ways, conventionally some think that this flag cures cough, and others that of constipation:) Conflicting flags - given the combinatorics, conflicting flags are very easy to get, especially if you don't think ahead about what we cover with flags The use of flags for critical functionality that should not be disabled for a long time is an example of a CMS system where you can deactivate file downloads with a flag, which effectively disables the entire system:) The point is that such a flag has long since become meaningless:) Flags that stay in the code and never get snuffed out - it just degrades the codebase

Finally, recommendations are made.

• Flag carefully
• Lock down access
• Remove flags

P.S. We had different systems at the company to control flags and experiments. We are now moving towards a common solution where Basic flag management scenarios will be right inside our IDP (internal developer platform) This section is about code + release management. Extended control scenarios will be inside the a/b platform - this is part of using flags for experimentation, personalization, bet and so on.

If you like such tasks and have experience in industrial development, you can write to me:)

#Software #Devops #SRE #Reliability #Architecture #Engineering #Processes