有没有CI工具可以保证分支质量不会下降？

传统上，CI系统仅通过对已提交更改的代码库执行QA验证，监视回归并发送人工干预通知，来对集成分支中的质量级别进行监视。

但是，当检测到这些回归时，分支机构至少在各自的QA验证开始后就已经陷入麻烦，并且将一直处于这种状态（甚至变得更糟！），直到所有罪魁祸首被发现，对其进行了修复并进行了新的QA验证确认分支质量级别已恢复。在所有这些时间里，分支可以被视为正常开发被阻塞。

是否有一个CI工具能够实际防止这种回归的发生，该工具将执行提交前的 QA验证，并且仅当使用相应提交更新的代码库也将通过那些提交前的QA验证时才允许提交。分公司质量水平？

更新：假设CI工具可以调用具有适当覆盖范围的适当的自动QA验证，以能够检测相应的回归。

据我所知，您正在寻找一种工具，该工具将拒绝破坏构建的提交-CI工具可能无法通过实际修复代码来防止回归，但它可能会阻止您添加错误的代码到存储库。

Atlassian有一些有趣的Git钩子应用程序：

服务器端预接收挂钩是对持续集成的一个特别有力的补充，因为它们可以阻止开发人员将代码推送到母版中，除非代码满足某些条件（例如精英​​忍者守护者），以保护其免受不良代码的侵害。

如果您使用的是Git，则挂钩非常强大（并且SVN，Mercurial和其他版本控制系统也有类似的挂钩），并且使用它们来运行提交前检查可能会很有用。

Git的文档对创建一个钩子拒绝推送，如果他们不符合一定条件的页面可能很容易地适应这个用例。

但是，很多人会认为拒绝提交对分支机构来说不是一个好主意feature –当构建由于某种原因而中断时，您只是在浪费时间与CI系统进行战斗，而不是真正地修复错误。

在master分支上，拒绝残破的合并可能很有意义，因为您可能要确保它始终在构建。对于一个feature分支，你将不可避免地打破的东西，因为代码不会投入生产，现在，它更有意义只是为了提醒你比实际拒绝你一起提交。

没有任何工具可以保证不进行回归-与执行测试的工具相比，这更多地取决于测试。但是，您可以帮助防止捕获的回归数据进入积分分支。您可以使用预提交的挂钩进行此操作，但是使用拉取请求通常会更容易（希望您已经将其用于对等代码审查）。

如果分支的上游是最新的（PR合并到该分支），并且其测试通过，则合并后它们仍将通过；否则，分支将通过。合并后目标分支的状态将与合并前源分支的状态匹配。

通常，指出PR中的源分支是否与目标保持最新以及是否具有通过的CI构建（这取决于所使用的工具）通常并不特别困难。您可以将此作为合并拉取请求的要求（根据策略和/或在软件中强制执行）。

像Reitveld和Zuul这样的真正的持续集成工具（而不是连续测试）可以提供帮助，尽管它们仅与您编写的测试和代码审查一样好。

使用GitLAB，您可以在项目设置中进行设置，以仅在管道成功时才允许合并，因此可以进行真正的持续集成，并通过将QA添加到合并批准列表中以及与Dynamic Environments相结合，可以保证质量在您合并到母版之前。

ApartCI是一个CI系统，旨在防止回归，从而确保平坦或提高分支质量水平。仍处于测试阶段。

它以某种方式编排集中的预提交验证，以确保仅在更改经过验证之后才提交更改，以及在此之前提交的所有其他更改，以达到或超过最新的分支机构质量水平。

与通常由开发人员驱动的提交前验证（通常并行执行）相比，这是关键的区别，这为因干扰的变化（从未一起测试）导致的回归留有空间。

该工具还设计为易于扩展 -能够维持很高的传入候选更改率，并支持在同一集成分支中工作的100/1000开发人员。

免责声明：我是该工具的作者和提供该工具的公司的创始人。对广告表示歉意。