有什么理由反对使用持续集成？

我可以想到使用它的充分理由; 但是,它的缺点是什么？

(除了购买另一台服务器)

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

(值得注意的是,通过"持续集成",我指的是与自动构建过程的自动集成,并自动运行测试并自动检测每个部分的故障.

值得注意的是,"持续集成"仅仅意味着中继或测试服务器.这并不意味着"推动所有变革".

有很多方法可以做错误的持续集成.)

我想不出有任何理由不进行持续集成测试.我想我假设"持续集成"包括测试.仅仅因为它编译并不意味着它有效.

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

也就是说,通过一些工作,您通常可以加快构建和测试过程.很多时候,慢速测试是由于每次测试都需要做太多的设置和拆卸,指向一个太过耦合的系统,需要整个系统设置只是为了测试一小块.

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

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

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

我不认为它有任何缺点.但是为了争论,这里是Eric Minick关于UrbanCode的文章 ("这是关于测试而不是构建.")他批评了基于Martin Fowler工作的工具,说他们没有足够的时间进行测试.

"为了真正成功实现CI,Fowler断言构建应该是自我测试,并且这些测试包括单元测试和端到端测试.同时,构建应该非常快 - 理想情况下不到十分钟- 因为它应该在每次提交时运行.如果有大量的端到端测试,在构建时执行它们同时将整个过程保持在十分钟之内是不现实的.

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

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

为什么我不喜欢CruiseControl

持续集成是一种态度而非工具

每天持续整合一美元

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