软件开发团队发现只要他们集成的越频繁，生活就会越简单。同样的，他们发现发布到生产越快也会越有价值。但是团队并不想将半成品暴露给用户。处理这种紧张关系的一种有用的技术是构建所有后端代码，进行集成，但不构建用户界面。功能可以被集成和测试，但是UI会被保留到最后，直到它被添加来完成功能，并向用户展示它。
这种技术的一个简单示例可能是让客户选择紧急订单（加急）。这样的订单需要根据客户的居住地以及当地的快递公司来定价。所涉及的货物的性质会影响仓库中使用的拣选方法。某些客户可能有资格获得紧急订单，这也可能取决于交付地点、一年的时间和所订购的商品的种类。
总之，这是商业上的逻辑，特别是因为它将涉及到与各种仓库、目录和客户服务系统的复杂集成。完成这个功能的开发需要几周的时间，但是其他功能在几天之内就要发布。但是对于用户来说，急单只是订单表单上的一个复选框。
使用复选框最为keystone来构建这个，该团队在多个生产版本的过程中对内部系统的底层业务逻辑和接口进行开发工作。用户不知道所有这些潜在的代码。只有在最后一步，楔石复选框需要使可见，这可以在一个相对短的时间内完成。通过这种方式，所有潜在的代码都可以被集成，并成为进入生产环境的系统的一部分，从而减少长期存在的特性分支带来的问题。
潜在的代码如果在激活时也需要被测试。这个可以在系统最初建立时就完成，假设系统测试不依赖用户接口。 Unit Tests和更底层的 Test Pyramid很容易做到这点。甚至Broad Stack Tests也可以运行，假如有一个机制可以让他们Subcutaneous Tests。在一些场景中，在UI中有相当多的行为，但如果在设计上允许UI成为一个 Humble Object，这也可以被测试。
并不是所有的程序都可以采取这种方式测试，但是，即使没有使用keystone的能力，这样做所需要的努力也是值得的。即使使用最好的工具来自动化这个过程，使用UI来测试也是很麻烦的。迁移更多的测试到更底层，特别是unit test，会大幅度提升 Deployment Pipelines 和Continuous Delivery
的效率。
当然，大多数ui将不仅仅是一个复选框，尽管它们通常并不需要做太多工作。在一个web app，一个复杂的功能通常是一个独立的web页面，这可以完整的来构建和测试，而keystone只是一个链接。一个桌面可能有几个屏幕，而keystone是菜单项使他们可见。
即便如此，也有一些情况不能简单的直接将UI打包进keystone。当这样时，就是用 Feature Toggles的时候。然而，即使在这种情况下，考虑一个keystone也是有用的，因为它可以确保特性切换只适用于UI。这会减少开关的使用量和以及使用开关的复杂性，允许simple toggle mechanisms的使用，当时机成熟时，它更容易被移除。
最后开发UI也存在风险，后端代码可能设计的和UI在一起不工作，或者是UI直到最后才关注到它所需要的，导致缺乏迭代和糟糕的用户体验。由于这些原因，keystone方法在整体方法中工作得最好，这种方法鼓励通过薄的垂直切片构建产品，从而导致快速发布小型但完全可用的功能。
我已经使用过用户接口的例子，但是同样的方法也适用其他接口，比如一个API接口。通过最后构建用户的接口，保持简单，我们可以构建和集成一个很大的功能。
Dark Launching是新功能构建时不展现给用户，开发完成后才被调用的一个变种。这可以用来评估对后端系统的影响，有利于一些改变。当所有的事情都做好后，我们可以增加这个keystone。
