...
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 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 filesand 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? (Maybe at least those which will live in application more than others or will go into releaseProbably 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. (I assume that if there will be some migrations associated to feature toggles they could be configured only on application )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.