但是，当检测到这些回归时，分支机构至少已经从相应的质量检查验证开始就陷入了麻烦，并将一直保持这种状态（甚至变得更糟！），直到找出所有的罪魁祸首，然后进行修复表示他们已承诺，并且新的质量检查验证确认分支机构的质量级别已恢复。在整个这段时间里，分支都可以被视为无法正常开发。
是否有一个CI工具能够真正防止此类回归的发生，它将执行预提交的QA验证并仅在以下情况下允许提交：用各自的提交更新的代码库也将通过那些预先提交的QA验证，从而保证最低的分支质量级别？
更新：假设是适当的自动QA验证且覆盖范围适当，从而能够CI工具可以调用以检测各个回归。
#1 楼
据我所知，您正在寻找一种工具，该工具将拒绝破坏构建的提交-CI工具可能无法通过实际修复代码来防止回归，但是它可以阻止您添加错误的代码Atlassian有一些有趣的Git钩子应用程序：服务器端预接收钩子对持续集成特别有力，因为它们可以阻止开发人员将代码压入掌握，除非代码满足某些条件，例如精英忍者守护者，以保护其免受不良代码的侵害。
如果您使用的是Git，则钩子是非常强大（并且SVN，Mercurial和其他版本控制系统也有类似的钩子），并且使用它们来运行提交前检查可能会很有用。
Git文档的页面位于创建一个钩子以拒绝不符合特定条件的推送，如果这些条件很容易适应该用例。
但是，很多人们会认为拒绝提交在
feature分支上是个坏主意-当构建由于某种原因而中断时，您只是在浪费时间与CI系统进行战斗，而不是实际修复该错误。 在
master分支上，拒绝残破的合并可能很有意义，因为您可能希望确保它始终在构建。对于feature分支，您将不可避免地破坏事情，并且由于代码现在尚未投入生产，因此警告您比实际完全拒绝提交更有意义。评论
那么，建立的sw映像有什么好处，但是从测试的角度来看DOA是预期的吗？开发人员即使构建代码也无法测试其代码更改，因此它们同样会被阻止。因此，总的来说，我会将提交拒绝扩展到未能通过最低质量检查的任何事物，这是通过平衡2个相互矛盾的要求来选择的：尽可能高以最大程度地保护受阻止的开发人员数量，并且尽可能低以使QA验证延迟不发生不会使该过程减慢太多。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 3 '17 at 13:39
一个示例就是拉取请求模型，您可以在其中限制是否可以合并拉取请求。例如，我们（我的公司）使用Atlassian Bitbucket Server，并且在允许合并请求请求之前，有一些选项要求给定分支至少需要N个批准和X个通过构建。这并不能完全拒绝它。但是可以防止在测试失败或其他人尚未看到代码时意外合并。
–安迪·辛（Andy Shinn）
17年4月4日在4:41
@AndyShinn：是的，我发现这很有用-GitHub还提供受保护的分支和对请求请求的检查，这通常很有用。
–Aurora0001
17 Mar 4 '17 at 11:19
在功能分支中允许破坏代码的一个论点是，即使尚未准备好，开发人员也可以将正在处理的代码推送到仓库中。这对于与他人共享代码以在事情准备就绪之前进行早期代码/体系结构审阅，帮助调试问题，或者对于那些正在休假的人将部分完成的工作放在别人可以得到的地方很有用。对于功能分支，我只会放置诸如linters和pre-commit挂钩之类的东西。
–布雷迪姆
17 Mar 4 '17 at 19:18
#2 楼
没有工具可以保证不进行回归-与执行测试的工具相比，这更多地取决于测试。但是，您可以帮助防止陷入陷阱的回归进入集成分支。您可以使用预提交的钩子来做到这一点，但是使用拉取请求通常会更容易（希望您已经使用它进行对等代码审查）。如果分支的最新信息上游（PR合并到的位置），并且其测试通过，然后在合并后它们仍将通过；合并后目标分支的状态将与合并前源分支的状态相匹配。
通常不特别困难（取决于所使用的工具），以同时指示源分支和PR是最新的目标，如果它具有合格的CI版本。您可以将此作为合并拉取请求的要求（根据策略和/或在软件中强制执行）。
评论
“如果分支的上游是最新的（PR合并到其中），并且其测试通过了，那么合并后它们仍然会通过”-为什么？合并是不连续的，它带来了未知数。像冲突一样-代码只有在解决后才可能生成。您需要运行测试并确认它们通过任何分支合并。我想说的是即使快进也要安全。见Apartsw.com/insights/2016/11/16/…
–丹·科尼莱斯库（Dan Cornilescu）
17年4月4日在3:57
嗯，是的，这样的保证是可能的，请检查我的答案。好吧，也许我应该澄清一下：通过回归，我的意思是说结果差于分支基准结果（并且忽略误报的可能性，需要解决这些问题，因为它们可能会倾斜基准，使整个事情脱轨并需要人工干预）。间歇性的假阴性只是令人讨厌的事情，它可以减慢速度，但是可以解决。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 4 '17 at 4:16
您不能保证没有回归，只能保证没有检测到回归。如果更改导致回归无法被测试捕获，则表明CI工具无法做出任何保证。虽然合并两组更改确实带来了未知数，但是您可以选择在要素分支中进行此操作（通过合并上游），然后再合并另一个方向。如果源与目标保持最新，则这是一次简单的合并（快进），此后目标状态将与合并之前的源状态相同，因此，如果测试在此之前通过，则它们将在之后通过。
–阿德里安
17 Mar 4 '17 at 4:30
劈开头发。可以使用测试配置CI工具，以检测并因此防止您关心的任何回归。对于合并，我不会过多争论-我的目标是尽可能避免合并，这只会给整体带来麻烦:)
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 4 '17 at 4:46
我的观点是，通过编写测试，不是您提供保护的CI工具，而是您自己。 CI工具无法提供您提供的测试以外的任何保证。
–阿德里安
17年4月4日在16:49
#3 楼
像Reitveld和Zuul这样的真正的持续集成工具（而不是持续测试）可以提供帮助，尽管它们仅与您编写的测试和代码审查一样好。评论
但是Reitveld似乎是一个协作代码审查工具，而不是CI工具，我是否缺少某些东西？这就是我所看到的：github.com/rietveld-codereview/rietveld
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 3 '17 at 7:09
Zuul似乎确实相关，我将对其进行深入研究。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 3 '17 at 7:16
它不进行测试，但可以处理分支管理的某些方面，充当网守系统，这是阻止恶意代码阻止合并的最佳选择。
–coderanger
17 Mar 3 '17 at 7:37
我明白你的意思了。好的，它可以帮助提高整体代码质量，但是它本身并不能带来任何保证。两个完全通过所有QA验证的非常好的更改在分支中相遇时仍可能导致中断。
–丹·科尼莱斯库（Dan Cornilescu）
17年3月3日在14:13
#4 楼
使用GitLAB，您可以在项目设置中进行设置，以仅在管道成功时才允许合并，因此可以进行真正的持续集成，将其添加到合并批准列表中进行质量检查，并与动态环境结合使用，可以保证质量在合并到母版之前。评论
该方法有效，但前提是您不允许第二次合并在上一次合并完成之前启动质量检查，否则第二次合并将看不到第一次合并，从而为回归留出了空间。换句话说，合并（包括其质量检查）必须完全序列化，这不适用于大型团队。
–丹·科尼莱斯库（Dan Cornilescu）
18-09-17在9:28
#5 楼
ApartCI是一个CI系统，旨在防止回归，从而确保平坦或提高分支质量水平。仍处于测试阶段。它以一种集中协调的方式预先提交验证，以确保仅在验证之后以及与之之前进行的所有其他更改一起完成更改，才能达到或超过该更改。最新的分支机构质量水平。
与通常由开发人员驱动的提交前验证（通常并行进行）相比，这是关键区别，这为因干扰性变化而导致的回归提供了余地，而这些变化从未一起进行过测试。 />该工具还设计为易于扩展-能够承受很高的传入候选者更改率，并支持在同一集成分支中工作的100/1000开发人员。
免责声明：我是作者工具和提供它的公司的创始人。广告的道歉。
评论
您最好添加免责声明，但我个人认为可以通过将自己的公司或产品推广为垃圾邮件的形式来提出问题并自我回答。
– THelper
17 Mar 4 '17 at 11:39
我问了一个关于meta的问题，是否允许：meta.devops.stackexchange.com/q/59
– THelper
17 Mar 4 '17 at 12:04
SnapCI也这样做。 RIP。
–paul_h
17年4月1日在23:21
@paul_h，除非我缺少SnapCI及其推荐的替代GoCD都基于提交后的验证（通过轮询SCM触发），所以它们仍然仅用于监视。除非进行PR检查，否则除非将这些检查完全序列化，否则它们只能降低回归发生率，而不能完全消除。
–丹·科尼莱斯库（Dan Cornilescu）
17年4月2日，下午3:31
丹，不轮询不，钩子。到尚未合并到主干/主站的短暂PR分支-trunkbaseddevelopment.com/game-changers / ...
–paul_h
17年4月8日在19:07
评论
我一直想知道了解这个问题的正确方法（以及您自己在答案中的建议）。如果我用“事后”代替“监视”，而用“事后防止”代替“预防”，那么问题还是差不多吗？另外，也许您可以添加一些示例方案来说明差异？@ Pierre.Vriens这样好吗？