Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe advanced local feature flag configuration #326

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Describe advanced local feature flag configuration #326

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
275d0b2
Describe advanced local feature flag configuration
MGibson1 Mar 20, 2024
c910e54
Clarify UserId property in context
MGibson1 Mar 20, 2024
5d663fd
Apply suggestions from code review
MGibson1 Mar 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 101 additions & 5 deletions docs/contributing/feature-flags.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,3 @@
---
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ Why open this up to everyone? We do not want to encourage usage of this except internally.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

sidebar_custom_props:
access: bitwarden
---

# Feature Flags

## Background
Expand Down Expand Up @@ -97,6 +92,107 @@ configuration setting can be used to override it. The file must be present befor
solution, but once there you can change the file contents and see immediate results in running /
debugging code.

<details>
<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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ This is also violating our line lengths since it's in custom HTML.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ We support an addition service account context as well that's omitted.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, we actually have three contextKinds now that I look closer. I'll expand to include descriptions of data on each


A feature flag may not appear in both the `flags` object and in the `flagValues` object.

Note that `UserId` is referred to as `key` in the `clauses` object while defining a segment.
</div>
<br/>
<details>
<summary>
JSON example
</summary>
<div>

```json
{
"flagValues": {
"example-single-boolean-key": true,
},
"flags": {
"example-advanced-configuration": {
"key": "example-advanced-configuration",
"on": true,
"variations": [
false,
true
],
"fallthrough": {
"variation": 0
},
"rules": [
{
"variation": 1,
"clauses": [
{
"contextKind": "user",
"attribute": "segmentMatch",
"op": "segmentMatch",
"values": [
"user-segment"
]
}
]
}
],
"version": 1
}
},
"segments": {
"user-segment": {
"key": "user-segment",
"rules": [
{
"clauses": [
{
"contextKind": "user",
"attribute": "key",
"op": "in",
"values": [
"<<UserIdGuid>>",
"<<UserIdGuid>>"
...
]
}
]
}
],
"version": 1
},
"organization-segment": {
"key": "organization-segment",
"rules": [
{
"clauses": [
{
"contextKind": "user",
"attribute": "organizations",
"op": "in",
"values": [
"<<OragnizationIdGuid>>",
"<<OragnizationIdGuid>>"
...
]
}
]
}
]
}
}
}
```

</div>
</details>

</div>
</details>

### Local configuration: code modification

In some situations there may be a need to change a feature flag value to be something other than its
Expand Down