【发布时间】：2012-03-21 23:20:58
【问题描述】：
我们希望建立一种简单的机制，让工程师可以将实验性代码和功能投入到我们的应用中，以便为一小部分用户尝试新事物，对不同的应用行为进行 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 工具吗？
【问题讨论】：
-
谢谢 Chloe，我不知道这个网站。
标签： ruby-on-rails-3.1 mvp multivariate-testing ab-testing