我们希望开始让我们的用户帮助我们在更广泛的版本发布之前测试我们的功能更改。我们的 rails 应用程序已经有了角色，但我不知道我们应该如何在不移动整个应用程序的情况下实现 beta 功能。
有些问题我想不出解决办法：
一种解决方案（一个不好的选择）是在新功能中编写代码并将其包装在仅当用户具有“beta”角色时才显示/使用它的逻辑中。问题在于，当您最终将其上线时，您可能需要做很多放松/改变。这既浪费时间，又可能引入错误。
另一种解决方案是在子域之外运行应用程序的单独“beta”分支，并将具有 beta 角色的用户路由到它。这样做的问题是 ssl 证书、电子邮件链接和其他域相关问题的复杂性使得这有点维护痛苦（尽管没有第一个解决方案那么糟糕）。
我怎样才能最有效地提供这一点，以尽量减少额外的维护工作，然后将测试版切换到完整版？
我认为在不影响当前应用程序的情况下进行此类测试的唯一合理机会是使用“暂存”环境，并且实际上只是将 beta 用户重定向到该环境。
与域相关功能的问题相比，与迁移/功能问题相比，这真的算不了什么。
在我们公司，我们正是这样做的，但我们没有 beta 用户的东西，但是如果没有独立的环境，防止新功能与当前功能混淆几乎是不可行的。
对于功能，只需为这些新功能使用不同的分支并从该分支创建“登台”环境，一旦功能经过测试，您只需将它们合并到 HEAD 并且新功能就在那里：]
我能想到的是在你的用户表中有一个 user_type 列。这样您就可以将他们标记为 beta 用户。（即使您可以将此标志设置为默认值，这样您就不需要更改现有代码。所有正在创建的新用户都将是 beta 用户。）
为此我假设
您将所有功能提供给您的 Beta 用户 Beta 用户将拥有与未来普通用户相同的功能。
** 唯一的优点是您可以在登录时过滤测试用户。在那之后，您可以执行诸如允许登录或不登录等操作。
当您切换到完整版时，只需将 beta 用户更新为普通用户
我不知道这如何适用于您的场景。
谢谢
同龄人
需要考虑的一种可能性是：对模型进行破坏性（即单向、不可逆）更改可能会出现问题，原因不仅仅是抑制您提供此 beta 功能的能力。例如，如果您在迁移过程中遇到问题，可能很难从更改中退出。
相反，我建议寻找只添加到模型中的方法：添加列同时保留旧列以实现向后兼容性、版本存储过程（如果您正在使用它们）等。如果您需要更改列数据类型，请改为创建目标数据类型的新列，然后让您的迁移也将现有行数据从旧列复制到新格式的新列中。然后，您可以在测试环境中执行数据库迁移，并确认应用程序的旧版本和新版本都继续使用数据库更改。
为您的应用程序提供多个版本的一种潜在方法是为您的 beta 站点使用另一种 respond_to 格式。您可以在 ApplicationController 中创建一个方法来检查用户是否处于测试阶段。如果为真，您可以覆盖 request.format 值，并在您的 respond_to 块中有一个“format.beta”类型的响应。
这种方法的挑战在于控制器逻辑。如果不在控制器方法中嵌入某种切换逻辑，您将无法更改控制器代码路径。这可能不是主要问题，具体取决于您有多少控制器更改。
（顺便说一句，看起来我们的名字非常相似！:-)）
我个人认为通过检查具有 beta 角色的用户来包装代码并不是一个坏主意。例如，搜索所有调用if current_user.authorized?(:beta)并完全删除它们将非常容易。
我正在考虑做的一件事是建立一个实际上是生产环境的测试版“登台”环境。我们的想法是拥有 beta.mydomain.com，然后将想要尽早获得功能的用户发送到那里。基本上，它只是一个部署到实时测试站点的分支。