但是，CI系统验证确实在这些强制性的提交前验证所涵盖的区域中检测到了一些回归（建筑破损，各种测试失败）。
在对这些回归进行分析期间，经常听到这样的论点，即认为所做更改是回归的根本原因的开发人员已成功通过了所有此类验证。通常，该主张会得到有力的证据支持，表明：
达到变更的最终版本后，便根据分支的尖端将其移植到新的工作空间中。 >所需的工件是从头开始构建的（因此，构建完全正常，没有与缓存相关的问题，等等）。
通过了所有强制性测试，包括涵盖相关区域的测试，并且应该已经检测到回归
没有间歇性的误报会影响相应的验证
将更改提交到分支时未检测到文件合并
由于新的工作空间，分支中提交的任何其他更改都未触及正在修改的文件被撤消了
尽管正确地遵循了所有规定的过程和实践，但是软件更改是否真的有可能导致这种退步？怎么样？
#1 楼
我可以想到的一种可能性是，当开发人员在自己的工作站上工作时，有时会为虚拟盒烘烤图像以在其工作站上运行，而您的基础架构不会使用完全相同的图像。开发人员在开发功能时需要在其工作初期就向中间件添加JVM参数或进行任何更改，然后将其忘记。
在提交之前，所有单元/集成测试均在其上运行工作站可以很好地工作，因为共享烘烤的图像，它可以在每个develloper系统上工作。
但是，通过CI时，它失败是因为未实现对中间件的更改，或者是因为开发人员忘记要求了，或者仅仅因为负责更新基本映像/资源调配系统的团队没有时间或忘记了更新系统。
这样做是一件好事在CI中，因为它在投产前就告诉系统无法按预期运行，但有时会变成地狱找到丢失的参数。
这最后一点是要避免拒绝提交，而只是在功能分支上中断CI，这样就不会阻塞其他任何人，并让开发人员尽早解决问题，当需要更改并阻止更改在流程中被遗忘时。
FWIW，我们正是在这里进行了此操作，开发人员可以完全访问开发机器，而Q / A中的发行版却失败了，因为参数更改已经被忘记了，我们确实转移到Chef来处理中间件的配置（现在是tomcat），因此对基础结构的每个所需更改都必须在某个地方编码，并将在所有环境中复制。
评论
值得一提的是，开发人员所做的更改是否依赖于测试框架中的功能，因此它可以在生产环境（我设法做到一次）之外的所有环境中工作。
–雅各布·卡尼亚（Jakub Kania）
17年11月24日在23:24
#2 楼
就是这样。生产总是不同的。真钱。实际负载。真实用户。真痛。这就是为什么将任何重大更改放在功能标志后面如此重要的原因。您的部署不应更改任何内容。开启功能是唯一应该对您的网站进行重大更改的事情。评论
我说的是集成系统中集成系统捕获的回归。在生产中部署之前。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 7 '17 at 4:57
考虑一个通过所有测试的CSS更改，但在生产中注意到销售下降到$ 0。目视检查发现按钮文本现在与背景颜色相同，用户拒绝单击彩色斑点。除非您具有UI回归并且人们实际验证了回归，否则自动化可以解决此类问题。 CI可能不会出现此问题。
–不退款不退货
17年7月7日在5:01
还包括：“所有强制性测试都通过了，包括那些涉及问题区域并且应该已经检测到回归的测试” –在对开发人员的图像进行预提交验证时，通过了相同的测试，但是在提交更改后构建的CI图像失败。
–丹·科尼莱斯库（Dan Cornilescu）
17年7月7日在5:04
#3 楼
从理论上讲，破损始终是可能的，因为开发人员执行的提交前验证是孤立进行的，因此无法考虑并行验证的其他运行中更改。这样的更改可能相互干扰，并导致回归，而实际上在SCM级别上没有可检测到的冲突。此类干扰性更改的简单示例：
让我们假设代码在最新版本的项目分支中，“项目分支”包含某个功能，该功能定义在一个文件中，并在其他两个文件中调用。并行处理该项目的两个开发人员正在准备对代码进行一些更改。
Developer A返工，该函数可以删除或添加必需的函数自变量，并且当然可以更新该函数的所有调用。所有关联的文件都与更新后的定义匹配。
开发人员B决定在文件中添加该函数的调用，该文件之前不包含任何此类调用，因此开发人员A的更改未涉及到该调用。当然，开发人员B正在填充参数列表以匹配最新标签中可见的函数定义。这是旧的定义，因为开发人员A的更改尚未提交。
两个开发人员都正确地执行了带有通过结果的预提交验证，并继续提交其代码更改。由于两个变更集不会接触相同的文件，因此不会发生最终合并，这通常表示存在潜在问题，需要仔细查看并可能重新执行预提交验证。没有任何东西甚至可以给人以微妙的暗示，可能出问题了。开发人员A.
#4 楼
当您发现此类问题时，应编写一些可以快速解决这些问题的新的运行速度非常快的验收测试，并将其添加到在集成测试之前运行的构建验证测试中。您应该经常向左移动，并尝试缩短对开发人员进行更改的反馈循环。如果您找不到解决方案，那么您的体系结构可能不如所需的敏捷。@Dan Cornilescu-您的方案适用于紧密耦合的体系结构，这就是为什么松散耦合的体系结构的原因（版本化RESTful API的微服务）已成为高性能组织中的当前最佳实践。这些服务组织矩阵还需要克服其他复杂性。
有时您需要重构整个体系结构以克服诸如此类的问题。我认为是Google和eBay都已经重新构建了自己的平台5次（在大约10年的时间里），原因是它们以前的体系结构受到限制。
评论
我认为您错过了问题的重点：问题中提到的强制性的提交前质量验证集已经包含您正在谈论的验收测试。它们在提交和通过之前由开发人员执行，并且由CI系统执行，并且在两次提交都进入后失败。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 24 '17在1:15
这就是我的观点，也许全新的架构是对此问题的适当响应，而当前架构无法解决该问题。
–icewav
17 Mar 24 '17在1:29
您是指产品架构还是流程架构？
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 24 '17 at 1:30
如果当前的流程体系结构无法解决问题，则为新的产品体系结构。
–icewav
17 Mar 24 '17在1:51
产品架构是无关紧要的，这个问题几乎适用于所有产品架构，除了非常小的琐碎的sw产品。请参阅我的答案中的示例。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 24 '17 1:59
评论
通过预提交，您的意思是在进入CI系统（在开发人员工作站上）或SCM挂钩检查之前？我在dev workstaion上看到了一个案例，但是在预提交的钩子上却没有。我猜这取决于确切的SCM系统。是的，如果进入同一分支的2个更改的预提交挂钩执行可能在时间上重叠-例如git就是这种情况。
抱歉，我不清楚，我的意思是您的提交前检查是在开发工作站上还是在SCM端（中央存储库）上运行的？总而言之，我想知道您是在谈论开发人员将在提交之前启动自己的检查，还是它是由中央服务器“接收”的自动化测试系统。
是的，这就是我要去的地方。请注意，即使允许集中检查，也可以进行回归-如果允许它们在时间上重叠。
好的，然后是修辞性的问题（我的意思是，您已经有了答案并且知道您在等待什么）。根本没有太多地方可以得到真正的答案。