deployment - 如何为您的用户实施有限的功能推出（与语言无关）？

Question

我想知道向选定的用户群推出新网站功能的一些常见或最佳实践。

例如，用户可能仅基于您的整体用户群的百分比 (10%)。部署应该是可定制的（可配置的）并支持任意数量的功能。将推出与特定用户角色或权限 (ACL) 相关联也很有用。

那么，从本质上讲，什么是可以合理扩展的架构？

至于与语言无关的部分，您可以提供伪代码、一般概念或想法，或者您喜欢的语言的片段来表达您的观点。

欢迎提供任何示例或教程的链接。

Answer 1

我的建议是，对于获得新功能的人来说，他们所在的网站应该尽可能靠近该功能公开后每个人都会访问的网站。

换句话说，例如，如果该条件仅在此 beta 期间存在，我将不会在页面上使用条件逻辑来确定按钮是否应该可见。相反，我会在登录时确定此人是否是 beta 参与者（该确定可能是随机的，可能参考他们的角色等）。如果他们是参与者，他们将被重定向到从版本控制分支部署的单独部署的站点。

部署完成后，分支将被合并，每个人都可以看到新功能。

这样，您不必担心公共测试版用户看到的代码库与最终发布的代码库不同（在某种程度上可能会破坏某些东西）。

Answer 2

在我的上一份工作中，我们使用负载均衡器和当前修订 cookie 完成了这项工作。

负载均衡器设置了一个 cookie，用于标识用户正在使用的实例的修订号。如果该 cookie 已经存在，负载均衡器只会将该请求发送到具有相应修订的正在运行的实例。当我们部署一个新的修订版时，负载均衡器继续使用现有的修订版 cookie 将流量发送到其原始修订版，直到该修订版不再运行或用户关闭其浏览器。新流量将被发送到新部署的修订版。这使我们能够在现有用户继续在旧版本上运行时测试一下更改。我们还可以手动设置该 cookie 以在生产环境内部测试新的 rev，然后再将新流量转移到它上面。

但是，该设置不支持向后不兼容的数据库更改。几乎没有办法做到这一点，您可以让一部分用户在一个数据库架构上，而在另一个数据库架构上，并且能够对两者进行写入，然后在您确定新版本没问题后以某种方式将这些写入合并在一起. 我的意思是，这是可能的，但这实际上取决于架构更改的确切内容以及它们如何影响您的应用程序，因此您无法在部署时以可靠、不可知的方式进行操作。对我们来说，我们通常只是尽量不做向后不兼容的模式更改。如果我们确实需要，我们会尝试将破坏性部分（删除列或表）推迟到以后的版本，在那里我们可以迁移模式并让两个版本都运行，而不会对当前用户产生不利影响。

Answer 3

对于随机选择过程，我喜欢在成功登录时询问每个客户是否想参与 beta 测试的概念，一旦达到所需或想要的用户总数，您就停止询问。在数据库中，我倾向于存储将用户重定向到的服务器，并运行一个标准脚本，在登录时将每个用户移动到正确的位置。

我们提前几个月设计我们的应用程序开发，并避免更改现有架构。原因很明显，当然这并不总是可行的，所以当我们有这样的更改时，我们总是在编写更改时完整记录更改并尽早计划该字段的迁移。这样，我们就有了一个正在做出哪些改变的战斗计划，我们可以为我们制定出最好的解决方案。不幸的是，这会根据情况发生变化。

我们总是运行多个环境，我们通常有生产、开发和测试版。这意味着我们 1 不会乱用等值钱的生产服务，我们不会有人破坏代码并在优化时将服务拉下线。

开发使用 GIT 进行版本监控，用户永远不会看到这一点，因为我们上传了各种奇怪而精彩的实验来玩。它还使用自己的数据库与实时数据。

使用测试版，我们通常会迁移特定的用户数据，但最近我们在复制整个数据库和计划测试版开始的特定日期方面有了更好的体验，这样做是允许用户选择退出测试版，而其他人可以选择加入支持此选项所需的更改最少。我们通常做的是每天在两个数据库之间迁移一次新数据，新的选择加入和选择退出仅在数据迁移到另一个平台时生效。

我们还使用现有的生产数据库进行了小规模的成功测试，测试了一些在自己的表之外运行的新功能，因此根据您正在做的数据明智地使用相同的实时数据库可能是一个不错的选择。

我希望这对你有用......祝你的测试伙伴好运。

Answer 4

谷歌网站优化器似乎正是您正在寻找的。