什么是“破坏构建”?“

理想情况下,你有

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

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

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

4. 验证生成是否正确生成的自动脚本。

5. 自动脚本/监控系统,在验证脚本失败时发出警报。

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

但是,由于程序/流程因公司而异,因此可能有其他定义。在某些地方,它可能会破坏单元测试。另外,它可能正在签入源代码,导致代码无法编译。

破坏构建正在提交任何使部署项目不可能(或可能但不明智)的更改。

修复损坏的生成不会修复损坏的生成,但可以创建新的未损坏的生成。

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

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

如果您的同事在系统更新时无法编译系统,因为缺少某些配置,那么构建就中断了,不是吗?

如果你的同事不能确信单元测试通过了,因为其中一个是脆弱的,构建就被破坏了,是吗?

如果您有自动化的性能测试,并且您的项目必须进行优化,那么我也会尽可能地说,如果您的代码运行速度不够快,那么您就破坏了构建(但这是有争议的)。

我不会如此强烈地关注代码覆盖率或其他度量标准。

可能会破坏构建。CI只是为了确保在您应该发货的那一天不会发生太多的事情;)

对于我们来说,每当测试套件在新的提交之后失败时,我们都会使用术语“破坏构建”。

所以,在您的例子中,是的,您可能已经破坏了构建(至少根据我们的公司)

只要你因为一个简单的人为错误(比如忘记提交一些东西)而破坏了构建,并且只要这是一个例外而不是规则,我会说这没关系。只要你能尽快解决这个问题:)

另一方面,如果有人在提交之前不在自己的机器上本地执行完整的构建,而定期中断构建,那么这是一个纪律不严的团队成员的迹象,他实际上并不关心其他团队成员和开发过程。

我的经验是,让人们更加小心的一个有效方法是设置CI服务器,以便在( 只有当 )构建的状态将更改,其中“罪犯”位于to:列表中,团队的其他成员位于cc:中。我想你可以称之为“耻辱因素”;)

破坏的构建是任何不能通过自动化测试套件的东西。

你是个破坏身材的人。;)只要你快点修好就没什么大不了的了。CI环境的关键是捕捉错误,而不是让人们害怕承诺。

我的公司建立了每个分公司的小费,无论是在生产或下一个生产。我们在每一个承诺和每天凌晨4点都这样做。我们使用的是Mercurial,所以这里的提交意味着推动对集成repo的更改。