version-control - 究竟是什么被认为是 "breaking the build?"

Question

在 CI 环境中，究竟什么是损坏的构建？

我可以想象有几个答案(编译、测试通过、指标在范围内、文档存在等的任何组合)，但我不确定其中哪些是规范的。

例如，就在今天发生在我身上，我实际上 checkin 了所有代码更改，但忘记提交 Visual Studio 项目文件，从而破坏了单元测试。 (尽管我确实三次检查了我的提交，因为它是谷歌代码上的一个公共(public) OSS 项目)。

在我第一次提交后，我很容易在不到一分钟的时间内解决了这个问题，但我现在应该认为自己是一个破坏者吗？

您如何配置 CI 环境:是每个版本都构建还是仅在每个完整构建之后的最新版本，或者您使用基于时间的新版本检查？

Answer 1

理想情况下，您有

计划在每晚运行以从源代码构建应用程序的自动化脚本。

用于将二进制文件复制到目录/目录集的脚本，如果应用程序在您的环境中运行，或者用于为客户创建可交付成果，则可以从中运行另一个脚本来部署应用程序。

运行并验证所有组件通过所有测试的自动化测试套件。

验证构建是否正确构建的自动化脚本。

如果验证脚本失败，自动脚本/监控系统会发出警报。

当上述过程生成警报时，这被认为是“破坏构建”。

但由于程序/流程可能因公司而异，因此可能会有不同的定义。在某些地方，它可能会破坏单元测试。其他人可能正在检查导致代码无法编译的源代码。