假设您使用的是持续集成过程，该过程会经常更新某些目标环境，以便每次发生某些更改时，“您”都可以立即测试您的更改。那是CI的目标之一，不是吗？
但是，还要假设您在测试周期中涉及其他人员，例如经理或客户。让其他人参与尝试（中断）您即将进行的更改很有意义，不是吗？
但是，如果您继续在其他人正认真尝试测试的环境中不断交付更改，那么可能会出现多个问题，例如：
they 可能会浪费他们的时间来报告问题，而当他们保存（深入）报告时，他们甚至无法自己重现该问题（例如，由于您偶然遇到了同一问题，并且已经将其修复在他们的环境中）。you 可能无法重现他们报告的问题，因为遇到问题的环境不再相同（您（!!!）可能覆盖了他们的环境）。那么，您该怎么做（如何配置事物？）来避免此类（令人沮丧的）情况？
Answers:
我将在此方面给出我的经验，主要是因为它展示了为什么某些答案并不总是适用的原因。
开始的一些背景：
我们正在做的不是完全自动化的持续交付，我们有一个发布时间表来为常规操作提供大量一致的应用程序。除此之外，每个测试团队都可以在一个Q / A环境中针对他们正在测试的应用程序触发发布，并且可以锁定某个应用程序版本，以避免另一个团队要求破坏他们的测试。
在发布之前检查应用程序的依赖关系，因此，如果其他应用程序无法更新或与所需的依赖关系不匹配，则系统不会发布某些内容。主要思想是允许在不影响某人的情况下进行更新，如果没有计划的测试，则应从以前的环境中进行（我们的目标是在中期从5个“第一”环境中删除计划的发行版）验证了此“按需”方法系统）。
简短的版本是在环境中的应用程序周围有一个“信号灯”系统，团队应该能够在进行手动测试时使用其依赖项（和传递性依赖项）锁定其目标应用程序。
该信号量的实现高度依赖于您的自动化系统，因此我将不对此进行扩展。
当然，如其他人所述，简单的方法是为具有所有依赖关系的应用程序创建一个新鲜的环境，以避免上述信号量。
听起来您正在谈论的是一个不断重复使用的测试环境，而对于每次测试执行，该环境都没有可靠地重新初始化。这使得这种测试不可靠。从可靠性的角度来看，如果需要，可以进行手动测试。
恕我直言，您不应该在 CI / CD认证目的内使用此类测试，因为这将有效地使您的认证过程无效（至少在该领域）。说软件通过了测试X却没有对每个交付的软件版本实际执行测试X，或者不确定所pass获得的结果不是偶然的（由于误报），将会削弱测试的置信度。假阴性不会损害信誉，但由于它们会产生不必要的“噪音”，因此也是不希望的。
在您的CI / CD认证过程之外执行此类测试是可以的。但是，您将在这种测试中将失败的结果当作客户发现的错误一样对待：您需要可靠地重现该问题，以便能够为其开发修复程序并确认该修复程序正在工作。如果测试不可靠，您将无法真正做到这一点。
如果您打算解决问题，那么理想情况下，您首先要开发一个自动化，可靠的测试案例来重现问题。用于开发修补程序并确认其有效性的工具（测试结果应从“失败”转换为“通过”）。您也可以（应该？）将此测试用例放置在CI / CD认证过程中，以防止将来再次发生（如果需要），从而提高总体软件发行质量。
inside和outside引用是相对于CI验证循环。基本上，我质疑存在QA环境的原因-在其中进行的大多数测试应该可靠，并最终作为CI验证的一部分执行，尤其是在连续部署的情况下-因为您希望在每次CI迭代中都执行它们（成功至少到那时为止）。
通常的方法是创建不同的环境：
开发人员-这是开发人员团队弄乱事情的地方。这是创建所有更改调整，部署新版本等。这是CI完全集成的地方。
PREPROD / QA-这是“玩” QA /测试/验证团队进行测试的地方。该环境通常在测试期间冻结。CI与该环境的集成仅是为了提供产品的新版本，配置等。
生产-是否需要解释:)？
要增加Romeo Ninov的答案，您需要在内部环境中尝试尽可能多地分离出应用程序。这部分是为什么docker在开发/测试方面如此成功的原因。它使您几乎假装根本不共享环境。
另一个选择是拥有非常明确定义的服务器，在这些服务器上运行应用程序，这些服务器与构成环境的其余基础结构分开。就是 所有环境管理或启用机制都在单独的，使用寿命长的服务器上运行。然后你钩在新的短命基于已知的图像上测试应用程序，如果任何改变都基本影像制作的服务器，你需要将这些更改应用无处不在每一个新的组件。这意味着要对所有变更进行测试。
如果appdev团队要求进行更改以破坏他人的应用程序，那么倒霉了，他们需要在内部在其代码中创建缓解措施，并将其特定要求与环境产品分开。