Feature flag: release without holding your breath

spinny:~/writing $ less openfeature-feature-flags-progressive-delivery.md

1 
2Deployment is when the code arrives in production. Release is when someone can actually use it. Confusing the two is one of the quickest ways to make every deployment a little tense moment.
3 
4The feature flag serve to put space between these two moments. You can deploy today, fire up tomorrow for the internal team, then for a pilot customer, then for 10% of users. If something goes wrong, turn off the flag. You don't necessarily have to rollback the entire release.
5 
6## The flag is not just an if
7 
8Technically it is often a `if`. Culturally it is much more.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18That little `if` can represent a gradual rollout, an experiment, a migration, an enterprise permit or an operational kill switch. The problem is that if you don't manage it well, it can also become technical debt that stays in the code for two years.
19 
20## Where does OpenFeature come in
21 
22OpenFeature is an open specification for evaluating feature flag with a common API. The idea is simple: your application code should not depend directly on the vendor or internal system you use for flags.
23 
24The app asks:
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34The provider decides where the rules come from: SaaS, file, internal service, flagd, GitOps configuration. If one day you change feature flagging backend, the application doesn't have to be rewritten everywhere.
35 
36This separation seems like an architectural detail, but it is felt as the project grows.
37 
38## Context is half the battle
39 
40An on or off flag for everyone is useful, but limited. Progressive delivery lives in context:
41 
42- internal or external user;
43- free or enterprise plan;
44- village;
45- organization;
46- app version;
47- stable percentage of traffic.
48 
49The important key is `targetingKey`: it must be stable. If it changes with every request, a user can end up once in variant A and once in variant B. For an experiment it's terrible, for a checkout it can be disastrous.
50 
51## A sensible rollout
52 
53A flow I like is this:
54 
551. deploy with flag off;
562. ignition for developers and QA;
573. switch-on for a pilot customer or tenant;
584. 5% rollout;
595. rollout at 25%;
606. 100% rollout;
617. removal of old code and flag.
62 
63The often forgotten point is the last one. A temporary flag must have a death date. If it stays forever, every future refactor will have to ask: "but is this branch still useful?".
64 
65## Kill switch: prepare them first
66 
67The kill switch is the flag that saves you when an external dependency starts messing with you, a job consumes too many resources, or new logic produces strange errors.
68 
69A good kill switch must be:
70 
71- easy to find;
72- documented in the runbook;
73- tested occasionally;
74- observable when activated;
75- independent, as far as possible, from the part that could break.
76 
77The worst thing is to discover during the accident that the flag exists, but no one knows if it still works.
78 
79## Observability or not progressive delivery
80 
81Turning on a feature at 10% without looking at metrics is just optimism with multiple steps.
82 
83Each rollout should answer simple questions:
84 
85- have errors increased?
86- has the latency changed?
87- do users complete the flow?
88- are there more tickets or retries?
89- does a variant impact only one segment?
90 
91OpenFeature supports hooks around flag evaluation. They are useful for logging errors, adding metrics or linking the rating to a trace.
92 
93## Naming and ownership
94 
95Names matter. `new_ui` says nothing. `checkout.v2.enabled` says much more.
96 
97For each flag I would mark at least:
98 
99- name;
100- description;
101- owner;
102- safe default;
103- reason why it exists;
104- date or condition of removal.
105 
106An ownerless flag is almost always a flag that no one will clear.
107 
108## Where to evaluate them
109 
110Frontend, backend or edge? Depends.
111 
112If the flag is for layout, copy, or onboarding, the frontend is fine. If it concerns permissions, billing, limits or sensitive data, it must be on the backend. If it involves routing or high-traffic experiments, the edge may make sense.
113 
114The simple rule: the frontend can improve the experience, but it shouldn't be the only security barrier.
115 
116## Conclusion
117 
118The feature flag done well change the relationship with production. They don't eliminate the risk, but they make it smaller and more manageable. You can release in slices, observe, stop, go back, learn.
119 
120OpenFeature adds a clean foundation: a common API, interchangeable providers, and a tidier way to grow the system. But the discipline remains yours: safe defaults, clear names, metrics, owners and cleanliness.
121 
122The best flag is the one that helps you release calmly and then disappears when it is no longer needed.
123 
124## Sources
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131

:Feature flag: release without holding your breathlines 1-131 (END) — press q to close

2Deployment is when the code arrives in production. Release is when someone can actually use it. Confusing the two is one of the quickest ways to make every deployment a little tense moment.

4The feature flag serve to put space between these two moments. You can deploy today, fire up tomorrow for the internal team, then for a pilot customer, then for 10% of users. If something goes wrong, turn off the flag. You don't necessarily have to rollback the entire release.

6## The flag is not just an if

8Technically it is often a `if`. Culturally it is much more.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18That little `if` can represent a gradual rollout, an experiment, a migration, an enterprise permit or an operational kill switch. The problem is that if you don't manage it well, it can also become technical debt that stays in the code for two years.

20## Where does OpenFeature come in

22OpenFeature is an open specification for evaluating feature flag with a common API. The idea is simple: your application code should not depend directly on the vendor or internal system you use for flags.

24The app asks:

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

34The provider decides where the rules come from: SaaS, file, internal service, flagd, GitOps configuration. If one day you change feature flagging backend, the application doesn't have to be rewritten everywhere.

36This separation seems like an architectural detail, but it is felt as the project grows.

38## Context is half the battle

40An on or off flag for everyone is useful, but limited. Progressive delivery lives in context:

42- internal or external user;

43- free or enterprise plan;

44- village;

45- organization;

46- app version;

47- stable percentage of traffic.

49The important key is `targetingKey`: it must be stable. If it changes with every request, a user can end up once in variant A and once in variant B. For an experiment it's terrible, for a checkout it can be disastrous.

51## A sensible rollout

53A flow I like is this:

551. deploy with flag off;

562. ignition for developers and QA;

573. switch-on for a pilot customer or tenant;

584. 5% rollout;

595. rollout at 25%;

606. 100% rollout;

617. removal of old code and flag.

63The often forgotten point is the last one. A temporary flag must have a death date. If it stays forever, every future refactor will have to ask: "but is this branch still useful?".

65## Kill switch: prepare them first

67The kill switch is the flag that saves you when an external dependency starts messing with you, a job consumes too many resources, or new logic produces strange errors.

69A good kill switch must be:

71- easy to find;

72- documented in the runbook;

73- tested occasionally;

74- observable when activated;

75- independent, as far as possible, from the part that could break.

77The worst thing is to discover during the accident that the flag exists, but no one knows if it still works.

79## Observability or not progressive delivery

81Turning on a feature at 10% without looking at metrics is just optimism with multiple steps.

83Each rollout should answer simple questions:

85- have errors increased?

86- has the latency changed?

87- do users complete the flow?

88- are there more tickets or retries?

89- does a variant impact only one segment?

91OpenFeature supports hooks around flag evaluation. They are useful for logging errors, adding metrics or linking the rating to a trace.

93## Naming and ownership

95Names matter. `new_ui` says nothing. `checkout.v2.enabled` says much more.

97For each flag I would mark at least:

99- name;

100- description;

101- owner;

102- safe default;

103- reason why it exists;

104- date or condition of removal.

105

106An ownerless flag is almost always a flag that no one will clear.

107

108## Where to evaluate them

109

110Frontend, backend or edge? Depends.

111

112If the flag is for layout, copy, or onboarding, the frontend is fine. If it concerns permissions, billing, limits or sensitive data, it must be on the backend. If it involves routing or high-traffic experiments, the edge may make sense.

113

114The simple rule: the frontend can improve the experience, but it shouldn't be the only security barrier.

115

116## Conclusion

117

118The feature flag done well change the relationship with production. They don't eliminate the risk, but they make it smaller and more manageable. You can release in slices, observe, stop, go back, learn.

119

120OpenFeature adds a clean foundation: a common API, interchangeable providers, and a tidier way to grow the system. But the discipline remains yours: safe defaults, clear names, metrics, owners and cleanliness.

121

122The best flag is the one that helps you release calmly and then disappears when it is no longer needed.

123

124## Sources

125

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131