Feature flag: release without holding your breath

spinny:~/writing $ vim 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~

NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :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}

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~