如何向特定用户提供测试版功能？ （导轨）
我们希望开始让我们的用户帮助我们在更广泛的版本发布之前测试我们的功能更改。我们的 Rails 应用程序已经有了角色，但我不知道我们应该如何在不移动整个应用程序的情况下实现测试版功能。
有些问题我想不出解决方案：
- 测试版功能可能需要数据库迁移。当它可能导致现有应用程序出现问题时，您该如何处理？
- 更改模板和 css/sass 也可能会更改现有功能。
- 更改底层模型代码可能会破坏依赖它的现有控制器/接口。
一种解决方案（一个糟糕的选择）是在新功能中进行编码，并将其包装在仅当用户具有“beta”角色时才显示/使用它的逻辑中。问题是，当您最终将其投入使用时，您可能需要做很多放松/改变的事情。这既浪费时间，又可能引入错误。
另一个解决方案是在子域之外运行应用程序的单独“beta”分支，并将具有 beta 角色的用户路由到该分支。问题是 ssl 证书、电子邮件链接和其他域相关问题的复杂性使得维护有点麻烦（尽管不像第一个解决方案那么糟糕）。
我如何才能最有效地提供此服务，以最大限度地减少维护的额外工作，然后将测试版切换到完整版？
We want to start letting our users help us test our feature changes before a wider release. Our rails app already has roles but I don't know how to we should go about implementing a beta feature without moving the whole app over.
Some issues I can't think of solutions to:
- A beta feature may require a database migration. How can you handle this when it could cause problems with the existing app?
- Changing templates and the css/sass will likely change it for existing features too.
- Changing the underlying model code could break existing controllers / interfaces that rely on it.
One solution (a bad option) is to code in the new feature and wrap it in logic that only shows/uses it if the user has the "beta" role. The problem with this is when you finally take it live, you could have a lot of unwinding/changing to do. This is both a waste of time and could introduce bugs.
Another solution is to run a separate "beta" branch of the app off a subdomain and route users with the beta role to it. The problem with this is that the complexity of ssl certificates, email links and other domain dependent issues make this a bit of a maintenance pain (though not as bad as the first solution).
How can I offer this most efficiently so as to minimize the additional work to maintain and then switch the beta to the full version?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为在不影响当前应用程序的情况下进行此类测试的唯一合理机会是使用“临时”环境，并且实际上只是将测试版用户重定向到该环境。
与领域相关功能的问题相比，与迁移/功能问题相比，这实际上不算什么。
在我们公司，我们正是这样做的，但我们没有测试版用户的东西，但如果没有一个独立的环境，那么阻止新功能干扰当前功能几乎是不可行的。
对于功能，只需为这些新功能使用不同的分支，并从该分支创建“暂存”环境，一旦功能经过测试，您只需将它们合并到 HEAD 即可，新功能就在那里:]
I think the only reasonable chance of these kind of tests work without affecting the current application would be using a "staging" environment and really just redirect the beta users to that environment.
Compared to problems with domain related features it is really nothing compared to migrations/functionality problems.
On our company we do exactly that, but we don't have the beta users thing, but without an separated environment it will be pretty much inviable to keep new features from messing with current features.
For the features, just use different branches for those new features and create that "staging" environment from that branch, once the features have been tested you just merge them to HEAD and new feature is there :]
需要考虑的一种可能性是：对模型进行破坏性（即单向、不可逆）更改可能会产生问题，原因不仅仅是抑制您提供此测试版功能的能力。例如，如果您在迁移过程中遇到问题，可能很难取消更改。
相反，我建议寻找仅添加到模型的方法：添加列，同时保留旧列以实现向后兼容性，版本存储过程（如果您正在使用它们）等。如果您需要更改列数据类型，请改为创建目标数据类型的新列，然后让您的迁移还将现有行数据以新格式从旧列复制到新列。然后，您可以在测试环境中执行数据库迁移，并确认应用程序的新旧版本都可以继续使用数据库更改。
提供应用程序多个版本的一种可能方法是为您的测试站点使用替代的 respond_to 格式。您可以在 ApplicationController 中创建一个方法来检查用户是否处于测试版中。如果为 true，您可以覆盖 request.format 值，并在您的 respond_to 块中包含“format.beta”类型响应。
这种方法的挑战在于控制器逻辑。如果不在控制器方法中嵌入某种切换逻辑，您将无法更改控制器代码路径。这可能不是一个主要问题，具体取决于您有多少控制器更改。
（顺便说一句，看起来我们的名字非常相似！:-)）
One possibility to consider: making destructive (i.e. one-way, non-reversible) changes to your model may be problematic for reasons beyond inhibiting your ability to provide this beta functionality. For example, it may difficult to backout from a change if you have a problem during the migration.
Instead, I would recommend looking at ways to only add to the model: add columns while leaving old columns in place for backward compatibility, version stored procedures if you're using them, etc. If you need to alter column data types, instead create a new column of the target data type, then have your migration also copy existing rows data from the old column to the new column in the new format. You can then perform your database migration in your test environment and confirm that both the old and new versions of the application continue to work with the database changes.
One potential way to serve up multiple versions of your application is to use an alternative respond_to format for your beta site. You could create a method in your ApplicationController to check if the user was in the beta. If true, you can override the request.format value and in your respond_to block have a "format.beta" type response.
The challenge with this approach is the controller logic. Without embedding some kind of switching logic within your controller methods, you won't have a way of altering the controller code path. This may not be a major problem, depending on how many controller changes you have.
(By the way, it looks like we have very similar names! :-) )
我能想到的是在用户表中有一个 user_type 列。以便您可以将他们标记为测试版用户。 （甚至您可以将此标志设置为默认值，这样您就不需要更改现有代码。所有正在创建的新用户都将是测试版用户。）
为此，我假设
您将所有功能提供给测试版用户
测试版用户将来将拥有与普通用户相同的功能。
** 唯一的优点是您可以在测试版用户登录时对其进行过滤。之后，您可以执行诸如允许或不允许登录等操作。
当您切换到完整版本时，只需将测试版用户更新为普通用户，
我不知道这如何适用于您的场景。
谢谢萨梅拉
What I can think of is something like having a user_type column in your users table. so that you can flag them as beta users. (Even you can set this flag as default so that you dont need to change the existing code. All the new users who are creating will be beta users.)
For this i'm assuming
You are giving all the features to your beta users
Beta users will be having the same functionality which will be having by normal user in future.
** Only advantage is that you can filter beta users as and when they are login. Upon that you can do something like allowing to login or not etc..
When you are switching to the full version just update beta users as normal users
I dont know how this is applicable to your scenario.
thanks
sameera
我个人认为通过检查具有 beta 角色的用户来包装代码并不是一个坏主意。搜索所有调用（例如
if current_user.authorized?(:beta)）并将其完全删除将非常容易。I personally don't think it's a bad idea to wrap the code with a check for a user having the beta role. It will be quite easy to search for all of the calls to, for example
if current_user.authorized?(:beta)and the remove them entirely.我正在考虑做的一件事是设置一个测试版“暂存”环境，它实际上是生产环境。我们的想法是拥有 beta.mydomain.com，然后将想要尽早获得功能的用户发送到那里。基本上，它只是一个部署到实时测试站点的分支。
One thing I am thinking about doing is setting up a beta "staging" environment that is actually the production environment. The idea would be to have beta.mydomain.com and then send users there that want to get features early. Basically, it would just be a branch that gets deployed to the beta site which is live.