究竟什么被认为是"破坏构建？"

Question

在CI环境中,究竟什么是破坏的构建？

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

例如,就在今天,我碰巧在实际检查了所有代码更改但忘记提交Visual Studio项目文件,从而破坏了单元测试.(尽管我确实三重检查了我的提交,因为它是谷歌代码上的公共OSS项目).

我在第一次提交后不到一分钟就能轻松解决这个问题,但我现在应该认为自己是一个破坏者吗？

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

Answer 1

理想情况下,你有

1. 自动脚本,计划每晚运行以从源代码构建应用程序.

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

3. 运行并验证所有组件的自动化测试套件都通过了所有测试.

4. 自动脚本,用于验证构建是否已正确构建.

5. 自动脚本/监控系统,如果验证脚本失败,则会发出警报.

当上述过程生成警报时,则认为是"破坏构建".

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

Answer 2

打破构建会提交任何使得无法(或可能但不聪明)部署项目的更改.

修复损坏的构建不会修复损坏的构建,但可以创建新的非破坏构建.

我将CI服务器配置为在每次提交时创建最小构建,并在每个时间段创建最大构建.这段时间取决于项目工作人员(更多人提交更多)和构建持续时间(您可以每次运行单元测试套件,但每天运行30分钟验收测试套件一次或两次).