version-control - 有哪些反对使用持续集成的论据？

Question

我可以想到很多使用它的充分理由；但是，它有什么缺点呢？

（除了购买另一台服务器）

使用每日构建而不是它有什么好处？

Answer 1

（值得注意的是，“持续集成”是指自动集成与自动构建过程并自动运行测试并自动检测每个部分的故障。

还值得注意的是，“持续集成”仅指中继或测试服务器。这并不意味着“推动每一个变化”。

有很多方法可以错误地进行持续集成。）

---

我想不出任何不做持续集成测试的理由。我想我假设“持续集成”包括测试。仅仅因为它编译并不意味着它可以工作。

如果您的构建和/或测​​试需要很长时间，那么持续集成可能会变得昂贵。在这种情况下，在提交之前运行与您的更改明显相关的测试（覆盖分析工具，如Devel::CoverX::Covered可以帮助发现哪些测试与哪些代码一起使用），在提交后使用SVN之类的东西进行集成测试::Notify，并在失败时提醒开发人员。使用类似Smolder的东西存档测试结果。这允许开发人员快速工作，而不必坐在那里观看测试套件的运行，同时仍能及早发现错误。

也就是说，通过一些工作，您通常可以加快构建和测试过程。很多时候，缓慢的测试是由于每个测试都必须进行过多的设置和拆卸，指向一个过于耦合的系统，需要设置整个系统来测试一小部分。

解耦通常会有所帮助，将子系统分解为独立的项目。更小的范围更容易理解和更快的构建和测试。每个提交都可以进行完整的构建和测试，而不会给程序员带来不便。然后可以将所有子项目收集在一起进行集成测试。

在每次提交时运行测试套件的主要优势之一，即使是在提交之后，您也知道是什么破坏了构建。而不是“我们昨天做的事情破坏了构建”，或者更糟糕的是“我们昨天做的四件事以不同的方式破坏了构建，现在我们必须解开它”，而是“修订版 1234 破坏了构建”。您只需检查一个修订版即可发现问题。

进行每日构建的优势在于，至少您知道每天都会进行完整、干净的构建和测试运行。但无论如何你都应该这样做。

Answer 2

我不认为它有任何缺点。但是为了争论，这里是Eric Minick 关于 UrbanCode 的文章 （“这是关于测试而不是构建。”）他批评了基于Martin Fowler 工作的工具，说他们没有给测试留足够的时间。

“要在 CI 中真正取得成功，Fowler 断言构建应该是自我测试的，并且这些测试包括单元测试和端到端测试。同时，构建应该非常快——最好不到十分钟- 因为它应该在每次提交时运行。如果有大量的端到端测试，在构建时执行它们同时将整个过程保持在十分钟以内是不现实的。

在每次提交时添加对构建的需求，并且要求开始变得不可能。选项要么是较慢的反馈，要么是删除一些测试。

Answer 3

James Shore 有很多关于认为使用像 CruiseControl 这样的 CI 工具意味着你在进行持续集成的危险的博客文章：

• 为什么我不喜欢 CruiseControl
• 持续集成是一种态度而不是工具
• 每天一美元的持续集成

设置 CI 服务器的一个危险是目标偏移，认为重要的是“保持构建通过”而不是“确保我们拥有高质量的软件”。所以人们不再关心测试需要多长时间运行。然后他们在签入之前需要很长时间才能运行所有这些。然后构建不断中断。然后构建总是被破坏。所以人们注释掉测试以使构建通过。并且软件的质量下降了，但是，嘿，构建正在通过......

Answer 4

通常有两种情况我认为持续集成没有真正意义。请记住，我是 CI 的大力倡导者，并尽可能使用它。

第一个是投资回报率没有意义的时候。我目前开发了几个小型内部应用程序。这些应用程序通常非常琐碎，开发的整个生命周期大约是一两个星期。为 CI 正确设置一切可能会翻倍，我可能再也看不到这种投资了。您可以争辩说我会在维护中恢复它，但这些应用程序在更新时很可能会被丢弃。请记住，您的工作可能是发布软件，而不是达到 100% 的代码覆盖率。

我听说过的另一种情况是，如果你不打算对结果做任何事情，CI 就没有意义。例如，如果您的软件必须发送给 QA，而 QA 人员只能真正每隔几天查看一个新版本，那么每隔几个小时进行一次构建是没有意义的。如果其他开发人员不打算查看代码指标并尝试改进它们，那么跟踪它们是没有意义的。诚然，这不是 CI 不是一种好的技术的错，而是您的团队缺乏愿意接受 CI 的原因。然而，在这种情况下实施 CI 系统是没有意义的。

Answer 5

开始时，需要一段时间来设置所有内容。

如果您添加测试、覆盖率、静态代码检查、重复搜索、文档构建和部署，可能需要很长时间（数周）才能正确完成。之后，维护构建可能是一个问题。

例如，如果您向解决方案添加测试，您可以让构建根据某些标准自动检测它们，或者您必须手动更新构建设置。自动检测更难正确。覆盖范围相同。与文档生成相同...

Answer 6

不进行持续集成的唯一充分理由是当您的项目工作到您的集成测试在很长一段时间内没有发现任何缺陷并且每次运行它们都花费太多时间时一个构建。换句话说：你已经完成了足够多的持续集成，你已经向自己证明你不再需要它了。