在开发时，我的团队显然使用development作为我们的环境。
当我们运行自动化测试时，我们使用testing。
我们还有staging 和production 环境，分别用于我们的测试人员检查功能和最终的“实时”产品。
我们正在尝试设置一个内部 CI 服务器来运行我们的自动化测试并最终协助自动化部署。
由于 CI 服务器确实在运行自动化测试，因此有人认为它应该运行在 testing 环境中。然而，为了让 CI 服务器真正有用，我的想法是它需要在production 模式下运行，尽可能接近实际production 环境的镜像（不接触生产数据库，显然）。
是否存在应在其下执行 CI 服务器的公认环境？ production 环境（使用不同的数据库）对我来说似乎是唯一合乎逻辑的答案，但我可能会遗漏一些东西......
【问题讨论】：
标签： ruby-on-rails-4 continuous-integration automated-tests automated-deploy
如您所说，在 PROD 环境中运行任何测试
似乎是唯一合乎逻辑的答案
但并不完全正确。您的测试可能会严重损害实际环境/应用程序，以至于您将面临恢复选项的风险。毕竟，测试的阴暗面是显示/发现您的软件不仅有小错误，而且工作不如预期。 我至少可以想到这些“为什么不测试生产”的考虑：
当产品推出时，客户依赖它。期望您的软件正在运行（）已经测试）。您的实时环境应该完成它的工作，而不是加载测试。如果产品行为不端（或没有表现），则必须派技术团队来弥补损坏，修复差距并使其运行无忧。现在这不仅影响了产品成本，而且在很大程度上推迟了项目的最后期限。这将对供应商的利润和接下来的几个项目产生递归影响。
生产或开发团队在最终完成产品开发后，必须在将新开发的产品加载到该环境中进行测试之前为测试团队制作此测试环境。
对我来说，不管你是什么
还有暂存和生产环境
相应地使用测试是必不可少的。此外，测试环境应该（配置）尽可能接近生产环境。此外，一个人可能正在尝试测试，而另一个人破坏了他一直在测试的东西。如果两者分开，他们就无法进行适当的测试。
为了完整的回答，您的 STAGE 环境可以根据公司的不同而具有不同的角色。 一是它可以是 QA/STAGE 环境，它具有生产的精确副本，用于 QA 和系统测试（当大量更新/更改或升级进入生产时测试系统）。
更新：
这也是我的观点。 QA 环境应该是 PROD 的镜像。关于将文件缓存/预加载到暂存/生产的问题的可能解决方案是创建 pre-/post-steps .bat（假设）文件。
在我们当前的测试项目中，我们使用这种方法。在预步骤中，我们设置了测试执行所需的文件（例如从以前的运行中删除文件和下载最新的副本/工件）。在后期步骤中，我们设置了所需的报告文件。优点是您的文件将在每次执行之前被收集和同步。
关于
不在同一个物理硬件上
在我的例子中，我们支持专用的远程测试服务器。优点很明显，唯一需要考虑的是它需要维护（管理）。
【讨论】：