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 for backend services
- 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 to avoid )
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.
We should definitelly have a ToggleRouter in each service that handles checking toggle status. It should introduce methods which are checking flags status on various levels, i.e. in env variables or request headers/cookies. If there is no toggle definition on higher level it should use lower level definition (i.e. if toggle can be changed per request and there is no toggle definition in http request application should use toggle value from env variables/application properties etc.) This router could be a spring component with scope defined to request.
Feature toggles for UI services
For UI services we could download flag configurations from backend server, if we are going with endpoint solution, or simply use environment variables or config.json files.
Questions
Which options of switching toggles should we support? Do we need a special endpoint to enable changing toggle state at runtime?
Do we need a new micro-service for configuring toggles?
Should we introduce some Jira ticket label to indicate which type of toggle feature uses?
Should we document our toggles somewhere? (Maybe at least those which will live in application more than others or will go into release)
Can we consider Batch Approval page as a candidate for feature flag that will be released?
Do we need a admin UI for runtime configuration of feature toggles?
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. (I assume that if there will be some migrations associated to feature toggles they could be configured only on application )