Feature Toggles (WIP)

Ticket: OLMIS-4797 - Getting issue details... STATUS

Reference Articles: Martin Fowler - Feature Toggles and Trunk Based Development - Feature Flags

Basic concept

The concept of Feature Toggles is based on having alternative codepaths and choosing between them at runtime. This allows developers to have in-progress features on shared integration branch (i.e. git master branch) and still being able to deploy it on production. To determine if new feature should be used/executed we need to have some kind of toggle router/service to check status of a flag or change it.

We can categorize feature toggles by how dynamic can they be switched:

on deployment
on runtime reconfiguration
on each request

or how long they (should) live in application.

Possible ways to handle feature toggles configuration

application.properties file
java class with constants
environment variables (won't work as a runtime configuration on docker, make more sense as on deployment configuration)
maybe introduce new endpoint for runtime toggle switching
using header or cookie per request toggle switching (could be done using HandlerInterceptor)

Maybe we should consider a new service with endpoint? This would simplify implementation in each service, may make response time longer. Also this could be a solution to cross-project feature flags and good way to retrieve flag statuses for UI.

Questions

Which options of switching toggles should we support? Do we need a special endpoint to enable changing toggle state at runtime? (We are not going to support runtime toggle switching).

Do we need a new micro-service for configuring toggles? (not a new microservice )

Should we introduce some Jira ticket label to indicate which type of toggle feature uses?

Should we document our toggles somewhere? (Probably yes)

Can we consider Batch Approval page as a candidate for feature flag that will be released? (Yes)

Do we need a admin UI for runtime configuration of feature toggles? (No)

How to deal with db migrations for those features? Do we need to introduce some java based migrations? (Flyway probably does not support procedure based SQL). We could have single java migration that will get all enabled toggles and find sql files in separate resource folder based on toggle name and execute them, if toggle will be removed and included into application those sql files could be moced to db/migration folder. (We are going to toggle using different sql tables, not sql migrations).

Chosen approach

To keep our solution as simple as possible we are going to allow setting those flags only using environment variables. For now we don't think that we should support switching toggles at runtime.

We are going cover implementations for both toggle statuses by unit/integration tests. As for contract tests there will be only those which are testing default implementation - this is caused by lack of runtime toggle switching and running builds for all possible permutation of feature flags after each commit seems not optimal for our Jenkins configuration.

As for feature flags that will touch data base we are going to support toggle based migrations. Instead we are going to use regular migrations to add new sql tables and decide if code is going to use those based on toggle state in repository layer.

Regarding UI we are also going to support flags configuration from env variables. Those are going to be injected into angular service before running reeference-ui application using env-replace. Other option is to use some caching service like Redis but it will require some work to configure it for our micro service environment.