Describe advanced local feature flag configuration #326
Conversation
|
No New Or Fixed Issues Found |
Deploying contributing-docs with
|
| Latest commit: |
5d663fd
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://6655c975.contributing-docs.pages.dev |
| Branch Preview URL: | https://ps-include-context-aware-fea.contributing-docs.pages.dev |
MGibson1
force-pushed
the
ps/include-context-aware-feature-flag-example
branch
from
05adfb8
to
c910e54
Compare
| @@ -1,8 +1,3 @@ | |||
| --- | |||
There was a problem hiding this comment.
❓ Why open this up to everyone? We do not want to encourage usage of this except internally.
There was a problem hiding this comment.
The metric I use for internal vs external is whether or not special access is required. The feature flags is in the AGPL licensed section of the codebase and not blocked by any employee-specific secrets.
I don't see why we wouldn't want external contributors feature flagging their contributions, if it makes sense and they are able.
There was a problem hiding this comment.
They're not able, since we'd have to register flags in LD. If you think an engineer would connect with them to do that then alright, but it's a bit of a jump from today.
There's sometimes an eagerness to adopt features in the community and what's happened is users start trying to put these developer overrides in and have problems, therefore increasing support needs. I want the impetus to be on our internal engineering team to quickly remove these in a follow-up release instead.
| <summary>Context-aware feature flag JSON</summary> | ||
| <div> | ||
| <div> | ||
| The `flags.json` file can also define flags which respond to user context. Currently, only `UserId`and the `OrganizationId` of all organizations a user belongs to are included in our feature flagging context. The syntax for defining context-aware flags amounts to defining a `flag` object which specifies `variations` values and `rules` which are evaluated against the user context. A `fallthrough` object is also available to specify a default variation. Rules are represented by `segments`, which are defined in the same file. |
There was a problem hiding this comment.
| The `flags.json` file can also define flags which respond to user context. Currently, only `UserId`and the `OrganizationId` of all organizations a user belongs to are included in our feature flagging context. The syntax for defining context-aware flags amounts to defining a `flag` object which specifies `variations` values and `rules` which are evaluated against the user context. A `fallthrough` object is also available to specify a default variation. Rules are represented by `segments`, which are defined in the same file. | |
| The `flags.json` file can also define flags that respond to user context. Currently, only `UserId` and the `OrganizationId` of all organizations a user belongs to are included in our feature flagging context. The syntax for defining context-aware flags amounts to defining a `flag` object that specifies `variations` values and `rules` which are then evaluated against the user context. A `fallthrough` object is also available to specify a default variation. Rules are represented by `segments`, which are defined in the same file. |
There was a problem hiding this comment.
⛏️ This is also violating our line lengths since it's in custom HTML.
There was a problem hiding this comment.
❌ We support an addition service account context as well that's omitted.
There was a problem hiding this comment.
Good point, we actually have three contextKinds now that I look closer. I'll expand to include descriptions of data on each
Co-authored-by: Matt Bishop <[email protected]>
Objective
I had cause to add test flag differences between authenticated and unauthenticated contexts.
In a local system, this means needing to expand our basic JSON definition considerably to define segments, rules, and flags. This documents the basics of how that works and provides an example to work from should others need to do the same.