如何为用户实现有限的功能部署(语言不可知)？

Question

我想了解一些将新网站功能推广到用户群的选定组的常见或最佳实践.

例如,用户可能仅基于总体用户群的百分比(10%).部署应该是可自定义的(可配置的)并支持任意数量的功能.将转出关联到特定用户角色或特权(ACL)也很有用.

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

至于语言不可知部分,您可以提供伪代码,一般概念或想法,或者使用您首选语言的片段来表达您的观点.

欢迎链接到任何示例或教程.

Answer 1

我的建议是,对于获得新功能的人来说,他们所在的网站应该尽可能接近每个人在公共功能上出现的网站.

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

推出完成后,分支将合并到每个人都看到新功能.

这样,您不必担心公共测试用户看到的代码库与最终版本代码库有所不同(在某种程度上可能会破坏某些内容).

Answer 2

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

负载均衡器设置一个cookie,用于标识用户正在使用的实例的修订号.如果该cookie已存在,则负载均衡器将仅将该请求发送到具有相应修订的正在运行的实例.当我们部署新版本时,负载均衡器继续将带有现有修订cookie的流量发送到其原始修订版,直到该修订版不再运行或用户关闭其浏览器.新流量将被发送到新部署的修订版.这使我们能够在现有用户继续运行旧版本的同时测试一些变化.我们还可以手动设置该cookie以在生产环境内部测试新的rev,然后再将新流量转移到其上.当我们感到舒服的是,新版本没有重大问题时我们可以删除旧版本,所有流量都将开始进入最新版本.

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