One of the topics i’ve heard recurring in my podcast is Feature Flags. It is not a complete post for learning, but just penning down whatever i’ve learnt the past week.

Questions:

1. when should you not use feature flags?
2. How to actual implement feature flags

Ive also found an artticle with good content to share with my readers: https://launchdarkly.com/blog/what-are-feature-flags/

Definition of feature flags

A software development process used to nebale or disable functionalities remotely without deploying code. New features can be deployed without making them visible to users.
feature flags help to decouple deployment from release letting you manage the full lifecycle of a feature.

It has many names:

• Feature toggle
• Feature flipper
• Feature switch
• Conditional feature
• Feature controls
• Release toggle

If you want to release the feature only for employees using their corporate emails, that can be achieved using feature flags.

Feature flags eliminate the need to maintain multiple feature branches within your source code. All changes can be done to the primary branch, only whent he feature is ready then it will be enabled by default, and once its stable, you should consider removing the feature flag entirely.

Who uses feature flag?

Feature flags are built primarily for non-tech usages. Engineers are creating switches for you as non-tech to toggle and give you more control over the application.

• Sales and Customer Support to provision entitlements
• Product Management to manage beta programs
• Marketing to run A/B testing

Ideally, the use of feature flag helps with:

• reduce the number of code rollback
• Gradually rollout new functionalities to users
• minimize the risk of a release by first releasing to small groups of users.
• test user acceptance

If you want to consider reducing your time to deployment, companies rely on feature flag management to gradually roll out features to users. Continuous delivery is the ability to shorten release cycles and get new functionalites in the user’s hands quickly and safely.

Safely has a few contexts:

• release to gain confidence in your new feature to work in production
• release to a smaller group of people for a start to incrementally gain confidence.
• allow the feature to be switched off if the feature encounters an issue.

Progressive Delivery allows fine-grained control over rollout and ownership of a feature. Progressive Delivery includes user segmentation, traffic management, observability, and automation to release features to small portions of user.

• If you have a library that allows the switching on/off of a feature, that is merely subset of the Progressive Delivery framework.
• you have to consider traffic management, User segmentation and how you can observe the performance of enabled features.

Why use feature flags

Based on DevOps report, characteristics of high performing orgasnisations includes quicker deployment time and low rollback %
high performing teams deploy code 46x more frequently with a lead time from commit to deploy 2,555 times faster. They are deploying code faster and they fail less frequently. High-performing teams have a lower change failture rate and recover from incidents faster.

Creating a CI/CD pipeline is necessary to increase the velocity of code deployments.
If you want to enable trunk-base development for your company, you have to consider feature flags so new feature’s code can be pushed into a single branch (typically Master branch), without having it enabled. Trunk based development helps to eliminate merge conflicts, broken builds and thus have a cleaner codebase.

Instead of a feature branch, use a flag to gate features not ready for public viewing.

When to use feature flags

1. Improve feature rollout

Where feature flags make a difference?

• If you want fast deployments.
• If you want to give non-technical personnel control over features

How are feature flags deployed?

1. Manage all your feature flag naming in a single place

Create a class and create classes for it to be called in the application layer.
Need to understand this part

Reference: https://martinfowler.com/articles/feature-toggles.html

Best practices

1. Choose the right level of flagging

2. Flag naming
   Remove a flag once the rollout feature flag has served its purpose.
   always name your flags ending with “_enabled”

3. Set up logging
   Give yourself visibility on who toggled the feature flags. If you want to give everyone access rights to feature flags, you need to then trhttps://featureflags.io/feature-flags-uses/ for audit purpose.

Audit and access control: who can change the flags and track who changed the flags.lau

4. Give access to non-technical users
   Most effective when put into product team, QA team to control.

It can foster rollout thinking.

Allow feature flags to be toggled on run time via some form of admin UI

5. Control accesses to flag

Not all feature flags are easily available - especially the money generating ones

6. Flag Status
   Its to manage short and long term flags, and know when are these flags ready to be removed.
   Remove flags once they have fulfilled their purpose, else it will grow to become technical debt.

Try to avoid feature flag hell. Having feature flags with unclear status, so you do not know when you should be removing them.

7. Each feature should have their own flags

Reference: https://devcycle.com/blog/dos-and-donts-of-feature-flags

Types of feature flag

1. Release flag
   You will need this for quick turnaround in CI/CD environment.
   You can control % roll-out, user group configuration, geography configuration.

Using this is part of the CD’s requirements. You need in-progress features to be deployed to production. Allowing incomplete and untested codepaths to be shipped to production as latent code, which may never be turned on.

2. Experiment
   For A/B testing, releasing new features to production to a small population of users. You can choose to release new UI feature to opted-in users.

3. entitltement/access management
   this feature flag typically have longer lifecycle.

4. Ops Flag
   kill-switch that offers graceful degration of the system under stress during peak load, but maintains essential features.

5. Bussiness flag
   Enable or disable a feature based on time of the year. or geography.
   Example: Enable free subscription for just a weekend.

Use cases

1. Canary Releasing
   Allow the application to understand the concept of user cohorts. You only want to turn the new feature on for a small percentage of total user base - a ‘canary’ cohort

2. AB testing

3. Subscription

4. Maintenance Mode

5. Sunset features

Reference: https://featureflags.io/feature-flags-uses/
https://www.cloudbees.com/products/feature-management/use-cases/progressive-delivery
https://martinfowler.com/articles/feature-toggles.html

Existing tools

1. Launchdarkly
2. Rollout.io
3. Split.io
4. BulletTrain
5. Optimizely

NPM related libraries

• Flipit

Reference: https://theproductmanager.com/tools/best-feature-flag-software/

Example of how feature flags look like

References

• Perrislands
• Feature toggles
• What are feature flags
• Devops Report