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