Hi dev forum,
I’m currently working on introducing Feature Flags into our application. I’ve created some confluence page to keep there some ideas and chosen solutions.
For now we decided to just support setting those flags only on deployment using environment variables to keep it simple. There will be no option to change it at runtime.
Our UI services will also use env variables. Those variables will be injected into dedicated UI service (using env-replace) that will be managing feature flags. If using env variables from ref-distro will not work we need to introduce some additional endpoint or service, like Redis, for getting current state of feature flag.
Regarding features that will require sql schema change we will not support conditional flyway migrations. Instead we will just do regular migration (i.e. creating new sql table) and decide on the repository level which sql columns/tables will we use. Of course we need to make sure that no “in progress” migrations will go into the release.
We also need to specify how log those feature flags should exists in our application. Probably most of them will be short lived and removed after few weeks but there will be some long term features that could support disabling them on deploy (like batch approve screen). How should we document those feature flags?
Those are some ideas and thoughts that I have written down after meeting with Josh. We probably still need to have some more use cases for those feature flags. The basic idea behind those is to have a option to implement “controversial” changes on master branch instead of doing it on branches and deal with merging huge changes in pull requests. Also we always have option to disable some functionality without changing our codebase.
As a example of feature flag on the UI I will introduce it to Batch Approve screen which we disabled in our last release. For the backend services we have OLMIS-2970 for improving performance of SoH calculation in Stock Management. It touches both java code and sql schema but it is a big feature and hard to implement quickly. Do you have some ideas of some small bug/tech debt that will also require some changes in sql schema and could be a good example for feature flag? Also more examples could positively affect implementation of this feature.
SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41