spinny:~/writing $ vim openfeature-feature-flags-progressive-delivery.md
1~2部署是指代码到达生产环境时。发布是指有人可以真正使用它。混淆两者是让每次部署都变得有点紧张的最快方法之一。3~4feature flag 用于在这两个时刻之间留出空间。您可以今天进行部署,明天为内部团队启动,然后为试点客户,然后为 10% 的用户启动。如果出现问题,请关闭该标志。您不一定需要回滚整个版本。5~6## 标志不仅仅是一个 if7~8从技术上讲,它通常是 `if`。从文化角度来说,它的意义远不止于此。9~10```typescript11if (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```typescript27const 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