Copying Feature Flags with Targeting User and/or rules

[thanh81]

Any way to copy a feature flag's targeting user/rules? I understand if the environments wouldn't have the user/etc to not be able to copy, but if it does? Or if it's just metadata?

I was trying to see if LaunchDarkly supported it and it looks like it does, so long as all the feature flags being copied has all the users/etc supported at the targeting environment.

[deleteLater]

Currently, we do not support copying targeting users and rules. For copying them, we need to consider

• If the src flag's target users don’t exist in the target environment, should we copy these users into the target environment?
• If the src flag contains a rule that using Segment, and this segment doesn't exist in the target environment. Since the segment may also reference environment users, making it hard/impossible to copy.

[thanh81]

If we are making complex targeting rules, what would you recommend be the best way to eventually use the rule in production? Thanh Nguyen

…

On Mon, Nov 25, 2024 at 1:41 AM deleteLater ***@***.***> wrote: Currently, we do not support copying targeting users and rules. For copying them, we need to consider - If the src flag's target users don’t exist in the target environment, should we copy these users into the target environment? - If the src flag contains a rule that using Segment, and this segment doesn't exist in the target environment. Since the segment may also reference environment users, making it hard/impossible to copy. — Reply to this email directly, view it on GitHub <#680 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBIGWINVIJZISGXMYDPH5L2CLBA7AVCNFSM6AAAAABRSWGFI2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZWHA3TIOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[deleteLater]

It depends. But a general rule is if you want to reuse these rules across multiple flags, put them into a Segment. Or if the flag configuration is too complex and hard to maintain, then I can simplify it by converting some targeting users/rules into Segments. No matter what, your goal should be to make it easier for others on your team to understand/maintain it.

[CuddleBunny]

Hello @deleteLater!

I've recently started working with @thanh81 in featbit and am trying to migrate some very complex feature flags from Microsoft.FeatureManagement json files. Many of these were implemented from IContextualFeatureFilter<T> and supply variants based on properties on the passed context. A simple example would be something like the following, which would be enabled for a user in those locations:

"SomePlacesFeature": {
  "EnabledFor": [
    {
      "Name": "MetadataFilter",
      "Parameters": {
        "Country": [ "Spain", "Canada" ]
      }
    }
  ]
},

This is easily handled in featbit with the user attributes functionality.

---

If the src flag's target users don’t exist in the target environment, should we copy these users into the target environment?

This shouldn't be the default behavior, in most applications users don't span environments. It could be optional if other folks are interested in this behavior. It would make sense not to copy any rules which target users directly.

If the src flag contains a rule that using Segment, and this segment doesn't exist in the target environment. Since the segment may also reference environment users, making it hard/impossible to copy.

Like the above, segments could be copied only if they don't target specific users. Both of these scenarios could be handled by either altering the messaging about not copying targeting rules to say it will only not copy those with user targets or copying those rules with the user list empty and prompt the user to enter or delete the rule as necessary.

---

In my experience, it's fairly rare to target segments of specific users when the system allows for access to the targeting criteria. It is also very time consuming and error prone to re-enter targeting rules across environments. It would be a huge boon to be able to copy these rules.

If adding this to the featbit UI is undesirable, a workaround could also be achieved by exposing the APIs used to add targeting rules and user attributes so that we could script our own migration logic. This would also help us with copying targeting rules across separate featbit instances.

[deleteLater]

Hi @CuddleBunny , thanks for your input. Very helpful and as you said if we ignore targeting users, and prompt the user in someway, things will become much more easier. We will consider adding this feature.

[thanh81]

@deleteLater, that would a great feature. we're trying to use featbit but have very complex targeting rules. Do you think it would be available any time soon?

[cosmic-flood]

@deleteLater, that would a great feature. we're trying to use featbit but have very complex targeting rules. Do you think it would be available any time soon?

We are working on it and hope to have first release next week (fingers crossed). After that, we can exchange more ideas for further improvements. @thanh81

[deleteLater]

Related PR (#696) has been merged and this feature has been included in v4.2.1

[thanh81]

Related PR has been merged: #696

Does it automatically build? If so, where's the artifacts?

[deleteLater]

Nope, but we may release v4.2.1 tomorrow which includes this feature.

[thanh81]

I saw the new release. Anyway you can update the helm charts also so it can reference the latest release?

[cosmic-flood]

Thank you for reminding us. We will update the Helm charts, but it will take some time to perform the necessary tests.