例如，用户可能仅基于总体用户群的百分比（10％）。部署应该是可自定义的（可配置的）并支持任意数量的功能。将转出关联到特定用户角色或特权（ACL）也很有用。
因此，从本质上讲，什么是可以合理扩展的架构？
对于与语言无关的部分，您可以提供伪代码，一般概念或想法，或者使用您首选语言的摘要来表达您的观点。
欢迎链接到任何示例或教程。
答案 0 :(得分：9)
我的建议是，对于获得新功能的人来说，他们所在的网站应尽可能接近每个人在公开此功能后所使用的网站。
换句话说，例如，我不会在页面上使用条件逻辑来确定按钮是否应该可见，如果该条件仅在此测试期间存在。相反，我会在登录时确定此人是否是测试版参与者（该决定可能是随机的，可能会引用他们的角色等）。如果他们是参与者，他们将被重定向到从版本控制分支部署的单独部署的站点。
推出完成后，分支将合并，每个人都会看到新功能。
通过这种方式，您不必担心公共测试用户看到的代码库与最终版本代码库的不同（在某种程度上可能会破坏某些内容）。
答案 1 :(得分：5)
在我上一份工作中，我们使用负载均衡器和当前的修订cookie完成了这项工作。
负载均衡器设置一个cookie，用于标识用户正在使用的实例的修订号。如果该cookie已存在，则负载均衡器将仅将该请求发送到具有相应修订的正在运行的实例。当我们部署新版本时，负载均衡器继续将带有现有修订cookie的流量发送到其原始修订版，直到该修订版不再运行或用户关闭其浏览器。新流量将被发送到新部署的修订版。这使我们能够在现有用户继续运行旧版本的同时测试一些变化。我们还可以手动设置该cookie以在生产环境内部测试新的rev，然后再将新流量转换到它上面。当我们对新版本没有重大问题感到满意时，我们可以删除旧版本，所有流量都将开始进行最新修订。
但该设置不支持向后不兼容的数据库更改。几乎没有办法做到这一点，你可以让你的部分用户在一个数据库架构上，而在另一个数据库架构上，并且能够对两者进行写入，然后以某种方式将这些写入合并在你确定新的转速是正常的。我的意思是，这是可能的，但它实际上取决于架构更改的确切内容以及它们如何影响您的应用程序，因此您无法在部署时以可靠，不可知的方式执行此操作。对我们来说，我们通常只是尝试不进行向后不兼容的架构更改。如果我们真的需要，我们会尝试将破坏性部分（删除列或表）推迟到以后的版本，我们可以迁移模式并运行两个版本，对当前用户没有任何负面影响。
答案 2 :(得分：1)
对于随机选择过程，我喜欢在每个客户成功登录时询问每个客户是否想要参与beta测试的概念，一旦达到所需的或所需的用户数量，您就会停止询问。在数据库中，我倾向于存储将用户重定向到哪个服务器并运行标准脚本，该脚本在登录时将每个用户移动到正确的位置。
我们提前几个月设计我们的应用开发并避免更改现有架构。原因很明显，当然这并不总是可行的，因此当我们进行这样的更改时，我们总是在编写时完全记录更改，并尽早计划此字段的迁移。通过这种方式，我们制定了正在进行变革的战斗计划，并且我们可以为我们提供最佳解决方案。不幸的是，这取决于具体情况。
我们总是运行多个环境，我们一般都有生产，开发和测试版。这意味着我们不会混淆同等资金的生产服务，我们没有人破解代码并在优化时将服务拉下线。
开发使用GIT进行版本监控，用户从未看到过这种情况，因为我们上传了各种奇怪而精彩的实验。它还使用自己的数据库和实时数据。
通过测试版，我们一般会迁移特定的用户数据，但最近我们在复制整个数据库和规划测试开始的具体日期方面有了更好的体验，这样做可以让用户选择退出测试版和其他用户选择支持此选项所需的最小更改。我们通常做的是每天在两个数据库之间迁移一次新数据，新的选择加入和退出仅在数据迁移到另一个平台时生效。
我们还使用现有的生产数据库进行了小规模的成功测试，测试了一些在自己的表中运行的新功能，因此根据您使用相同的实时数据库进行数据操作可能是一个不错的选择。
我希望这对你有用...祝你的测试伙伴好运。
答案 3 :(得分：0)
Google网站优化工具似乎正是您所寻找的。