我认为持续集成最显著也最广泛的益处是降低风险。说到这里，我的脑海中还是会浮现出第一段描述的早期软件项目。他们已经到了一个漫长项目的末期（至少他们期望如此），但还是不知道距离真正的结束有多远。 延迟集成的问题在于时间难以估计，你甚至无法得知你的进展。结果是你在项目最紧张的阶段之一把自己置入了一个盲区，此时即使没有拖延（这很罕见）也轻松不了多少。 持续集成巧妙的解决了这个问题。长时间的集成不再存在，盲区被彻底消除了。在任何时间你都知道你自己的进展，什么能运转，什么不能运转，你系统里有什么明显的 bug，这些都一目了然。 Bug 让人恶心，它摧毁人的自信，搞乱时间表，还破坏团队形象。已部署软件里的 bug 招致用户的怒气。未完成软件里的 bug 让你接下来的开发工作受阻。 持续集成不能防止 bug 的产生，但它能明显让寻找和修改 bug 的工作变简单。从这个方面看，它更像自测试代码。如果你引入 bug 后能很快发现，改正也会简单得多。因为你只改了系统中很小的一部分，你无需看很多代码就能找到问题所在。因为这一小部分你刚刚改过，你的记忆还很新鲜，也会让找 bug 的工作简单不少。你还可以用[差异调试](http://www.martinfowler.com/bliki/DiffDebugging.html)——比较当前版本和之前没有 bug 的版本。 Bug 也会积累。你的 bug 越多，解决掉任何一个都会越困难。这部分原因是 bug 之间的互相作用，你看到的失败实际上是多个问题叠加的结果，这使得检查其中任何一个问题都更加困难。还有部分原因是心理层面的因素，当人们面对大量 bug 时，他们寻找和解决 bug 的动力就会减弱。《Pragmatic Programmer》一书中称之为“[破窗综合症](http://www.amazon.com/exec/obidos/ASIN/020161622X)“。 使用持续集成的项目的通常结果是 bug 数目明显更少，不管在产品里还是开发过程中都是如此。然而，我必须强调，你受益的程度跟你测试的完善程度直接相关。其实建立测试系统并非想象中那么困难，但带来的区别却显而易见。一般来说，团队需要花一定时间才能把 bug 数量减少到理想的地步。做到这一点意味着不断添加和改进测试代码。 如果你用了持续集成，你就解决了频繁部署的最大障碍之一。频繁部署很有价值，因为它可以让你的用户尽快用到新功能，从而快速提供反馈，这样他们在开发过程中可以有更多的互动。这可以帮助打破我心目中成功的软件开发最大的障碍——客户与开发团队之间的障碍。