#1 楼
我将用CI假设您是指一台集成服务器。充分利用测试和环境稳定性的最佳方法是使每种测试类型的环境脱钩。最好的例子是生产，它经过用户的“测试”。请注意，根据环境，我指的是用于部署特定版本的应用程序的服务器。这作为构建）。在这样的环境中，您最终将拥有与现场/生产环境类似的设置。根据您的团队的限制，这是我建议的建议：
限制使用新环境
仅安排工作以在通信量最小时启动负载测试。通常在晚上。测试完成后，应该有一份报告，并且应足够详细，以根据内部NFR阈值指示需要改进的地方。
不受其他环境的限制
>创建用于负载测试的新环境
对于每个新构建，如果它已在CI服务器中成功部署和/或测试，请部署到新环境中
运行负载测试并保存结果。根据您的CI工具，您也许可以根据结果质量配置报告和警报
在两种情况下，您都需要指定负载测试套件，以使您能够确定延迟太高的地方。我个人建议您第二种解决方案。尽管它需要更多的设置和维护，但由于以下原因，它是最有益的：
准确地告诉您何时构建开始不稳定。对于第一个解决方案，您可能需要进行调查，因为白天发生了很多变化。
高度了解哪些因素/谁使系统变慢。目前，团队已意识到此问题，可以立即进行补救。从长远来看，这项工作可能会被忽略。
可以充当性能门，在此时间内具有一定响应时间的所有构建都将停止进一步发展（即生产），直到响应时间得到改善。每天做一份工作是不切实际的。另外，您将需要等待一天才能看到改进的结果或手动运行测试。
如果您正在使用CI / CD，那么快速故障将被视为延迟故障。浪费一天时间解决问题可能会对您的产品上市时间产生重大影响。
#2 楼
没有正确的答案，从某种意义上说，您正在面临需求冲突。您也不能只吃蛋糕；）如果特定的质量检查验证（确实，不仅是性能）足够重要，并且您想立即捕获任何回归-您必须将其插入CI执行中。但是，除非您设法以某种方式与CI管道中的其他现有作业并行执行它，否则它将延长CI执行的持续时间。
您可以根据需要在“较慢的” CI管道中执行它，而执行的频率比常规CI管道要少。例如，只是每晚而不是每次提交之后。缺点是，当检测到回归时，您将不得不筛选一大堆提交来识别罪魁祸首。既可以通过人工分析手动完成，也可以使用自动二等分执行受影响的QA验证（或两者结合）。但这需要时间和资源。如果是罕见事件，那么这可能是可以接受的折衷方案，否则，您必须减少执行“较慢” CI管道之间的时间。
您必须决定更重要的是：CI执行速度或更快地捕获回归。该决定还可以取决于开发阶段的上下文。例如：
如果您在master / dev开发分支中，那么在CI执行速度方面有很多更改可能会更重要
在生产的发布分支削减中，您的提交率比在主分支中要低得多，因此优先考虑较快地进行回归（CI执行时间越长影响越小）
最后，当使用能够组合变更集的CI系统时，这样的决定将变得更加容易，因为更长的CI执行对有效变更集验证时间的影响减少了，请参见从6个月减少到16秒？来自DORA和Puppet Labs的DevOps报告中的令人沮丧的DevOps加速数据。
#3 楼
考虑这一点的另一种方法是考虑替代方法，以及它们是否适合您的需求。我分解性能指标的轴之一是它们是真实用户指标还是综合指标指标。您的性能测试大概是综合性的：每次在相同的环境中都运行相同的一组操作，从而可以轻松比较彼此之间的运行。
，综合性测试不会显示更改对用户的实际影响，这就是RUM的全部意义。您可以进行Canary部署，如果Canary中的性能下降超过可接受的阈值，则将其回退并进行调查（我看过Facebook上的一则有关他们如何在Canary服务器上收集完整调试跟踪的谈话，因此可以找到负责该代码的缓慢并自动回溯到一组提交和作者）。这对用户的影响更为现实，但是如果实际用户的行为存在正常差异，那么在没有大量流量的情况下可能很难做到。
理想情况下，您将同时使用这两种方法跟踪效果的方法。但是由于我们生活在一个不理想的世界中，因此您可以通过将重点放在其中一个而不是另一个上，从而为其他需求腾出资源，从而保持对公司绩效的关注。在您的特定示例中，如果这意味着减少CI反馈周期，那么较慢的部署是否可以取舍？也许-但这取决于您的公司。