一切即代码：高质量持续集成之道

立志做国内自动化/AI测试领域最好的原创公众号。欢迎微信关注公号"测试不将就"(ID: awesometest)，更多原创文章在路上。我们的口号是：“插上自动化/AI的翅膀，软件测试也能高大上”，同时会发布关于Python开发, 持续集成等精彩文章。

作者：肖哥，资深码农/技术写作者，欢迎添加作者微信(slxiaozju)交流。

PART 1: 背景

持续集成(Continuous Integration, CI)存在的意义，是发现代码改动(Gerrit ticket/Gitlab MR/Github PR, etc.)所包含的软件问题(Bug)，并阻止这些有问题的代码改动合入代码主干(Master)。

CI由一系列任务(例如，Jenkins Job)组成。一般来说，只有所有任务都成功了，代码改动才能通过验证。任何一个任务的失败，都会导致代码改动无法提交。

然而，这样的CI规则基于的是一个潜在的假设，那就是：如果CI任务失败，那么失败一定是由触发这次任务的代码改动造成的。

显然，这种假设是过于理想化的，在实践中经常并不成立。因为CI是一个系统，被测软件(测试对象)只是CI的组成部分，而不是CI的全部。CI的失败，完全可能是由被测对象之外的因素导致的。

我们通常用“稳定性”(Stability)来衡量CI在判断代码改动是否有问题时的表现。对于一个稳定性足够高的CI来说，当代码改动没有问题时，它能够稳定地成功；而当代码改动有问题时，它又能够稳定地失败。这是目标。

虽然CI的稳定性受多方面因素制约。但是对于CI工程师来说，提高CI自身(即被测软件之外的部分)的质量(Quality)，是一件自主可控的，能够促进CI整体更稳定的事情。

然而