cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Reducing Release Risk with AI-Driven Feature Flag Analytics - review

Slawa
Advisor

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.

Slawa_0-1691508364206.png

 

  1. 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
  2. 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)
  3. 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.

1 REPLY 1

ChadTurner
DynaMight Legend
DynaMight Legend

@Slawa are you still having an issue with this? Maybe an RFE would be suitable with this. 

-Chad

Featured Posts