Should we use feature flags for work in progress features?

[rogerhutchings]

Firstly, this is a pretty thorough article on feature flags, and uses Javascript as the language: https://martinfowler.com/articles/feature-toggles.html

Context

We currently have a deployment setup where complete new features are merged into the master branch, and master is automatically deployed to the staging environment. master is then deployed to production manually via a lita command.

However, we also have a requirement to be able to show new features in progress before they are deployed. e.g. a design review of a new component before it goes live.

In Panoptes-Front-End, this is achieved by deploying a feature branch to its own staging environment, which we can do because it's a single page app; this becomes a lot more involved with the rebuild.

Possible solution

New features that aren't ready for deployment are hidden behind a feature flag, which is toggled via a query parameter in the URL. When the parameter is present, it shows the new feature, and falls back to existing behaviour when it's not.

To do a design review, the new feature is merged to master with its feature flag, and deployed to staging. We then get it reviewed on the staging environment by using a URL with the right query param, make any changes needed, and remove the feature flag.

If we need to trigger a production deploy during this process, it doesn't matter; the new code path is only triggered with the query param.

Example implementations

• https://github.com/jayf/javascript-feature-flags
• https://github.com/paralleldrive/react-feature-toggles/

[camallen]

The API has feature flags built in through the flipper library https://github.com/jnunemaker/flipper, FWIW - We could expose these publicly via the API for the JS app to modify behaviour and load this data to an app store. Though we'd have to serve more requests to keep the feature flag states consistent between client / server and I'd prefer the API didn't do this.

In my opinion, feature flags are more aligned to changing run time not deploy time to modify the activated code paths.

My gut reaction is that adding this behaviour is a patch to fix the missing feature branch deployments. It adds another mechanism and increases our app complexity.

I think the best solution here is to fix the feature branch deployments or invest some time on it before adding feature flags in.

[srallen]

We agreed to writing a script to create temporary deployments for branches in ADR 17, so I'd prefer we finish that part up first then circle back to this idea to determine if it's still needed.

[eatyourgreens]

I think master should be reserved for beta testing of features that are scheduled for the next release. I’m also ok with us using flags to hide experimental work like translations or workflow advancement.