Skip to content

Commit ba74a39

Browse files
committed
Revise content
1 parent a4162d9 commit ba74a39

File tree

1 file changed

+25
-20
lines changed

1 file changed

+25
-20
lines changed

practices/feature-toggling.md

Lines changed: 25 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,6 @@
1414
- [Best practice lifecycle](#best-practice-lifecycle)
1515
- [Testing toggled features](#testing-toggled-features)
1616
- [Designing for failure](#designing-for-failure)
17-
- [Comments](#comments)
1817
- [Further reading](#further-reading)
1918

2019
## Context
@@ -41,7 +40,7 @@ This is particularly powerful in continuous delivery environments where small, f
4140

4241
For a detailed and widely referenced introduction to this practice, see Martin Fowler's article on [Feature Toggles](https://martinfowler.com/articles/feature-toggles.html).
4342

44-
While some areas are looking to adopt a more enterprise-grade offering with Flagsmith, it's important to recognise that more minimal feature toggle approaches may be appropriate for smaller or simpler systems. The [Thoughtworks Technology Radar](https://www.thoughtworks.com/radar) notes that many teams over-engineer feature flagging by immediately adopting complex platforms, when a simpler approach (e.g., environment variables or static config) would suffice. However, irrespective of how the toggle is implemented, the **governance, traceability, and lifecycle management processes should be consistent**.
43+
While some areas are looking to adopt a more enterprise-grade offering with a dedicated feature toggling tool, it's important to recognise that more minimal feature toggle approaches may be appropriate for smaller or simpler systems. The [Thoughtworks Technology Radar](https://www.thoughtworks.com/radar) notes that many teams over-engineer feature flagging by immediately adopting complex platforms, when a simpler approach (e.g., environment variables or static config) would suffice. However, irrespective of how the toggle is implemented, the **governance, traceability, and lifecycle management processes should be consistent**.
4544

4645
## What is feature toggling?
4746

@@ -51,9 +50,9 @@ Toggles can be defined statically (e.g., environment variable or config file) or
5150

5251
## Why use feature toggling?
5352

54-
- **Decouple deployment from release**: Code can be deployed behind a toggle and activated later.
53+
- **Decouple deployment from release**: Deploy code behind a toggle and activate it later.
5554
- **Enable safe rollouts**: Enable features for specific users or teams to validate functionality before full rollout.
56-
- **Support operational control**: Temporarily disable a feature causing issues without rollback.
55+
- **Support operational control**: Temporarily disable a feature which is causing issues, without needing to rollback.
5756
- **Enable experimentation**: Run A/B tests to determine user impact.
5857
- **Configure environment-specific behaviour**: Activate features in dev or test environments only.
5958

@@ -66,23 +65,27 @@ According to Martin Fowler, toggles typically fall into the following categories
6665
- **Ops toggles**: Provide operational control for performance or reliability.
6766
- **Permission toggles**: Enable features based on user roles or attributes.
6867

68+
> [!NOTE]
69+
> While permission toggles can target users by role or attribute during a rollout or experiment, they are not a replacement for robust, permanent role-based access control (RBAC). Use RBAC as a separate, first-class mechanism for managing user permissions.
70+
6971
## Managing toggles
7072

7173
Poorly managed toggles can lead to complexity, bugs, and technical debt. Best practices include:
7274

7375
- Give toggles meaningful, consistent names.
74-
- Store toggle state in a centralised and observable system.
7576
- Document the purpose and expected lifetime of each toggle.
76-
- Remove stale toggles once their purpose is fulfilled.
77-
- Avoid nesting toggles or creating toggle spaghetti.
77+
- Store toggle state in an observable system.
78+
- Guard the feature behind a single toggle check, and pass the resulting behaviour or strategy through your code to minimise duplication and simplify removal.
7879
- Ensure toggles are discoverable, testable, and auditable.
80+
- Avoid nesting toggles or creating toggle spaghetti.
81+
- Remove stale toggles once their purpose is fulfilled.
7982

8083
## Toggling strategy
8184

8285
Choose a feature flagging approach appropriate for the scale and complexity of your system:
8386

8487
- **Simple applications**: Environment variables or configuration files.
85-
- **Moderate scale and beyond**: Look to make use of e.g. [Flagsmith](https://www.flagsmith.com/), which supports targeting, analytics, and team workflows.
88+
- **Moderate scale and beyond**: Look to make use of a dedicated feature toggling tool, which supports targeting, analytics, and team workflows.
8689

8790
Feature toggles should be queryable from all components that need access to their values. Depending on your architecture, this may require synchronisation, caching, or SDK integration.
8891

@@ -105,16 +108,21 @@ Document toggles in your architecture or delivery tooling to ensure visibility a
105108

106109
Features behind toggles should be tested in both their enabled and disabled states. This ensures correctness regardless of the toggle value.
107110

108-
- Write tests that explicitly set the toggle on and off.
109-
- Use test frameworks that allow injecting or mocking toggle values.
110-
- Consider test coverage for the toggle transitions (e.g., changing at runtime).
111-
- Ensure integration and end-to-end tests include scenarios where toggles are disabled.
111+
- Prefer testing the behaviour behind the toggle (e.g. via Strategy implementations) directly, rather than toggling features within tests.
112+
- Where the Strategy Pattern is used, write separate unit tests for each strategy to validate their behaviour in isolation.
113+
- If toggling is required in tests, use frameworks that allow injecting or mocking toggle values cleanly.
114+
- Ensure integration and end-to-end tests include scenarios with the toggle both enabled and disabled, especially if the toggle is expected to persist across multiple releases.
115+
- Include toggle state in test names or descriptions to clarify test intent (e.g. `shouldReturnNull_whenFeatureDisabled()`).
116+
- Track test coverage across both toggle states and regularly review it for long-lived or critical toggles.
117+
- Ensure test coverage includes edge cases introduced by toggled logic, such as different user roles, environment-specific behaviour, or state transitions.
118+
- Use contract tests where toggled behaviour affects external APIs or integrations to ensure they remain backward-compatible.
119+
- Avoid asserting on the presence or structure of toggle code itself, focus on testing expected outcomes.
112120

113121
This is particularly important for toggles that persist for more than one release cycle.
114122

115123
## Designing for failure
116124

117-
Feature toggles should never become a point of failure. Design your system so that it behaves predictably even if the toggle service is unavailable or fails to return a value.
125+
If you are using a feature toggle service external to the application, feature toggles should never become a point of failure. Design your system so that it behaves predictably even if the toggle service is unavailable or fails to return a value.
118126

119127
Best practices:
120128

@@ -123,12 +131,9 @@ Best practices:
123131
- Graceful degradation: Systems should still function, possibly with reduced capability, if a toggle cannot be resolved.
124132
- Resilient integration: Ensure that SDKs or services used for toggling are resilient and do not block application startup or core functionality.
125133

126-
## Comments
127-
128134
## Further reading
129135

130-
- [Feature Toggles by Martin Fowler](https://martinfowler.com/articles/feature-toggles.html)
131-
- [Unleash Strategies and Best Practices](https://docs.getunleash.io/topics/feature-flags/feature-flag-best-practices)
132-
- [Flagsmith Docs](https://docs.flagsmith.com/)
133-
- [Feature Flag Best Practices](https://launchdarkly.com/blog/best-practices-for-coding-with-feature-flags/)
134-
- [Thoughtworks Tech Radar](https://www.thoughtworks.com/radar/techniques/minimum-feature-toggle-solution)
136+
- [Feature Toggles (aka Feature Flags) by Martin Fowler](https://martinfowler.com/articles/feature-toggles.html)
137+
- [11 principles for building and scaling feature flag systems](https://docs.getunleash.io/topics/feature-flags/feature-flag-best-practices)
138+
- [Best practices for coding with feature flags](https://launchdarkly.com/blog/best-practices-for-coding-with-feature-flags/)
139+
- [An example tool for feature toggling](https://docs.flagsmith.com/)

0 commit comments

Comments
 (0)