Feature flags allows to hide not-yet-ready feature from the user, making it possible to merge not fully completed features to Master and deploy to PROD.
Feature flags align with twelve-factor-app principles (as with any other settings they could be overriden via environment variables on Stage)
Here's the idea:
- You start to implement a feature
- You implement some very first steps, and according to trunk-driven-development want to merge it to master
- You need master to be deployable to PROD, but your feature isn't ready to be shown to the user yet (since you just started)
- You create a feature-flag and turn it ON in DEV or Canary environment, and turn it OFF on Prod (via environment variables on docker container)
- You add a code to visually hide / disable the feature if feature-flag is off.
For backend you should add a feature-flag as a boolean setting in appsettings.json
.
You then read it from appsettings
as a usual configuration.
You could easily override anything specified in appsettings.json
using env. variables. E.g. Email__Host=smtp.sendpulse.com
.
Check out env-variables.ts for a reference implementation (isMiniProfilerEnabled
feature flag).
Steps to add:
- Add variable to .env file
- Add variable with type STRING to env.d.ts
- Use normal ways to access env. variables (provided by vite), e.g.
import.meta.env.REACT_APP_SENTRY_DSN
- Env. variables should have a prefix
REACT_APP
- Set variables when running Docker image on certain stage (e.g. in
Configuration
section of App Service in Azure Portal) - We use import-meta-env plugin so you could override these variables at runtime as well.
- On hosting machine, when Docker image starts run
npx @import-meta-env/cli --example .env
which will use env. variables to override previously defined values. Steps 6 and 7 are already implemented in a template, so no need to do them for each feature flag.