我们希望为工程师建立一个简单的机制，将实验代码和功能投入到我们的应用程序中，以便为一小部分用户尝试新事物，对不同的应用程序行为进行 A/B 测试，并且通常提供沙盒开发人员可以在不影响主要生产代码的情况下发疯的环境。我们对实验功能 (EF) 的一些要求是：
- 对于熟悉 Rails、JS/Coffee 和我们的应用程序的任何人来说，添加 EF 应该非常简单
- EF 代码应尽可能位于生产代码之外（“在岛上”）。
- EF 代码不应在生产代码中长出有害的触角，即尽可能保持松散耦合。
- 乍一看应该清楚什么是 EF 代码，什么不是。
- EF 代码不必支持 TDD、UX 等完整的组织策略。事实上，快速而肮脏的实验是这样做的目标，我们不希望创造力和热情受到流程和策略的阻碍。只有一个实验被认为是成功的（通过用户测试），我们是否要花精力把它带到所有的政策中。
- EF 功能可以在仪表板站点上打开/关闭，并且可以推广到特定用户。
- 从事生产代码的开发人员不应该以任何方式处理实验性代码——理想情况下是完全分离。如果更新生产代码，实验可能会中断，这比强制生产代码开发人员保持所有实验更新更可取。让实验继续进行取决于实验者。
- 我们的系统建立在 Rails 的服务器上，并有一个丰富的客户端应用程序，用 CoffeeScript 和 Knockout.js 和 Backbone.js 编写。EF 可能涉及 Rails 代码（控制器操作、路由、模型）、视图模板、CoffeeScript 代码（数据绑定、jQuery 模板、模型和视图模型等）、CSS/SCSS，并且该机制应该允许所有这些都被沙箱化。
目前，我们不太关心拆分测试或多变量测试的测量过程，这是使用 Vanity gem 等工具或 KissMetrics 和 MixPanel 等商业解决方案解决的问题。我们更关心如何创建解决分离、合并和维护问题的设置。Rails 有这样的工具吗？