Feature flag：无需屏住呼吸即可释放

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

1~
2部署是指代码到达生产环境时。发布是指有人可以真正使用它。混淆两者是让每次部署都变得有点紧张的最快方法之一。
3~
4feature flag 用于在这两个时刻之间留出空间。您可以今天进行部署，明天为内部团队启动，然后为试点客户，然后为 10% 的用户启动。如果出现问题，请关闭该标志。您不一定需要回滚整个版本。
5~
6## 标志不仅仅是一个 if
7~
8从技术上讲，它通常是 `if`。从文化角度来说，它的意义远不止于此。
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18这个小小的`if`可以代表逐步推出、实验、迁移、企业许可或运营kill switch。问题是，如果管理不好，它也可能成为技术债务，在代码中保留两年。
19~
20## OpenFeature 是从哪里来的
21~
22OpenFeature 是一个开放规范，用于评估 feature flag 和通用 API。这个想法很简单：您的应用程序代码不应直接依赖于您用于标志的供应商或内部系统。
23~
24该应用程序询问：
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~
34提供商决定规则的来源：SaaS、文件、内部服务、flagd、GitOps 配置。如果有一天您更改了功能标记后端，则不必到处重写应用程序。
35~
36这种分离看起来像是一个建筑细节，但随着项目的发展，它会被感觉到。
37~
38## 上下文是成功的一半
39~
40开或关标志对每个人来说都是有用的，但有限。渐进式交付存在于上下文中：
41~
42- 内部或外部用户；
43- 免费或企业计划；
44- 村庄;
45- 组织;
46- 应用程序版本；
47- 稳定的流量百分比。
48~
49重要的关键是`targetingKey`：必须稳定。如果它随着每个请求而变化，用户可能会在变体 A 中一次，在变体 B 中一次。对于实验来说，这很糟糕，对于结账来说，这可能是灾难性的。
50~
51## 明智的推出
52~
53我喜欢的流程是这样的：
54~
551. 挂旗部署；
562. 开发人员和QA的点火；
573. 为试点客户或租户开启；
584. 5%推出；
595. 推出25%；
606. 100%上线；
617.删除旧代码和标志。
62~
63经常被遗忘的一点是最后一点。临时旗帜必须有死亡日期。如果它永远保留，未来的每次重构都必须问：“但是这个分支仍然有用吗？”。
64~
65## Kill switch：先准备好
66~
67当外部依赖项开始困扰您、作业消耗太多资源或新逻辑产生奇怪的错误时，kill switch 是可以拯救您的标志。
68~
69一个好的kill switch必须是：
70~
71- 容易找到；
72- 记录在运行手册中；
73- 偶尔进行测试；
74- 激活时可观察到；
75- 尽可能独立于可能损坏的部分。
76~
77最糟糕的是在事故中发现旗帜存在，但没有人知道它是否仍然有效。
78~
79## 可观察性或非渐进式交付
80~
81在不考虑指标的情况下以 10% 的速度启用某个功能只是采取多个步骤的乐观态度。
82~
83每次推出都应该回答简单的问题：
84~
85- 错误增加了吗？
86- 延迟有变化吗？
87- 用户是否完成了流程？
88- 还有更多票或重试吗？
89- 变体是否仅影响一个部分？
90~
91OpenFeature 支持围绕标志评估的钩子。它们对于记录错误、添加指标或将评级链接到trace很有用。
92~
93## 命名和所有权
94~
95名字很重要。 `new_ui`什么也没说。 `checkout.v2.enabled` 说得更多。
96~
97对于每个标志，我至少会标记：
98~
99- 姓名；
100- 描述;
101- 所有者;
102- 安全默认；
103- 它存在的原因；
104- 移除日期或条件。
105~
106无主旗帜几乎总是无人会清除的旗帜。
107~
108## 在哪里评估它们
109~
110前端、后端还是边缘？视情况而定。
111~
112如果该标志用于布局、复制或入门，则前端就可以了。如果涉及权限、计费、限制或敏感数据，则必须位于后端。如果涉及路由或高流量实验，边缘可能有意义。
113~
114简单的规则：前端可以改善体验，但它不应该是唯一的安全屏障。
115~
116## 结论
117~
118feature flag做得好改变了与生产的关系。它们并不能消除风险，但可以使风险更小、更易于管理。你可以分段释放、观察、停下来、返回、学习。
119~
120OpenFeature 添加了一个干净的基础：通用的 API、可互换的提供程序以及更简洁的系统扩展方式。但纪律仍然是你的：安全的默认值、清晰的名称、指标、所有者和清洁度。
121~
122最好的标志是能够帮助您平静地释放，然后在不再需要时消失的标志。
123~
124## 来源
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

2部署是指代码到达生产环境时。发布是指有人可以真正使用它。混淆两者是让每次部署都变得有点紧张的最快方法之一。

4feature flag 用于在这两个时刻之间留出空间。您可以今天进行部署，明天为内部团队启动，然后为试点客户，然后为 10% 的用户启动。如果出现问题，请关闭该标志。您不一定需要回滚整个版本。

6## 标志不仅仅是一个 if

8从技术上讲，它通常是 `if`。从文化角度来说，它的意义远不止于此。

10```typescript

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

12 return newCheckout(input);

13}

14~

15return oldCheckout(input);

16```

17~

18这个小小的`if`可以代表逐步推出、实验、迁移、企业许可或运营kill switch。问题是，如果管理不好，它也可能成为技术债务，在代码中保留两年。

19~

20## OpenFeature 是从哪里来的

21~

22OpenFeature 是一个开放规范，用于评估 feature flag 和通用 API。这个想法很简单：您的应用程序代码不应直接依赖于您用于标志的供应商或内部系统。

23~

24该应用程序询问：

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~

34提供商决定规则的来源：SaaS、文件、内部服务、flagd、GitOps 配置。如果有一天您更改了功能标记后端，则不必到处重写应用程序。

35~

36这种分离看起来像是一个建筑细节，但随着项目的发展，它会被感觉到。

37~

38## 上下文是成功的一半

39~

40开或关标志对每个人来说都是有用的，但有限。渐进式交付存在于上下文中：

41~

42- 内部或外部用户；

43- 免费或企业计划；

44- 村庄;

45- 组织;

46- 应用程序版本；

47- 稳定的流量百分比。

48~

49重要的关键是`targetingKey`：必须稳定。如果它随着每个请求而变化，用户可能会在变体 A 中一次，在变体 B 中一次。对于实验来说，这很糟糕，对于结账来说，这可能是灾难性的。

50~

51## 明智的推出

52~

53我喜欢的流程是这样的：

54~

551. 挂旗部署；

562. 开发人员和QA的点火；

573. 为试点客户或租户开启；

584. 5%推出；

595. 推出25%；

606. 100%上线；

617.删除旧代码和标志。

62~

63经常被遗忘的一点是最后一点。临时旗帜必须有死亡日期。如果它永远保留，未来的每次重构都必须问：“但是这个分支仍然有用吗？”。

64~

65## Kill switch：先准备好

66~

67当外部依赖项开始困扰您、作业消耗太多资源或新逻辑产生奇怪的错误时，kill switch 是可以拯救您的标志。

68~

69一个好的kill switch必须是：

70~

71- 容易找到；

72- 记录在运行手册中；

73- 偶尔进行测试；

74- 激活时可观察到；

75- 尽可能独立于可能损坏的部分。

76~

77最糟糕的是在事故中发现旗帜存在，但没有人知道它是否仍然有效。

78~

79## 可观察性或非渐进式交付

80~

81在不考虑指标的情况下以 10% 的速度启用某个功能只是采取多个步骤的乐观态度。

82~

83每次推出都应该回答简单的问题：

84~

85- 错误增加了吗？

86- 延迟有变化吗？

87- 用户是否完成了流程？

88- 还有更多票或重试吗？

89- 变体是否仅影响一个部分？

90~

91OpenFeature 支持围绕标志评估的钩子。它们对于记录错误、添加指标或将评级链接到trace很有用。

92~

93## 命名和所有权

94~

95名字很重要。 `new_ui`什么也没说。 `checkout.v2.enabled` 说得更多。

96~

97对于每个标志，我至少会标记：

98~

99- 姓名；

100- 描述;

101- 所有者;

102- 安全默认；

103- 它存在的原因；

104- 移除日期或条件。

105~

106无主旗帜几乎总是无人会清除的旗帜。

107~

108## 在哪里评估它们

109~

110前端、后端还是边缘？视情况而定。

111~

112如果该标志用于布局、复制或入门，则前端就可以了。如果涉及权限、计费、限制或敏感数据，则必须位于后端。如果涉及路由或高流量实验，边缘可能有意义。

113~

114简单的规则：前端可以改善体验，但它不应该是唯一的安全屏障。

115~

116## 结论

117~

118feature flag做得好改变了与生产的关系。它们并不能消除风险，但可以使风险更小、更易于管理。你可以分段释放、观察、停下来、返回、学习。

119~

120OpenFeature 添加了一个干净的基础：通用的 API、可互换的提供程序以及更简洁的系统扩展方式。但纪律仍然是你的：安全的默认值、清晰的名称、指标、所有者和清洁度。

121~

122最好的标志是能够帮助您平静地释放，然后在不再需要时消失的标志。

123~

124## 来源

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~