为什么需要持续集成？

from:http://www.blogjava.net/Jennifer/archive/2011/03/31/347439.html

偶尔想起学生时，几个同学一起做项目，虽然不大，但还是分了模块，每个人负责一个或多个模块。每天打开电脑，从版本控制库更新最新代码，运行下程序，回忆昨天完成的并计划今天的任务。突然发现昨天好好的功能，今天突然不work甚至抛出异常，于是大喊一声谁破坏了我的功能？没人回应，只能自己一步一步查看到底那个代码破坏了昨天的功能，然后找到提交的同学，再商量到底该怎么解决。其实当时我们各自实现自己的模块，写（或不写）测试，然后提交代码，各自只关心和测试自己的模块，难免会发生冲突，尤其是两个模块结合的地方，如果被破坏方可能在几个小时，几天甚至更长时间后发觉应用被破坏，或者直到最后项目上线前一分钟才发觉。。。

后来参加工作，知道了持续集成可以解决当时的痛苦，而且可以提供更多。持续集成是XP实践之一，于是，很多人错误认为持续集成是为了实现敏捷编程的。实际上，早于敏捷编程概念的提出，持续集成作为一个best practice就已经被很多公司采用了，只不过作为一个概念，则是由Martin大叔为了推进敏捷所倡导并由此风靡起来。

那么为什么我们需要持续集成或者说持续集成给我带来了什么好处呢？

• 及早获得系统级的成果或者是可以deploy到production环境的产品。因为代码已经被集成起来了，即使整个系统还不是那么可用，至少比零散的模块让人更有安全感。增强了客户和我们自己的信心。

• 可以很容易的知道每一个版本之间有什么变化，甚至我们可以很容易的重新build出任何一个时间点上的版本，这点非常重要。工作后第一个项目就遇到了难缠的客户，经常今天告知我们明天需要一个版本部署到生产环境，如果没有持续集成，我们如何得到有信心可以部署到production的build？如果没有持续集成，我们如何提供包含最新功能的可以部署到production的build？偶尔，客户并不需要你提供的最终build，而是包含功能1和2而不包含功能3的build，如果没有频繁的持续集成，我们又怎么快速的得到某一时间的build？

• 及早的发现和定位错误：比如学生时代的项目，某个人在工作的时候踩进了别人的领域、影响了别人的代码，而被影响的人还不知道发生了什么，于是bug就出现了。这种bug是最难查的，因为问题不是出在某一个人的领域里，而是出在两个人的交流上面。随着时间的推移，问题会逐渐恶化。通常，在集成阶段出现的bug早在几周甚至几个月之前就已经存在了。结果，开发者需要在集成阶段耗费指数倍的时间和精力来寻找这些bug的根源。如果有了持续集成，当持续集成失败了，很容易说明最新加入的代码或者修改的代码引起了错误，当然这需要强大的自动化测试作为后盾。

• 项目进度的一目了然。频繁的集成使我们可以看到哪些功能可以使用，哪些功能还没有实现。开发人员不用在汇报任务的时候说我完成了多少百分比而烦恼，而PM也不再烦恼程序员说完成了编码的50%到底是个什么概念。

因此引用同事的原话“没有持续集成，说明交付流程是混乱不清晰随机的。”

from:http://xiaozhuwuxin.iteye.com/blog/662669

一些原则：

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。

2. 开发人员每天至少向版本控制库中提交一次代码。

3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

5. 每次构建都要100%通过。

6. 每次构建都可以生成可发布的产品。

7. 修复失败的构建是优先级最高的事情。