1.1. 软件集成中的焦油坑
史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
----摘自《人月神话》
如果一个项目足够小，或者是一个人的项目，对外部系统的依赖很小，那么就不会存在“焦油坑”。然而随着软件工程化的出现，软件项目复杂度的增加，开发团队的大规模化，就会对集成和确保软件组件能够在一起工作提出了更多的要求。
现实是残酷的，软件开发绝非一帆风顺，团队成员代码绝对不会魔术般的自己组合在一起，新的功能加入到原有软件中的时候，往往带来新的臭味，形成了“焦油”，常常导致其他“焦油”的产生，更糟糕的是，这些小“焦油坑”在当时并不能及时被发现，越积越多，最后往往让“巨兽组件”陷入其中。存在的问题有可能到交付前的集成测试的时候才发现，有可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致项目失败。
当小组成员们完成了自己所负责的模块，恐惧地祈祷着“第一场雪”来的晚一些；联调那一天，你爱它、或者你不爱它，它还是来了；似乎姗姗来迟，犹抱琵琶半遮面；然而办公楼还是沸腾了，铃声不断、负责人咆哮着、团队咒骂着、各种服务在呻吟中不断的重启，有“国家免检产品”的美丽谎言的外衣，还是摆脱不了“流产”残局。OMG，居然存在这么大的“焦油坑”，当我们把那些经过测试的组件、脚本、配置项、子项目放进其中，然后看着它们不停的挣扎，开发者也跟着挣扎到项目的失败。一个铁钉影响了整个战局，然后仅仅是一个铁钉的原因吗?(butterfly effect)，当那些喧闹在世界这一边平静下来了，然而这些相似的噩梦和切腹之痛一幕又一幕再上演在世界的其他角落。
当我们憧憬理想中那片净土，美好场景应该是这样的：新代码提交到系统中，我们及时得知是否破坏了原有的功能，然后及时做出决策，修复它。若此过程粒度足够的细、足够地频繁，那么即便是破坏了原有的功能，也是一番“柳暗花明又一村”的美景，每个人都享受着开发过程中那点难忘的小插曲，或许你的手指沾上了“焦油味”，那它一定让你回味无穷，即使你不喜欢这种味道。整个软件过程就是以一个稳步可靠的步伐，持续增量的向前行进，而不是不断地加入新的代码，然后等到后来“焦油坑”被人发现的时候被动地去清除它。
1.2. 持续集成定义大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
“持续集成”起源于极限编程开发，是它的12个基本原则之一。“持续集成”是一种软件开发实践；它要求开发小组的每个成员频繁的集成他们的工作成果。这个频度通常是至少每天一次有时甚至每天多次开发团队的成员频繁的整合他们之问的工作；这种整合不是简单的组装软件每次的集成通过一个包含测试的构建去尽快的探测潜在的错误；保证软件现有的功能不被破坏，自动分析现有代码的状态有无重复逻辑、代码的复杂度等)并发布相关的报告。通过快速反馈，开发人员可以了解软件集成的情况.对不成功的集成进行快速的修改；从而提高软件开发的效率和质量。
1.3. 持续集成的价值 1.3.1 持续集成对项目管理的作用1. 对项目目标、进度、质量管理的作用软件项目的目标是开发出可运行的、客户满意的软件系统。持续集成有统一的代码库；要求开发人员定期地、不断地向代码库提交代码；新近提交的代码会经过编译与测试，与代码库中旧有的代码相整合，形成安全稳定运行的代码库，即软件产品。
手动构建过程降低了团队的生产率，也给构建过程带来了不确定的隐患，使得发现和解决“焦油坑”变的异常艰难。使用持续集成工具将构建过程自动化；便于分析并找出问题。大大提高了团队的开发效率。稳定而高效的开发效率保证开发团队在一个轻松愉快的环境中工作。团队成员有更多的时问和精力学习新技术并将其应用在软件开发中；自动化测试，集成将开发人员从简单、繁琐的低级脑力劳动中解放出来，从而进行更高层次的思考持续集成的自动构建过程。
持续集成过程要求编程人员事先编写好很多的测试用例。在代码的提交过程中就对代码进行测试；这样的及早测试能够快速地发现软件代码中的错误和缺陷，及时修改，从而提高软件的质量。这些测试包括：单元测试、功能测试、集成测试，进行部署；持续集成要求有一个全面的单元测试验证集。使持续集成能够获得短集成周期。然而，在持续集成过程中，编写测试代码是必要的，而且这样也省去了人工测试的时间；确保了软件产品的质量，对软件项目的质量管理有利。
2. 对项目风险、人力资源管理的作用与开发人员的机器相比，持续集成服务器运行在相对稳定、干净的环境中减小跟踪调试的难度)，持续集成过程的失败通常意味着最近一次更新破坏了软件现有功能或引入了新的缺陷。这种快速反馈集成结果.并进行快速修改的工作方式.在第一时间消除了代码中的Bug.极大地减小了系统发生错误、不能在用户环境中运行、系统集成时涌现大量问题的风险。
软件开发过程最终表现为人与人之间各种形式的合作。安全感与信心是合作最基本也是最重要的部分。持续集成所做的是加强了团队成员的沟通，项目中的所有人都知道系统现在的状态、目前已经做了那些变动。沟通中最重要的一件事是主线的构建状态。持续集成会告诉你构建的状态和上次主线构建的状态。将构建的结果反馈的形式很多，红绿灯、网站发布构建结果；不在一起工作的人也能看到目前项目的状态这样的工作方式使团队成员及时了解项目情况。得到及时、准确的沟通，可以增强团队成员的安全感和信心，使团队在一个好的氛围中工作。
3. 对产品市场和客户的作用一个可以稳定运行的软件系统才是最重要的。没有使用持续集成工具的环境中，大量的问题只有在产品发布前进行最终集成的时候才会出现；开发团队往往在发布前承受着巨大的压力.并导致产品延迟发布或者在进行集成的过程中引入更多、更严重的缺陷。在使用持续集成工具的环境中，开发人员对源文件进行修改、提交.持续集成服务器会将这部分修改与其他的代码进行整合、测试。并重新生成最终发布产品。
客户看到通过持续集成的频繁部署的结果.很快的看到软件系统的新特性.然后针对这些特性迅速反馈；开发者可以根据这些反馈进行后续的开发在这样的开发过程中，开发者和客户得到很好的沟通，客户能够经常地看到实现的产品；融洽了客户关系；增强了客户的满意度客户的满意是项目最终成功的重要标志之一。
4. 对项目软件配置管理的作用把一个项目所有的源代码都保存在一个仓库里，系统的当前状态始终是最新提交的代码；持续集成项目组都使用代码仓库，而且代码仓库中不仅有代码，还要求要把什么都放在代码仓库里，构建唯一的代码仓库。把用于构建的东西都放到里面去：测试脚本、属性文件、数据库、安装脚本和其他库文件等等。这样做的好处是保证了代码仓库的完整性和有效性。为持续集成的构建做好准备。这样的代码库的工作方式，为软件的配置管理提供了极大的方便。
1.3.2 对开发者的意义1.减少开发风险、重复过程一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况，减少开发风险。 减少重复的过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及反馈。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多的投入到动脑筋的、更高价值的事情上。
2. 重构代码，生成可部署的软件持续集成每次构建过程中，我们得到一些反馈信息，使用工具插件随时观察我们的代码，并快速找到相似功能、模块，重构那些代码中出现的异味，检入到代码仓库中，然后循环这些个过程，使得我们的代码简洁、易懂、稳定，也为将来软件重用做了很好的铺垫。持续集成可以让开发者在任何时间发布可以部署的软件；对于客户来说，可以部署的软件产品是最实际的资产。
