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