如何向用户实施有限的功能推出（与语言无关）？
我想知道向选定的用户群推出新网站功能的一些常见或最佳实践。
例如，用户可以仅基于总体用户群的百分比 (10%)。部署应该是可定制的（可配置的）并支持任意数量的功能。将部署与特定用户角色或权限 (ACL) 相关联也很有用。
那么，从本质上讲，什么是能够很好地扩展的架构呢？
至于与语言无关的部分，您可以提供伪代码、一般概念或想法，或者您喜欢的语言的片段来表达您的观点。
欢迎提供任何示例或教程的链接。
I would like to know some common or best practices of rolling out a new website feature to a select group of the userbase.
The users could be, for example, based solely on a percentage of your overall user base (10%). The rollout should be customizable (configurable) and support any number of features. It would also be useful to associate rollouts to specific user roles or privileges (ACL).
So, in essence, what is an architecture that would scale reasonably well?
As for the language agnostic portion, you can either provide pseudo-code, general concepts or ideas, or snippets from your preferred language to get your point across.
Links to any examples or tutorials are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我的建议是，对于获得新功能的人来说，他们所在的网站应该尽可能接近该功能公开后每个人都会访问的网站。
换句话说，如果该条件仅在此测试期间存在，那么我就不会在页面上使用条件逻辑来确定按钮是否可见。相反，我会在登录时确定此人是否是测试版参与者（该确定可能是随机的，可能会参考他们的角色等）。如果他们是参与者，他们将被重定向到从版本控制分支部署的单独部署的站点。
部署完成后，分支将被合并，每个人都会看到新功能。
这样，您就不必担心公共测试版用户看到的代码库与最终发布的代码库不同（在某种程度上可能会破坏某些内容）。
My recommendation would be that, for the people who are getting the new feature, the site they are on should be as close as possible to the site that everyone will be on once the feature is public.
In other words, I wouldn't have, for example, conditional logic on a page to determine whether a button should be visible or not, if that condition would only exist during this beta period. Rather, I would determine at login time whether this person is a beta participant or not (that determination might be random, might reference their role, etc). If they are a participant, they would be redirected to a separately deployed site that is deployed from a version control branch.
Once the rollout is complete, the branch is merged in and everyone sees the new feature.
This way, you don't have to worry that the codebase the public beta users are seeing is different (in some way that could break something) from the eventual release codebase.
在我的上一份工作中，我们使用负载均衡器和当前修订版 cookie 来完成此任务。
负载均衡器设置一个 cookie，用于标识用户正在使用的实例的修订号。如果该 cookie 已经存在，负载均衡器只会将该请求发送到具有相应修订版本的正在运行的实例。当我们部署新的修订版时，负载均衡器继续将带有现有修订版 cookie 的流量发送到其原始修订版，直到该修订版不再运行或用户关闭浏览器。新流量将被发送到新部署的修订版。这使我们能够在现有用户继续使用旧版本的同时测试一些更改。我们还可以手动设置该 cookie，以便在将新流量转移到生产环境之前在内部测试新的转速。当我们确信新版本没有重大问题时，我们可以删除旧版本，所有流量将开始转向最新版本。
但该设置不支持向后不兼容的数据库更改。几乎没有办法做到这一点，您可以让部分用户使用一个数据库模式，部分使用另一个数据库模式，并且能够对两者进行写入，然后在确定新版本正常后以某种方式将这些写入合并在一起。我的意思是，这是可能的，但它实际上取决于架构更改的具体内容以及它们如何影响您的应用程序，因此您无法在部署时以可靠的、不可知的方式完成此操作。对于我们来说，我们通常只是尝试不进行向后不兼容的架构更改。如果我们确实需要，我们会尝试将破坏性部分（删除列或表）推迟到更高版本，这样我们就可以迁移架构并使两个版本都运行，而不会对当前用户产生不利影响。
At my last job we accomplished this using the load balancer and a current revision cookie.
The load balancer set a cookie identifying the revision number of the instance that the user was using. If that cookie was already present, the load balancer would just send that request to a running instance with the corresponding revision. When we deployed a new revision, the load balancer continued to send traffic with an existing revision cookie to their original revision until that revision was no longer running or the user closed their browser. New traffic would get sent to the newly deployed revision. This allowed us to test out changes for a bit while our existing users were continuing to run on the old revision. We could also manually set that cookie to test out the new rev internally on the production environment before turning new traffic onto it. When we were comfortable that the new revision had no major problems we could bring down the old revision and all traffic would start going to the latest revision.
That setup does not support backwards incompatible database changes though. There's pretty much no way to do it where you can have part of your users on one db schema and part on another, and be able to take writes to both and then somehow merge those writes together after you've decided the new rev is ok. I mean, it's possible but it really depends on what the schema changes are exactly and how they effect your app, so you can't do it in a reliable, agnostic way on deployment. For us, we just generally tried not to do backwards incompatible schema changes. If we really did need to, we'd try to postpone the destructive part (dropping a column or table) to a later revision where we could migrate the schema and have both versions running with no adverse effect on current users.
对于随机选择过程，我喜欢这样的概念：在成功登录时询问每个客户是否想要参与 Beta 测试，一旦达到所需或想要的用户总数，您就停止询问。在数据库中，我倾向于存储将用户重定向到的服务器，并运行标准脚本，在登录时将每个用户移动到正确的位置。
我们提前几个月设计应用程序开发，并避免更改现有架构。原因很明显，当然这并不总是可能的，所以当我们发生这样的更改时，我们总是在编写更改时完整记录更改，并尽早计划该字段的迁移。这样我们就可以制定一个关于正在做出哪些改变的作战计划，并且可以为我们制定最佳的解决方案。不幸的是，这确实会根据情况而改变。
我们总是运行多个环境，通常有生产、开发和测试版。这意味着我们 1 不会搞乱等同于金钱的生产服务，我们不会让人在优化时破坏代码并让服务离线。
开发使用 GIT 进行版本监控，而用户永远不会看到这一点，因为我们上传了各种奇怪而精彩的实验供玩。它还使用自己的数据库与实时数据。
对于测试版，我们通常会迁移特定的用户数据，但最近我们在复制整个数据库并规划测试版开始的特定日期方面获得了更好的体验，这样做是允许用户选择退出测试版，而其他人则选择加入支持此选项所需的更改最少。我们通常做的是每天在两个数据库之间迁移一次新数据，新的选择加入和选择退出仅在数据迁移到另一个平台时生效。
我们还使用现有的生产数据库进行了小规模的成功测试，一些新功能在自己的表中运行，因此根据您正在做的数据明智地使用相同的实时数据库可能是一个不错的选择。
我希望这对你有用......祝你的测试伙伴好运。
For a random selection process I like the concept of asking each customer when they have a successful login if they want to participate in beta testing, once the total required or wanted quantity of users is reached you stop asking. In the database I tend to store what server to redirect the user to and run a standard script that moves each user to the correct location upon login.
We design our app development months in advance and avoid changes to the existing schema. The reason is very obvious, of course this is not always possible so when we have a change like this we always fully document the change when it is written and plan the migration for this field as early as possible. This way we have a battle plan of what changes are being made and we can put in place the best solution possible for us. This unfortunately does change depending on the circumstances.
We always run multiple environments, we have production, development and beta generally. This means we 1 do not mess with production services that equal money, we don't have people breaking code and pulling the service offline when optimizing.
Development uses GIT for version monitoring and users never see this as we get all sorts of weird and wonderful experiments uploaded for playing with. It also uses it's own database vs the live data.
With beta, we do migrate specific user data generally but recently we have had a better experience with duplicating the entire database and planning a specific date for the start of beta, what this does is allows users to opt out of beta and others to opt in with minimal changes required to support this option. What we generally do is migrate new data between the 2 databases once per day, new opt-ins and opt-outs only take effect from the time the data has been migrated to the other platform.
We have also had success on a small scale using the existing production database for beta testing some new functions that operated out of their own table so depending on what you're doing data wise using the same live database could be a good option.
I hope this is useful for you... good luck with your testing mate.
谷歌网站优化器似乎正是您所寻找的。
Google website optimizer seems like exactly what you are looking for.