但是，还要假设您有其他人参与测试周期，例如经理或客户。让其他人参与尝试（破坏）您即将发生的变化是有意义的，不是吗？
但是，如果您持续不断地在其他人所处的环境中交付变化，那么认真地尝试测试它们，然后可能会出现多个问题，例如：
they可能会浪费他们的时间来报告问题，而当他们保存（深入）报告时，他们甚至无法再复制自己的问题（例如，因为您偶然也遇到了相同的问题，并且已经在他们的环境中解决了该问题）。他们遇到问题的环境不再相同（您（!!!）可能覆盖了他们的环境）。 （令人沮丧的）情况？#1 楼
我会在这方面做我的经验，主要是因为它展示了为什么某些答案并不总是适用的。开始的一些背景：这些环境可托管大约80个应用程序，其中大多数通过db2-iSeries上的Web服务或共享表相互依赖。
无论好坏，iSeries都是我们的数据库参考系统。
最后一点使将应用程序及其依赖项放在隔离环境中的想法无效，因为为每个应用程序提供一个AS400会花费太多，而且我们也没有硬件来运行它。
我们要做的不是完全自动化的持续交付，我们有一个发布时间表，以针对常规操作提出大量一致的应用程序。除此之外，每个测试团队都可以在一个正在测试的应用程序的Q / A环境中触发发布，并且可以锁定某些应用程序版本，以避免另一个团队要求破坏他们的测试。
在发布之前检查应用程序的依赖关系，因此，如果其他应用程序无法更新或与所需的依赖关系不匹配，系统将不会发布某些内容。
主要思想是在不影响应用程序的情况下允许更新某人，如果没有计划中的测试，那么它应该从以前的环境中流出来（并且我们的目标是在中期中删除5个“第一”环境中的计划发行版，现在我们已经验证了此“按需”方法系统）。
简短的版本是在环境中的应用程序周围有一个“信号灯”系统，团队应该能够在进行手动测试时用其依赖项（和可传递依赖项）锁定其目标应用程序。 />此信号量的实现高度依赖于n您的自动化系统，因此我将不对其进行扩展。
当然，如其他人所述，简单的方法是为具有所有依赖项的应用程序创建一个新鲜的环境，以避免上述信号灯。
#2 楼
听起来您正在谈论的是一个不断重复使用的测试环境，而对于每次测试执行，该环境都没有可靠地重新初始化。这使得这种测试不可靠。从可靠性的角度来看，如果需要的话，可以通过手动测试进行类似的操作。在那个区域）。说软件通过了测试X却没有对每个交付的软件版本实际执行测试X，或者不确定所获得的pass结果不是偶然的（由于误报），将会削弱测试的置信度。误报不会破坏信誉，但由于它们会产生不必要的“噪音”，因此也是不希望的。在CI / CD认证过程之外执行此类测试是可以的。但是，您将在这种测试中将失败的结果当作客户发现的错误一样对待：您需要可靠地重现该问题，以便能够为其开发修复程序并确认该修复程序正在工作。如果测试不可靠，您将无法真正做到这一点。
如果您打算解决问题，那么理想情况下，您首先要开发一个自动化，可靠的测试案例来重现问题。用于开发修补程序并确认其有效性的工具（测试结果应从“失败”转换为“通过”）。您也可以（应该？）将此测试用例放置在CI / CD认证过程中，以防止将来再次发生（如果需要），以提高整体软件发行质量。
评论
您的答案有很多需要消化的地方（我不确定我是否已经完全理解了）。但是您所写的“在CI / CD认证过程之外执行此类测试”的内容是：我希望生产/交付的最终结果存储在您的QA和产品环境中（通过CD，自动或手动）。但这也让我“似乎”认为CI也应该在那儿交付其输出，而“外部”似乎是分离或重复之类的，不是吗？
– Pierre.Vriens♦
17年3月13日在18:35
内部和外部参考是相对于CI验证循环的。基本上，我质疑存在QA环境的原因-在其中进行的大多数测试应该可靠，并最终作为CI验证的一部分执行，尤其是在连续部署的情况下-因为您希望在每次CI迭代中都执行它们（成功至少到那时为止）。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 14 '17 2:21
#3 楼
通常的方法是创建不同的环境：DEV-这是开发团队弄乱事情的地方。这是创建所有更改调整，部署新版本等。这是CI完全集成的地方。
PREPROD / QA-这是“玩” QA /测试/验证团队进行测试的地方。该环境通常在测试过程中冻结。 CI与该环境的集成只是为了提供产品，配置等的新版本。
生产-是否需要解释一下:)？
评论
好的，这应该有助于提高稳定性，谢谢！我的问题是关于“测试”环境的，因此显然不应将“生产”视为这样。尽管有那些使用“生产”进行测试的人，但是您还是会说“最好的测试是在生产中激活它，如果它不起作用，则只需执行回滚/回退！”？
– Pierre.Vriens♦
17年3月13日在18:09
@ Pierre.Vriens，在产品恕我直言中“玩”是不明智的:)这种环境分离是有意的。在上一份工作中，我们有5种不同的环境。。。
–罗密欧·尼诺夫（Romeo Ninov）
17年3月13日在18:14
“我”同意这样的游戏是不明智的。但是，“您”会对牛仔（我经常用这种术语说的“术语”）不断做些什么，每次他们都得到经理的批准以解决（例如）每月发布激活问题时，“您”能做什么，通过另一个错误修正（例如，针对前一天的错误修正...引入了新的错误）。您认为这在现实世界中不会发生吗？顺便说一句：关于答案中的“冻结”，您认为发布诸如“冻结环境的示例实现是什么？”之类的问题是有意义的。
– Pierre.Vriens♦
17年3月13日在18:22
@ Pierre.Vriens，对我来说，发布这样的问题非常有意义。通常，这是受公司规则约束的，但是开发人员会创建相当动态的环境，这可能是一个真正的挑战:)
–罗密欧·尼诺夫（Romeo Ninov）
17年3月13日在18:36
这是我的首选方法，这样可以为开发人员提供一个环境，使开发人员可以在集成环境中立即测试其更改，但保持QA整洁，直到准备好正式测试代码为止
– Taegost
17 Mar 29 '17 at 20:43
#4 楼
如果您正在执行CI / CD，则意味着在部署（CD）之前会进行一些自动化测试（CI）。如果您在测试环境中发现很多问题，则意味着它们不会被部署之前运行的测试所困扰。这表明自动化测试不足。如果开发人员遇到在测试环境中出现缺陷的问题，则他们需要改进其自动化测试套件以防止这种情况。从生产到生产的整个过程，这还将提高整体质量和可靠性。#5 楼
为了增加Romeo Ninov的答案，您需要在内部环境中尝试尽可能多地分离出应用程序。这部分是为什么docker在开发/测试方面如此成功的原因。它让您几乎假装根本不共享环境。另一种选择是拥有非常明确定义的服务器，在这些服务器上运行应用程序，这些服务器与其余基础结构分开改善您的环境。就是所有环境管理或启用机制都在单独的，使用寿命长的服务器上运行。然后，您基于已知映像挂接新的短期服务器来测试应用程序，并且如果对基本映像进行了任何更改，则需要将这些更改应用于每个新组件。这意味着要对所有变更进行测试。
如果appdev团队要求进行更改以破坏他人的应用程序，那么倒霉了，他们需要在内部在其代码中创建缓解措施并将其特定要求分开来自环境产品。
评论
有趣的观点/补充，尽管其中可能有些事情您可能需要细化/修改：（1）在这种情况下，“应用程序”是什么意思（一些示例？）（2）任何想法如何在其中工作（旧的）大型机环境（3）在这种情况下，什么是“缓解者”？ PS：如果您认为我应该为这些“事物”（项目符号）中的任何一个提出新问题，请告诉我。
– Pierre.Vriens♦
17年3月13日在18:16
评论
这个答案是我习惯（大型机）的一种变体，在那里我们至少在1.5年左右的时间里做这些事情（在“ DevOps”诞生之前）。我想知道在这里添加我自己的答案（进一步扩展这个答案，我们如何使用CMN / ZMF来处理“银行”）是否有意义，或者只是将其带到一个新的问题（自我回答）。你怎么看？另外，我对这个比喻感到好奇，值得一个新问题（参考这个答案）？ PS：您介意我纠正一些错字吗？
– Pierre.Vriens♦
17年3月18日在9:49
编辑没问题:)我确实保持了通用性，这对devops组织恕我直言不是很具体。同样，DevOps是组织的变更，它可以通过共享问题来帮助建立更好的自动化...因此，我将其称为信号量，就像在编程中一样，我认为不值得提出问题，但这取决于您
–滕西拜
17年3月18日在10:11
好的，编辑完成（照常：回滚/根据需要进行改进）。顺便说一句，您的键盘上有一个“ s”吗？！？！？！除此之外：周末需要考虑的事情：请参阅我最新的meta问题...周末好！在这里园艺的时间（修剪...）
– Pierre.Vriens♦
17 Mar 18 '17 at 10:20