Last active
March 24, 2023 14:06
-
-
Save tarqd/00648bd12a5162763ee42deb27806422 to your computer and use it in GitHub Desktop.
Revisions
-
tarqd revised this gist
Mar 24, 2023 . 1 changed file with 0 additions and 1 deletion.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -37,7 +37,6 @@ Consider the complexity cost of introducing a flag vs the benefits. If your flag - `Release: Chatbox Frontend` - `Release: Chatbox Backend` - ### Bad: - `Release: Chatbox Frontend Sprint Fix CSS Bug 112` -
Mar 1, 2022 . 1 changed file with 1 addition and 1 deletion.There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -28,7 +28,7 @@ - Feature flags should not replace any configuration that would completely block the application from starting (database hostname, api urls, etc) - **As a database or file store** - Try to keep variations small - Avoid large/complex JSON payloads if you can. Consider if you can break the dynamic parts out into individual flags - Do not bloat the initialization payload by treating feature flags as a source of truth. - **For every commit/sprint/change**. Consider the complexity cost of introducing a flag vs the benefits. If your flags look like your commit log or jira backlog, something has gone wrong -
Mar 1, 2022 .There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode charactersOriginal file line number Diff line number Diff line change @@ -0,0 +1,43 @@ # When should I not use feature flags? ## Feature flags work great for use-cases that require these properties: **Dynamic** - Feature flag changes are propagated to SDKs in under 200ms without restarting the application **Contextual** - Feature flag rules are evaluated against the user object, allowing you to define rules that easily adapt your business requirements as they change **Time-bound** - Feature flag rules and targets can be made to automatically expire or change using workflows **Delegated** - Approvals, Triggers, and the API allow you to easily delegate the authority to change application behavior to people and services with a complete audit trail ## You should not use feature flags: - **As a replacement for secrets management or to target on secrets/credentials** - **As a replacement for configuration management** - Feature flags are not a good fit for replacing configuration that is static or rarely changes at runtime. You may want to consider augmenting / overriding with feature flags instead. - Feature flags should not replace any configuration that would completely block the application from starting (database hostname, api urls, etc) - **As a database or file store** - Try to keep variations small - Avoid large/complex JSON payloads if you can. Consider if you can break the dynamic parts out into individual flagsπ - Do not bloat the initialization payload by treating feature flags as a source of truth. - **For every commit/sprint/change**. Consider the complexity cost of introducing a flag vs the benefits. If your flags look like your commit log or jira backlog, something has gone wrong - ### Good: - `Release: Chatbox` - `Release: Chatbox Frontend` - `Release: Chatbox Backend` - ### Bad: - `Release: Chatbox Frontend React Component` - `Release: Chatbox Frontend Sprint Fix CSS Bug 112`