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