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

Question

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

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

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

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

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

Answer 1

理想情况下，你有

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

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

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

4. 验证构建是否已正确构建的自动脚本。

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

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

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

Answer 2

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

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

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

Answer 3

打破构建阻止任何依赖于与CI环境相同的标准工具和代码集的用户获得编译和运行系统。

如果您的同事在最新时无法编译系统，因为缺少某些配置，构建会被破坏，不是吗？

如果你的同事不能确信单位测试通过，因为其中一个是片状的，构建被破坏了，不是吗？

如果你有自动化的性能测试，并且你的项目必须进行优化，我会尽可能地说，如果你的代码运行得不够快，你就破坏了构建（但这是有争议的）

对于代码覆盖率或其他指标，我不会那么强烈。

打破构建可能会发生。 CI就是为了确保它在你应该发货的那天不会发生太多的事情;）

Answer 4

对我们来说，只要测试套件在新提交后失败，我们就会使用术语“打破构建”。

所以，在你的实例中，是的，你会破坏构建（至少根据我们公司）

Answer 5

只要你因为一个简单的人为错误（比如忘记提交某些内容）而打破了构建，只要这是一个例外而不是规则，我会说它没问题。只要你注意尽快解决这个问题：）

另一方面，如果某人在作出之前没有在他/她的机器上本地执行完整版本而定期打破构建，那么这是一个不守纪律的团队成员的标志，他们并不真正关心其他团队成员和开发过程。

我的经验是，让人们更加小心的一种有效方法是将CI服务器设置为在（且仅当）构建状态发生变化时发送电子邮件，并使用“罪魁祸首“在To：列表和Cc团队的其他成员：我猜你可以称之为“耻辱因素”;）

Answer 6

破坏的构建是指未通过自动化测试套件的任何内容。

你是一个破坏者。 ;）只要你快速修复它，这不是什么大问题。 CI环境的重点是捕捉错误，而不是让人们害怕犯错。

我的公司构建了每个分支的提示，无论是在生产中还是在下一个生产阶段。我们每次提交都会这样做，每天凌晨4点。我们正在使用Mercurial，因此这里的提交意味着将更改推送到集成存储库。