Skip to content

Commit fc9e2c1

Browse files
stefaniukLeeGathercole
authored andcommitted
Add the intent section
1 parent 0798eb9 commit fc9e2c1

File tree

1 file changed

+15
-10
lines changed

1 file changed

+15
-10
lines changed

practices/feature-toggling.md

Lines changed: 15 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -2,10 +2,11 @@
22

33
- [Feature Toggling](#feature-toggling)
44
- [Context](#context)
5-
- [In summary](#in-summary)
5+
- [The intent](#the-intent)
6+
- [Key takeaway](#key-takeaway)
67
- [Background](#background)
78
- [What is feature toggling?](#what-is-feature-toggling)
8-
- [Why use feature toggles?](#why-use-feature-toggles)
9+
- [Why use feature toggling?](#why-use-feature-toggling)
910
- [Types of toggles](#types-of-toggles)
1011
- [Managing toggles](#managing-toggles)
1112
- [Toggling strategy](#toggling-strategy)
@@ -20,7 +21,11 @@
2021
- These notes are part of our broader [engineering principles](../principles.md).
2122
- Feature toggling contributes to safer delivery, reduced deployment risk, and enhanced responsiveness to change.
2223

23-
## In summary
24+
## The intent
25+
26+
We use feature toggling as a key enabling practice to support our move towards daily code integration and deployment, including multiple deployments per day. Feature toggling allows us to separate deployment from release, so that incomplete features can be merged and deployed without impacting end users. It enables incremental development by allowing small, frequent commits to `main`, and supports risk-managed rollouts by enabling functionality selectively. Importantly, it also provides a mechanism for rapid rollback without reverting code. This approach is critical to mitigating the risks associated with frequent deployments, and is foundational to achieving a safe and sustainable continuous delivery model.
27+
28+
## Key takeaway
2429

2530
- Feature toggling enables functionality to be turned on or off without deploying new code.
2631
- It separates deployment from release, allowing code to be safely deployed without activating a feature.
@@ -43,13 +48,13 @@ Feature toggling works by introducing conditional logic into the application cod
4348

4449
Toggles can be defined statically (e.g., environment variable or config file) or dynamically (e.g., via an external feature flag service). Dynamic toggles can be changed without restarting or redeploying the application.
4550

46-
## Why use feature toggles?
51+
## Why use feature toggling?
4752

4853
- **Decouple deployment from release**: Code can be deployed behind a toggle and activated later.
49-
- **Safe rollouts**: Enable features for specific users or teams to validate functionality before full rollout.
50-
- **Operational control**: Temporarily disable a feature causing issues without rollback.
51-
- **Experimentation**: Run A/B tests to determine user impact.
52-
- **Environment-specific behaviour**: Activate features in dev or test environments only.
54+
- **Enable safe rollouts**: Enable features for specific users or teams to validate functionality before full rollout.
55+
- **Support operational control**: Temporarily disable a feature causing issues without rollback.
56+
- **Enable experimentation**: Run A/B tests to determine user impact.
57+
- **Configure environment-specific behaviour**: Activate features in dev or test environments only.
5358

5459
## Types of toggles
5560

@@ -76,7 +81,7 @@ Poorly managed toggles can lead to complexity, bugs, and technical debt. Best pr
7681
Choose a feature flagging approach appropriate for the scale and complexity of your system:
7782

7883
- **Simple applications**: Environment variables or configuration files.
79-
- **Moderate scale and beyond**: Look to make use of [Flagsmith](https://www.flagsmith.com/), which support targeting, analytics, and team workflows.
84+
- **Moderate scale and beyond**: Look to make use of e.g. [Flagsmith](https://www.flagsmith.com/), which supports targeting, analytics, and team workflows.
8085

8186
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.
8287

@@ -115,7 +120,7 @@ Best practices:
115120
- Default values: Every toggle should have a known and safe default (either on or off) hardcoded in the consuming service.
116121
- Fail-safe logic: Ensure that remote flag checks have timeouts and fallback paths.
117122
- Graceful degradation: Systems should still function, possibly with reduced capability, if a toggle cannot be resolved.
118-
- Resilient integration: SDKs or services used for toggling should not block startup or core paths.
123+
- Resilient integration: Ensure that SDKs or services used for toggling are resilient and do not block application startup or core functionality.
119124

120125
## Further reading
121126

0 commit comments

Comments
 (0)