破坏建筑,为什么是件坏事?[关闭]

因为如果其他人检查了你的坏更改,他们将无法工作,或者如果他们这样做,他们将这样做效率较低。

它还意味着您在提交之前没有正确地测试您的更改,这是CI中的关键。

在标记“破坏构建”时要非常小心,因为这是一件坏事。它是需要立即关注的东西,但它也是开发周期中非常正常和预期的部分。这就是为什么持续集成如此有用——它会立即告诉您构建何时被破坏,以及是什么变更集导致了它。它能帮助你快速回到正轨。

如果你的文化惩罚“破坏建筑”,那么你就有可能创造一个有毒的工作环境。同样,把它当作需要立即关注的事情,但不要把它贴上“坏”的标签。

来自马丁·福勒 http://martinfowler.com/articles/continuousIntegration.html

使用CI的关键是 你一直在发展 已知稳定基。这不是坏事 主线建设要打破的东西, 但如果一切都发生了 时间表明人们不是 对更新和 在提交之前在本地生成。什么时候? 主线建设确实中断了, 但是,重要的是 固定快速。

因为如果其他人签出更改,他们将无法工作… 此图片版权归Geek&Poke所有,版权归A creative commons license所有。

你打破了昨天发生在我身上的事。当您的团队成员尝试使用源代码时。它不会建造。因此,他们将努力测试他们正在做的工作。你的队伍越大,情况就越糟。

当然,持续集成的关键是尽早发现问题。每天或更频繁的签入需要将冲突减少到可管理的范围。

您应该获得存储库的最新副本并在本地构建。这将告诉您建议的签入是否会破坏生成。解决所有问题,然后签入。

这样,集成问题就保持在本地并且易于解决。

一旦构建开始破裂,人们就不愿意得到最新的变更,而您开始了通向变更的大爆炸集成的致命螺旋。

打破这个结构对项目进度(以及队友的血压)有着可怕的影响。 =>其他获得最新版本的开发人员无法再在那里构建自己的更改,从而延迟了它们 =>持续集成将中断,这意味着正式测试可能会延迟

许多版本控制工具(例如tfs)可以阻止开发人员签入不编译或通过单元或代码分析测试的代码。

我不认为破坏构建必然是一件坏事,只要在存储库中有一个众所周知的工作分支或标记。这就是说,如果您知道您的代码将在今天中断构建,那么就在存储库中创建您自己的分支,但下周您将修复它。然后,您可以合并回主干。

因为这意味着有人做了一些不好的事情(或者至少有些更改发生了冲突),而您不能再构建和部署您的系统。

破坏构建意味着您将代码提交到一个共享存储库,该存储库要么(a)不编译,要么(b)不工作(单元测试失败)。从这个共享存储库开发的任何其他人都必须处理您提交的中断代码,直到它被修复。这将导致整个团队的生产力下降。