- last edited on by
IzabelaRokita
This is nice idea to display feature toogles in sessions: https://www.youtube.com/watch?v=VZakh1_oEL8
But there is atleast one major problem spotted in current implementation.
Session properties usage approach showed in video (assign name to string properties like stringproperties.featureName1, stringproperties.featureName2 etc) Is not manageable on a scale.
- App properties need to be created each time/deleted over time - this may leads to management overhead. New feature need to be tested each sprint
- Very expensive - dynatrace free teer is 20 vars, and since this is a SESSION property - each new one will be lead to wasting of money (it will require #1 active CRUD management for properties)
- This point is came from #1 and #2 since session properties configuration will be high mutable - that leads to a problem with "configuration as code approach" or additional overhead with scripting and clashes with elasicchash in dynatrace.
Probable solutions:
a) Dynatrace - create new type of vars: tra-ta-taa..... 🎵🎵🎵 array of strings )))
b) OBB: use single string variable AKA {app_name}_features and write vales in key value format with delimiters for easier parsing/matching e.g. "dark_mode=1 | new_login=0 | 3d_secure=0 | api_version=1.234 | jira_epic=DYNA-12345"
It will allow to extract values or combination in session query or data expoler by matching.
And will solve all problems mentioned above:
- management overhead
- cost
- potential conflicts in case of active CRUD
PS I don't know indgration details with "Feature Flag Analytics" but it seams like JS integration.
That leads to an option apply the same approach for action properties as well.
How do Feature Flags mitigate the risk of bad deployments? How can Feature Flags be rollout out selectively? How can the impact of Feature Flags on end users or systems be observed and analyzed? How do Flagsmith and #Dynatrace integrate, and what is the role of the open source standard ...
Featured Posts
