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