持续交付是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。

版本管理即一个软件服务、系统、功能模块随着客户需求反馈的增多、技术的革新，会在不同时间出现不同的版本，而这些版本都需要管理。

目前 DevOps 中的 CICD 流水线能力使交付变的更加的顺畅，而 Git 的代码版本管理平台也版本管理更简单。但只用这两类技术还无法实现真正的持续交付与版本管理。而 Feature flags 则是在这方面可以很好的解决一些困局。

困局

传统的CICD流水线只能让产品更好的被打包并部署到计算资源中，这个过程虽然降低了部署的复杂度，提高了部署的时间和安全性，但是他对业务侧没有实际性的影响。而使用Git的软件版本管理虽然让管理更加的人性化，降低了一些技术门槛，但同时还只能对一个大的版本进行控制。多个版本的交付需要保留多个分支和相应的硬件资源。

而正是上面的这两个技术的困局，使软件工程仍然无法很好的去辅助"持续交付"、"精益创业"的业务增长。思考以下几个方面与营收相关的场景，现有的技术确实难解决：

1. 不同的客户需要不同的功能模块的不同版本，当组合变多且多个业务人员在向外按需销售、展示、签单时，几乎都需要技术人员的参与。不仅让公司的人员成本提升，也无法快速的反应市场需求。且产品的迭代往往需要兼顾不同的版本，对整个研发的管理和运维的困难也很高。

2. 对于需要依靠"持续交付"和"精益创业"思想去寻找第N条增长曲线破局的企业，需要为多个赢利点做实验性功能研发和试用。即需要在千人千面的版本管理局面下，随时将某个版本交付给对应的客户，并让业务人员可以进行实验性市场拓展。

如上图所示，总结起来就是当前的技术手段无法去很好的支持"处于实验阶段"的技术研发与产品运营的"精益创业"工作流。

敏捷开关的方案

如上图所示，解决困局需要持续的允许多个实验的存在，而敏捷开关首先则提供了一个很好的 feature flags 技术实现与管理平台，帮助企业可以从研发到运营团队整体实现持续的精益创业。

1. 通过 Feature flag 技术使产品的交付从大版本解耦为"实验"，使有能力让交付的时间和版本的管理都基于这个实验，脱离整个项目。

2. 让技术与非技术人员都可以无跨度的参与其中，业务团队可以根据自己的策略和产品情况去交付和控制产品给对应的客户群体。

敏捷开关有一个客户，他们在寻找第2条增长曲线，在主服务中尝试添加各种新的数据化服务帮助客户创收。其中有一个"城市购买力热力分布图"模块，有几个问题：

1. 这是一个在整体服务中的独立功能模块，但需要在整体产品服务中被使用（而不是一个独立的品牌、独立的SaaS服务）。

2. 此模块的功能更新、迭代都需要相对独立。在实验期间不同的客户会有小的不同反馈，需要做小范围的千人千面的需求适配。

3. 业务人员需要独立的给客户进行功能的交付与版本的控制，并根据线上数据和线下沟通的反馈，去找到营收点。

当企业的产品拥有 "功能开关+ 灰度发布 + 远程配置 + ab测试 + 版本控制 + 持续交付 + 订阅管理 + 等等" 能力并融为一体时，为解决上面的问题提供了基础。当可以将这些能力和赋予这些能力的 feature flags 很高的管理，允许团队更轻松的进行整体协同时，困局就有了很好的解决方案。从更好的助力企业的"持续创新"、"精益创业"。