一、什么是 Keystone ？
对软件研制团队来说，越是频频地集成他们的代码，工作就越轻松。同时，越频频发布功用迭代，产品就越有价值。但是团队并不想把开发了一半的功用暴露给用户。对这种矛盾的一个有用的处理机制便是先构建一切的后端代码，集成到产品，但不供给用户界面。这个功用能够在用户端无感知的状况下被集成和测验，直到悉数完结上线后，再将这个功用展现给用户。就像是 Keystone（拱顶石，建筑学术语，通常引申为保证其他部件就位的核心关键点）。
二、限时特价促销活动
举一个简略的比方，比方说给用户推送一个限时特价产品。这样的订单一般都需求依据用户方位、配送状况等信息确定价格。所以依据用户方位、时刻、产品类型等因素，决议了用户是否会收到这种限时特价产品的推送信息。
总而言之，这是一个很杂乱的电商运作逻辑，由于需求涉及仓储量、产品目录、客户服务等多个体系的协同。完结这样一个流程的开发，或许需求几周的的时刻，同时，另一些功用或许需求每隔几天就发布一次。而对客户而言，特价产品推送仅仅订单表格上的一个挑选框。
在这个项目中，能够让挑选框作为 Keystone。研制团队能够跨多个产品发布周期进行内部体系的业务逻辑和接口开发。用户感知不到这些代码改动。最后一步是让用户看到这个特价推送的挑选框 UI 界面，通常这用不了多少开发时刻。这种形式下，一切中间代码都能够参加集成，并随着产品发布周期布置在线上，这样就避免了长时刻运用 feature branch（特性分支——一种分支管理形式）带来的危险。
三、中间代码和UI界面的测验方法
中间代码需求像线上代码相同接受严格的测验。这需求体系（测验）分层建立，而不是一切测验都依赖于用户页面的触发。单元测验和 Test Pyramid（测验金字塔）中的低层测验都应当能够正常履行。乃至 Broad Stack Test 都能够正常履行，只要供给必定的机制使它们成为 Subcutaneous Tests。某些状况下，UI 层自身包含了杂乱的行为，不过只要规划得当，UI 也能够经过进入 Humble Object 的方法得到测验。
并非一切运用程序的构建方法都支撑这种大覆盖面的”皮下”测验，但即使无法运用 Keystone 形式，这种规划准则也是有价值的。即运用最好的工具去自动化这一过程，从 UI 层触发的测验也总是很难建立的。将更多的测验转移到界面层以下各层级，特别是单元测验层，能够显著提升布置流水线的速度，完成持续交付。
当然，大多数的 UI 改变会比添加一个挑选框杂乱，即使如此，运用 Keystone形式也并不会添加太多工作量。在 Web 运用中，一个杂乱的功用通常都是一个独立页面，能够作为一个全体构建和测验。这种场景下，Keystone 便是一个链接。桌面运用或许规划多个界面改变，这种状况下，Keystone 能够是一个能展现这些界面的菜单项。
尽管如此，确实存在一些场景用户界面不能被简略地打包经过一个 Keystone 操控。这时候就需求用到功用开关了。即使在这种状况下，Keystone 的概念也能够协助我们将功用开关的完成限定在UI层操控上。这样能够避免开关四处散落在后端代码中，降低了开关运用的杂乱性，更好地遵循单开关机制，也为后续的开关清理降低了难度。
四、总结
后端先行，最后再开发 UI 界面的方法也存在一个潜在的危险，便是后端代码的规划或许无法与后开发的UI协调一致，或者在后期UI完成时才发现规划点遗漏，这会导致反应延迟并带来糟糕的用户体会。因此，只要在产品上支撑功用垂直划分，研制上能够按功用粒度快速发布的团队中，Keystone 形式才能够发挥最大的价值。
在这里我仅仅举例了一个用户界面的小比方，但同样的方法适用于任何界面改变，例如 API。经过最后再供给用户界面，并且保持简练的方法，即使是很大的功用晋级，我们也能够经过逐个部分增量构建、集成来完结。
在 FeatureProbe 就能够完成 Keystone 形式，做到后端代码与UI 界面分隔布置测验。研制团队能够先开发后端代码布置，用户侧无感知这一块功用核心功用已经布置到体系上了，保证新功用后端代码没有问题后，在 FeatureProbe 后台操作页面，能够一键敞开 UI 界面功用，测验 UI 界面功用没有问题后，再将这个新功用开放给用户。
目前 FeatureProbe 运用 Apache 2.0 License 协议已经彻底开源。你能够从 GitHub 或 Gitee 获取到一切源码。
与此同时，我们供给了无需布置的在线试用环境和一个仅需5分钟即可体会的示例项目。
