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