在 CI 环境中，究竟什么是损坏的构建？
我可以想象有几个答案（编译、测试通过、指标在范围内、文档存在等的任何组合），但我不确定其中哪些是规范的。
例如，就在我今天碰巧签入了所有代码更改，但忘记提交 Visual Studio 项目文件，从而破坏了单元测试。 （尽管我确实三次检查了我的提交，因为它是谷歌代码上的一个公共 OSS 项目）。
我在第一次提交后不到一分钟就轻松解决了这个问题，但我现在应该认为自己是一个构建破坏者吗？
您如何配置您的 CI 环境：是每个版本都构建还是在每个完整构建之后只构建最新版本，或者您是否使用基于时间的新版本检查？
【问题讨论】：
标签： version-control build-process continuous-integration
理想情况下，你有
计划在每晚运行以从源代码构建应用程序的自动化脚本。
用于将二进制文件复制到一个目录/目录集的脚本，如果应用程序在您的环境中运行，或者用于为客户创建可交付成果，则可以从中运行另一个脚本来部署应用程序。
运行并验证所有组件通过所有测试的自动化测试套件。
验证构建是否正确构建的自动化脚本。
自动脚本/监控系统，在验证脚本失败时发出警报。
当上述过程生成警报时，这被认为是“破坏构建”。
但由于程序/流程可能因公司而异，因此可能会有不同的定义。在某些地方，它可能会破坏单元测试。其他的可能是检查源代码导致代码无法编译。
【讨论】：
破坏构建是指提交任何使项目无法（或可能但不明智）部署的更改。
修复损坏的构建不会修复损坏的构建，但可以创建新的非损坏构建。
我将我的 CI 服务器配置为在每次提交时创建一个最小构建，并在每个时间段创建一个最大构建。周期取决于参与项目的人数（更多人提交更多）和构建持续时间（您可以每次运行单元测试套件，但 30 分钟的验收测试套件每天一次或两次）。
【讨论】：
破坏构建会阻止任何依赖与 CI 环境相同的标准工具和代码集的用户来获得编译和运行系统。
如果您的同事在更新时无法编译系统，因为缺少某些配置，则构建已损坏，不是吗？
如果你的同事不能确信单元测试通过了，因为其中一个是不稳定的，那么构建就被破坏了，不是吗？
如果您进行了自动化性能测试，并且您的项目必须进行优化，我想说的是，如果您的代码运行速度不够快，那么您已经破坏了构建（但这是有争议的)
我不会那么强烈地关注代码覆盖率或其他指标。
可能会破坏构建。 CI 只是为了确保它不会在你应该发货的那一天发生太多;)
【讨论】：
对我们来说，每当新提交后测试套件失败时，我们都会使用“破坏构建”一词。
所以，在你的例子中，是的，你会破坏构建（至少根据我们公司的说法）
【讨论】：
只要您因为简单的人为错误（例如忘记提交某事）而中断构建，并且只要这是例外而不是规则，我会说没关系。只要你注意快速解决这个问题:)
另一方面，如果有人在提交之前没有在他/她的机器上本地执行完整的构建而定期破坏构建，那么这表明团队成员纪律不严，并不真正关心其他团队成员和开发过程。
我的经验是，让人们更加小心的一种有效方法是设置您的 CI 服务器，以便在（且仅当）构建状态发生更改时发送电子邮件，并带有“罪魁祸首”在收件人：列表和抄送团队的其他成员：。我想你可以称之为“耻辱因素”；）
【讨论】：
一个损坏的构建是没有通过自动化测试套件的任何东西。
你是一个构建破坏者。 ;) 只要您快速修复它，这并不是什么大问题。 CI 环境的全部意义在于捕捉错误，而不是让人们害怕提交。
我的公司构建了每个正在生产或即将投入生产的分支的尖端。我们在每次提交和每天凌晨 4 点执行此操作。我们使用的是 Mercurial，因此这里的提交意味着将更改推送到集成存储库。
【讨论】：