_徐萌_信息科学与工程学院_电子与通信工程

1、 文本复制检测报告单(全文标明引文)检测文献:作者:检测范围:21110233023_徐萌_信息科学与工程学院_电子与通信工程徐萌 中国学术期刊网络出版总库 中国博士学位论文全文数据库/中国优秀硕士学位论文全文数据库中国重要会议论文全文数据库 中国重要报纸全文数据库中国专利全文数据库 互联网资源 英文数据库(涵盖期刊、博硕、会议的英文数据以及德国Springer、英国Taylor&Francis 台学术文献库 优先出版文献库互联网文档资源个人比对库 1900-01-01至2013-03-24 期刊数据库等)时间范围:可能已提前检测，检测时间：2013-3-16 14:25:07，检测结果：8.

2、1%1. 21110233023_徐萌_信息科学与工程学院_电子与通信工程_第1部分总字数：6024文字复制比：14.7%(884)(0)1持续集成在现代软件开发中的应用与研究6.3%徐仕成(导师：杨邦荣) - 中南大学硕士论文- 2007-05-01是否引证：是2基于变更管理的持续集成研究与应用6.3%相(导师：袁兆山) - 合肥工业大学硕士论文- 2009-04-01是否引证：是3基于AOP的集成测试方法研究及其在信息科研系统持续集成中的应用4.8%康乃元(导师：徐建良) - 中国海洋大学硕士论文- 2010-04-15是否引证：是4基于MIPS的嵌入式Linux系统开发环境的设计与实现2

3、.3%邱烽(导师：王东;林贵旭) - 上海交通大学硕士论文- 2011-06-01是否引证：否5自动化测试平台Safe的设计与实现2.0%白赫鹏(导师：王方石) - 北京交通大学硕士论文- 2011-06-01是否引证：否6基于TeamCity的Web项目持续集成方案2.0%李婧; - 软件导刊- 2009-08-30是否引证：否- 1 -总文字复制比：4%去除引用文献复制比：0.6%去除本人已发表文献复制比：4% 单篇最大文字复制比：1.5% 重复字数： 1033 总字数： 25552单篇最大重复字数： 381 总段落数： 3前部重合字数：951疑似段落最大重合字数：884 疑似段落数：3后

4、部重合字数：82疑似段落最小重合字数：67 指标：剽窃观点 自我剽窃一稿多投过度引用整体剽窃重复发表剽窃文字表述 表格：0脚注与尾注：48 14.7%（884）21110233023_徐萌_信息科学与工程学院_电子与通信工程_第1部分（总6024字） 0.6%（67）21110233023_徐萌_信息科学与工程学院_电子与通信工程_第2部分（总10904字） 1%（82）21110233023_徐萌_信息科学与工程学院_电子与通信工程_第3部分（总8624字） （注释：无问题部分文字复制比部分引用部分） ADBD2013R_20130324124531201303241248062005568

5、73813检测时间：2013-03-24 12:48:06 1引言 1.1课题研究背景 软件信息业的蒸蒸日上，使得电子软件被社会的各个领域所广泛应用，而软件产品的质量也就毋庸置疑的成为了人们非常在意的重要因素。实际上，对于软件来讲，无论在开发的过程中应用了什么样的方法或技术，在最终的软件产品中都会出现一些错误或者缺陷。也许随着开发技术的进步、开发语言的逐步升级、开发方式慢慢的进步，软件产品的质量会越来越好，但是想要完全修复软件中的错误也是不可能的。因此，软件的发展永远也不能达到人们对软件的要求水平，而这些产生的错误也就需要软件测试过程来发现，测试能够决定一个软件项目的质量。国外很多公司对软件测

6、试都非常的重视，尤其是美国著名的微软公司，他们在开发软件的过程中，测试人员的数量一般情况是开发人员的1.5倍到2.5倍左右，表1-1是微软公司在开发Exchange 2000和Windows 2000时的人员配置情况。 表1-1 美国微软公司软件测试人员分布 随着软件测试理论以及应用研究工作的不断深入，软件测试也逐渐的经历了以下的好几个发展历程，每一个发展阶段也代表了软件测试慢慢走向成熟： 1. 20世纪60年代，在软件工程建立前，测试是为了证明程序开发的正确性。 2. 20世纪70年代，产生了Ad-hoc testing，意思是测试者一边测试一边设计测试的内容，没有在测试之前建立完整的计划和

7、测试周期表，也并不对测试结果进行记录和保存，因此那时的测试不能保证准确性，与前期的调试并没有很大的区别。 3. 1979年， Glenford Myers的The Art of Software Testing，对测试重新进行了定义，他认为软件测试过程是一个程序或者系统，目标是为了发现缺陷和错误。 4. 20世纪80年代初期，软件测试开始着重于质量，其内涵也变得有所不同，表明软件测试不只是一个发现错误的过程 ，还应该包括评估软件质量和功能的一个大范围，同时也制定了一些软件测试标准。 5. 20世纪90年代后期，软件开发人员开始关注一些过程管理对于软件测试的影响，形成了各种测试模型，也标志着测试

8、能力在慢慢走向成熟。 6. 进入21世纪，人们越来越认识到了软件测试的重要性，甚至掀起了软件开发工作应该要以软件测试为主要内容的思潮 。 在经历了这些发展阶段之后，针对不同的发展阶段，软件测试的含义和涵盖范围都在不断的发生着变化。而软件测试不仅仅是找错而已，还需要有计划的进行，而且越早的发现软件的错误，花费的成本也就越低。 软件测试分为很多类型，比如，按照测试的对象来分包括单元测试、集成测试、系统测试和验收测试。根据每一个测试的流程和阶段都要使用不一样的测试工具或者系统，而且还需要随时对其进行维护。在软件测试阶段，集成测试是其中的重要一步，它是在单元测试完成之后进行的，作用是保证软件系统中各个

9、模块能够正常衔接工作的重要阶段，还能弥补单元测试过程中无法完成的工作。集成测试开始的越早，故障发现的就越早，消除故障的成本就会减少。但是在软件开发过程中遇到的主要风险也是在集成问题上，许多软件开发项目的最终失败都是因为在最后集成时出现问题。 持续集成的出现解决了上述的问题，它是伴随着敏捷软件开发而建立的，现在已经被大部分的软件企业的开发团队所接受，但是它的价值并没有真正的体现出来，原因是开发者缺乏对持续集成系统的了解，而开发团队又很少有能在应用持续集成时出现问题的解决方法和经验，因此，对持续集成的研究就从未停止过。 1.2课题研究现状及意义 Kent Beck在1996年提出了极限编程，也就是

10、大家所熟知的XP的概念，他在 Extreme Programming Explained: Embrace Change（解析极限编程拥抱变化）一书中阐述了极限编程的12个最佳实践，持续集成在初期时就是开始于XP中的12个最佳实践之一。尽管Kent Beck提出了持续集成这个概念，但是因为XP刚开始并没有受到业内的普遍认可，很多人对此集成方法产生质疑，并且他在书中也仅仅是提出了实践持续集成的大概思想，并且他当时提出的方法在极限编程思想的基础上，他认为采用持续集成实践必须在XP的软件开发模式的环境下进行，但是在那个环境下软件行业的开发者们还都不太能够接受和认可极限编程开发模式，因此，大家对持续集

11、成的误解也由此产生。 2000年，ThoughtWorks公司的首席科学家同时也是极限编程思想的发起者之一的Martin Fowler以“Continuous Integration（持续集成）”为题写了一篇享誉业内的文章，他将持续集成描述为：持续集成是一种软件开发实践，即团队的成员们经常集成他们的工作，每个成员每天至少集成一次，这导致每天发生多次集成。每次集成都通过自动化的构建（包括- 2 -一种敏捷的Web软件快速开发工具的设计与实现 汪滟(导师：程文青) - 华中科技大学硕士论文- 2007-06-01 1.2% 是否引证：否 8 快速原型法在软件开发中的应用 1.2% 梅灿华,孟庆全

12、- 淮南职业技术学院学报- 2003-02-15 是否引证：否 9 极限编程研究与应用 0.9% 王向阳(导师：陈珉) - 武汉大学硕士论文- 2004-05-08 是否引证：是 10 基于极限编程方法的教育软件项目开发 0.6% 汪灏;陈丹敏;杨建豪; - 软件导刊- 2012-03-31 是否引证：否 原文内容 7 测试）来验证，从而尽快检测出集成错误。许多团队发现这个过程会大大减少集成问题，让团队更够更快地开发内聚的软件 。他是在Thoughtworks公司软件项目持续集成实践的基础上详细介绍了持续集成实践的应用。他了Kent Beck的一部分观点，并且认为就算是不采用采用极限编程的开发

13、模式，应用持续集成实践模式来进行软件的开发和管理都是有必要的。不过他只是在文章当中提到了要实现持续集成所需要的几个重点问题以及其基础的理论，并没有说明如何来实现这些实践。这篇文章的出现并流行，让持续集成的价值慢慢被发现和认可，但是在实际项目中如何真正使用持续集成方式，还是存在着很多问题 。 国外的软件企业相比于我们国家对持续集成的研究和应用开始较早，大部分的大型软件公司都陆续研制出了符合自己软件开发模式的持续集成工具和产品。例如Thoughtworks公司就推出了它的CruiseControl系列持续集成专用工具，该工具的诞生很大程度上推进了持续集成研究领域的发展。虽然我国对于持续集成的应用研

14、究也在慢慢进步，但是相比于发达国家，还有比较大的差距。中国敏捷软件开发大会（AgileChina）一直把持续集成作为讨论的热门话题，但是集中以发表出现的问题为主，很少有切实可行的解决方案。此外，国际软件组织定期都会举行Continuous Integration and Testing Conference（持续集成和测试会议），主题就是有关持续集成的研究和应用，并且从2007年起每年都会举行，在会议中有许多项目都得到了很大的进展。Jesper Holck和 Niles Jorgensen就指出了：“持续集成的应用为FreeBSD和Mozilia这两个大型的软件项目提供了很好的质量保证”。 目

15、前，持续集成已经应用到了全球85%以上的软件开发项目中。例如，微软公司在拥有上百万甚至上千万的代码的软件开发项目中仍然能够每天都做持续集成，这也就证明了持续集成是非常有价值而且重要的。 在互联网行业，软件更新换代的非常快，不断变化的软件开发模式下，每一个软件开发公司都想赶在行业内发布自己的最新产品，时间就是金钱，怎样在最短的开发周期内就能开发出最优秀的产品、获得更多用户的信赖和喜欢成为了互联网企业追求的目标。现如今国内外比较大型的开发公司如Google、百度、阿里巴巴等，都引入持续集成方法以此来降低软件开发过程中的风险以及不断改进和提高软件的质量。 Google是互联网公司中的龙头老大，同时它

16、的持续集成技术也是行业的领先者。谷歌公司有着很强大的自动化测试设施来确保软件开发过程中集成测试阶段的顺利进行，而且也减少了测试人员在部署、运行、分析测试结果等方面的工作量和精力 ，能把更多的时间放在开发上，提升软件开发效率，谷歌公司也在不断的升级持续集成系统以更好的改善其功能。 百度在国内的互联网公司中属于佼佼者，它在2009年开始实施敏捷开发实践，2010年在各个产品开发项目中普及持续集成模式，获得了很大的成效。在持续集成过程中建立一套完整可靠的产品发布流程，力争对每一个测试阶段都实现自动化，对所有阶段进行严格的版本控制，开发团队每一个成员都要对自己提交的变更负责任，并且以同样的方式进行各种

17、环境部署，并对次系统不断的更新改进，通过持续集成建立一条全自动的测试流水线。自从引入持续集成后，百度公司的产品发布周期也缩短了很多，由引入前的九天减少为三天，极大程度的缩减了测试周期和人工的耗时如图1-1。 图1-1 百度公司引入持续集成前后对比图1.3课题来源 本课题是源于笔者在海信传媒网络技术实习期间遇到的软件开发中的问题： 1. 集成时间滞后带来缺陷修复成本较大 在实际项目开发的最开始阶段，就会有很多问题，但是往往却是到最后集成时才会发现问题，大部分的软件项目都是大型复杂的，就会导致开发人员一般要花大量的时间和精力来寻找项目中的问题和Bug的根源所在，就算是顺利的找到了原因出在什么地方，

18、最后都会由于涉及了很多的模块和功能，需要对软件整个系统做出更改，这个过程不仅会浪费开发人员的时间也会导致项目无法按期完成，造成巨大的经济损失。根据行业经验，如果在编码阶段Bug的修复成本为1，那么在软件提交上线之后，修复Bug的成本就将达到401000！Bug发现的越晚，修复成本越大。 2. 集成次数有限带来缺陷不能充分暴露 在目前海信传媒的整个软件开发过程中，集成的次数往往只有一次，即仅仅在各模块编码结束之后才进行一次集成，由此带来的问题就是由于模块间有着很强的交互性，软件的Bug不能被充分暴露出来。 以传媒公司的SmartTV3.4项目为例，在项目研发过程中，软件质量是通过文档评审（Doc

19、ument Review）-代码走查 （Code Review）-单元测试（UT）-集成测试（LIT）-系统测试（SIT）各个阶段来保障的。如图1-2所示，在项目前期，经过文档评审（Document Review）、代码走查（Code Review）和单元测试（UT），大约48%的Bug已经在前期被修复。但是仍然有32%的Bug在后期的集成测试阶段（LIT）才被发现。这正是由于各模块在提交LIT之前缺少必要的集成导致的，如果能够在开发阶段尽早集成、进行多次的集成，那么就可以完全充分的认识到软件存在的问题。 图1-2 海信传媒公司软件开发各阶段的Bug比例图 3. 集成测试完全依靠手工致使效率低

20、下 在公司项目开发的过程中，一方面，研发部门对于软件产品的版本质量控制不够，导致前期的UT测试、CodeView不充分 ，导致在集成测试阶段发现大量的问题；另一方面，研发内部对于版本没有控制的手段，导致版本发布频繁。这就给集成测试部门带来了极大的测试压力。由于目前的集成测试大部分依赖于手工完成，因此测试部门就需要全员投入，往往需要加班才能完成测试任务，人员的高负荷投入也使得测试过程中出现错误和忽略错误的几率增大。 以公司的SmartTV3.22项目为例，EPG（电子节目菜单）在一周之内总共提交了9个版本，每提交一次版本就需要对大约 - 3 - 100条测试用例进行一归测试，在短时间内需要所有的

21、测试工程师进行大量和反复的手工测试，造成测试人员苦不堪言。 4. 现有集成模式带来开发进度不可控 由于在现有软件开发过程中把模块集成和集成测试置于整个项目开发周期的相对靠后阶段，因此在没有进行集成测试时 ，开发人员对整个项目的开发进度和状况都不是很清楚，一般都是由每个团队成员自己估计完成的百分比，但是这种估计肯定是不完全准确的，就会给项目带来很大的风险。 目前传媒公司几乎所有的项目采用的都是瀑布式的开发模式，这种瀑布式的开发模式实际上是一种顺序模式，它将软件开发的每一个阶段都严格划分，并要求在开始下一阶段的工作之前必须完成上一阶段的所有工作，各阶段之间存在严格的顺序性和依赖性。 在软件开发的流

22、程中，集成测试是影响项目质量的一个重要因素。瀑布集成是在编码完全结束之后才开始，处于整个开发周期相对靠后的阶段，一旦集成测试中发现Bug，需逐级回溯来重新确认。而且目前项目的开发人员都是各自独立工作，集成测试是最后所有开发人员把每一个模块的全部代码提交后才进行的，这种方法可以适用于比较简单和早期的软件开发过程中 ，但是随着集团智能化战略的推进，公司承担着越来越多的系统开发任务。软件应用的复杂性日益提高、软件功能的交互性越来越强、软件需求的变更也越来越频繁，开发人员之间的分工合作越来越深，相互依赖程度也越来越高，几乎没有各自完全独立工作的模块，因此，这种模式会给后期的集成工作带来了很大的风险。在

23、这种背景下，寻求更好的开发模式和集成策略就成为目前较为迫切的需求，也是本文所关注的焦点。 如果能够引入持续集成实践，就可以避免了上述遇到的问题，但是基于当前研发部门的情况，进行持续集成实践还存在着以下几个问题： 1. 虽然开发团队已经认识到原有集成模式的缺点并且开始认识到持续集成的优点和价值，但是由于缺少对持续集成真正内涵的理解，也不能正确的应用和实施持续集成。 2. 持续集成的成功案例不够多，很少有实际软件项目的实践指导。 3. 很多管理层认为持续集成可以通过开发者手动来完成，而忽略了它的真正意义。 面临以上的几点问题，为了使持续集成能够在软件开发项目中得到有效用，本课题希望通过对持续集成的

24、研究以及在海信传媒的实际项目中的试验经验，能够让更多的开发者们对持续集成的理论有更深刻的认识，理解它的真正内涵和价值，并且能把持续集成最后应用到各自的开发项目中，收获它所带来的成功的喜悦。 1.4 课题的研究工作 第一章首先介绍了本文的研究背景情况、持续集成在业内的现状和选择此课题的意义，并说明了本研究是基于本人在海信传媒公司的项目经历而进行的。 第二章比较了常用软件开发模型的集成方式： “Big-Bang”集成方式，“迭代递增”方式，以及微软公司的“每日构建”模式，然后提出了现代敏捷软件开发与持续集成的概念，并比较了每日构建和持续集成的不同。 第三章本章首先对持续集成的概念做了具体的解释，然

25、后深入研究了持续集成的基础理论和工作方式，最后总结了持续集成在现代企业软件开发中的重要价值，为后面的深入研究提供了动力。 第四章建立了持续集成的系统架构，并对持续集成系统的各个构建工具做了细致的讨论，然后最终对选择的持续集成构建工具进行分析。 第五章提出了基于Jenk的具体设计方案，包括了版本控制的实现、自动化测试的构建和安装Jenk的方法和配置，然后给出了该方案最后在项目中的初期实施效果。最后分析了在实施持续集成实践的过程中可能会出现的很多误区。 - 4 -脚注和尾注 1. 袁冰，操云甫Web客户端应用程序性能测试自动化研究计算机测量与控制200412(8)：732-734. 2. Will

26、iam ELewis?软件测试与持续质量改进M人民邮电，2010. 3. 张大方，李玮软件测试技术与管理湖南：湖南，2007，12. 4. Glenford，J.MThe Art of Software Testing MJohnWiley&Sons，Inc，2004. 5. 陈宏刚，熊明华，林斌等编著.软件开发过程与案例北京：清华大学，2003. 6. Kent Beck Extreme Programming Explained：Embrace ChangeAddison-Wesley，Pearson Education，2000. 7. Amr Elssamadisy，Gregory S

27、challiol Recognizing and responding to bad smells in extreme programming. Proceedings of the 24th International Conference on Software Engineering，2002. 8. Matrin Fowler，Matthew FoemmelContinuous Integration EB/OLhttp:/www. martinfowler. com/articles/Continuoushitegration.html，2000. 9. CruiseControl

28、 EB/OL/. 10. Continuous Integration Testing Conference./index.php，2006. 11. Jesper Holck，Niels JorgensenContinuous integration and quality assurance: a case study of two open source projectsFree/open Source Software Development. Idea Group Publ

29、ishing， 2005. 12. 陈刚，羌铃铃软件项目开发中的持续集成研究.项目管理结束，2011，9(12). 第六章总结本文的所有研究内容，提出了本方案的可行性，并对后期的工作做出了长远的展望。1.5 本章小结 本章首先介绍了整篇本章的研究背景情况，以及持续集成在业内的现状和为什么选择此课题的意义，并阐述了课题的来源：说明了本研究是基于本人在海信传媒公司的项目经历而进行的，最后归纳总结了本文的研究工作，并对每一章都做了概括 ，让读者对后续的研究工作有一个大体的轮廓和概念。 2 软件开发模型与集成方式的对比研究 目前，一般的大型软件产品都由几百万甚至上千万行代码构成，例如：windows9

30、5的操作系统源代码就达到大约1100万行之多。整个系统能否正常工作都与这千万行的代码密切相关，任何一行出问题都可能导致系统，并且每个部分之间又相互影响。至今为止，已经出现了很多种的软件开发模型和集成，而每一种模式都有各自的特点，它们在抵抗风险和和降低项目的不确定性上都体现着不同的作用，他们之间的关系也密不可分，相互又都有着交叉关系。但是总结一下在软件集成时我们要考虑的方面无疑也就是几下几点： 1.2.3.整合各个模块时会不会出现数据的丢失。每个分模块集成时是否会出现互相干扰。 每个小模块独自可以正常工作，但是集成后是否会出现问题。在软件飞速发展的这几十年中，寻找更好的软件开发方法和有效的集成方

31、式一直是软件工程领域研究的热点，在这个过程中不断的涌现出了很多种的开发模型和集成方式。下面就选择几个典型的例子来比较一下各种模型和集成方式的特点。“Big- Bang”、“迭代递增”和“每日构建”这三种集成方式都是业内研究和讨论的热点，也代表着集成领域的发展。比较这三种集成模式之后也就对持续集成的思想起源有了更加深刻的认识。 2.1 常用软件开发模型的集成方式比较 2.1.1 “瀑布模型”与“ Big-Bang”集成模式 Wton Royce在1970年首先提出了著名的“瀑布模型”，直到20世纪80年代的初期，这种模型都是被很广泛的应用到各个软件开发过程中的。Wton Royce倡导采用结构化

32、的设计方法，将产品功能的实现和设计分开，力求把过程变得简单化，同时也方便开发人员分工协作。瀑布模型的整个过程分为六个阶段：计划、需求、设计、编译、测试和维护，而且各个阶段是必须按照顺序进行，就好像瀑布的水流一样，自顶而下的落下，瀑布模型也是由这个形象的比喻而得名，图2-1展示了它的工作方式。 图2-1 瀑布模型 由上图可以看出，这种模型设定了软件开发过程中每一项工作都要按照次序进行，当前的过程要接受上一级过程的执行结果，完成了本级的工作后要对结果进行分析和审核，如果审核通过了，那么就接着进行下一级的过程，不通过则回到初始阶段修改瀑布模型。瀑布模型注重软件开发的阶段性，开始于第一个阶段的计划和根

33、据客户的需求而做的系统需求分析，最后结束于对产品的测试，虽然瀑布模型很重视测试阶段，但是往往会出现的问题是当项目的测试结果交付给客户时会发现整个开发人员在对客户的要求有很大的偏差，导致最后的功能虽然实现了，但是客户仍然是不满意的。一般情况，这种系统设计问题要到最后测试阶段才能被发现，增加了项目开发的风险。出现问题后就会导致项目不能按期限完成而增加额外的开发时间、需要返工或者随之带来的费用上的增加，最后导致进度变缓慢。瀑布模型中系统设计和需求说明书存在的问题是很难再开发项目的初期就被发现的，只有第一次运行集成测试和验收测试时才会发现初始的设计和需求有问题。瀑布模型虽然有着一些缺点，但是如果软件项

34、目规模小、有着很明确的目标、需求和功能很简单明了，那么采用这种瀑布模型是一个很不错的选择。但是对于现代企业软件开发的复杂性，它的劣势也就凸显而来了。 通过分析瀑布模型，我们很容易的发现了它的缺陷和问题： 1. 瀑布模型对用户需求的准确性要求很高，只有做到这一点才能开展后续阶段的工作，但是在实际开发中，这几乎是不可能，也是很难实现的。 2. 模型的每个阶段拥有很强的依赖性和次序性。只有确保当前阶段工作的顺利完成而且结果正确才能进行下一个阶段的工作，但是如果遇到最后阶段出现错误的话，很可能需要追溯到它之前的许多阶段。假如在软件开发的后期集成时发现问题 ，这样将要付出很高的代价来查找问题的根源。 3

35、. 瀑布模型最大的缺陷也就是无法适应需求的改变，在开发中总结的一些实践经验无法重新加入到初期的系统需求上 ，这样就会带着风险进行后期的开发，失去了今早纠正隐患的机会。 - 5 - 2. 21110233023_徐萌_信息科学与工程学院_电子与通信工程_第2部分总字数：10904 文字复制比：0.6%(67)(0) 瀑布模型在软件开发中的应用及其局限性 罗孟华;李军;黄益辉; - 才智- 2009-03-20 0.6% 是否引证：否 原文内容 1 13. ConradiR， Fuggetta A Improving software process improvement IEEE Softwa

36、re， 2002， 12(4)：92- 99. 14. 王向阳极限编程研究与应用：硕士学位论文武汉：武汉大学2004. 正是由于上述的缺陷也把这种集成方式称为 “Big-Bang”集成方法，它是一种非增量式集成。这种方法规定开发人员必须把所有模块按照需求一次性全部整合起来，然后进行整体测试。然而“Big-Bang”集成方法的缺陷就是，在进行集成测试的时候可能会发现很多的bug，每个bug的定位和改正非常困难，很容易产生混乱状态，并且在改正一个错误的同时还有可能会引入其他新的错误。在小型应用系统中，整个软件系统由不太多的单元模块组成，它可能就是一种比较好的方法，但是随着软件行业日渐蓬勃发展，规模

37、也越来越大，大部分的情况都是开发比较复杂的软件，这时，就需要我们寻找其他更好的集成方式。2.1.2 Rational统一过程与“迭代递增”集成模式 Rational统一过程(Rational Unified Process，简称RUP)是由Rational软件公司（现在Rational已经被IBM并购）创造的开发模型，它定义了产品开发的每一个过程都可以被认为是一个完整的迭代，而每一次迭代之后就会产生一个稳定、可执行发布的版本，这个过程中包括涉及版本的所有活动包括其周边因素。一个迭代过程分为：确定产品需求、系统分析设计、测试和实施的流程。RUP还认为每次迭代产生的版本都是该产品最终版本的其中一个

38、子集，也是最终产品所有功能中的一部分。按照RUP的设计方法，一个大型项目的开发过程就会有很多次的迭代过程，而且每一次只需要考虑整个项目中的一部分需求，并建立在前一次已经成功迭代的基础上进行，只对当前的过程进行分析、设计、测试和实施等工作。RUP就是用这种变迭发的方法来进行，这样每次迭代都可以对原有功能进行一部分的更新和增加，照这种迭代递增方式进行下去，最后一次成功的迭代也就意味着最终版本的产生。 其流程如图2-2所示： 图2-2 RUP示意图 RUP 的软件开发过程在时间上被分为四个顺序的阶段，分别是：Inception （初始阶段）、 Elaboration（细化阶段） 、 Construc

39、tion（构造阶段）和Transition（交付阶段）。Steve McConnell这样形容道：“这些阶段就好像是从雪山顶上开始滚雪球，雪球会越来越大”，因此把这种集成方法称之为“迭代递增”集成方式。 相比于“Big-Bang”集成模式，“迭代递增”集成软件设计灵活检验、修改方便，还提供了可以提早采取预防措施的机会，很大程度上增加了项目的成功率，有助于均衡整个开发过程的负荷，流程可在迭代过程中得到改进和精炼，能够更加容易的确定bug的位置。并且允许代码的变更、随时能够优化系统的需求，然后通过向业务人员展示迭代后系统产生的新功能，开发人员可以很快的从业务部门搜集对于本产品的反馈，尽早的修正之前

40、对需求理解的偏差，以确保最终的产品版本能够满足客户的要求和目标。其次这种迭代递增可以逐步集成。在传统的集成过程中，一般会要求一次性集成系统中所有的模块，项目越复杂集成工作就会占到整个项目开发中的越大比例，有时会达到40%左右。 在迭代模型中集成是不间断的，系统功能也是每集成一次增加一部分，因此每次的工作量和难度相对来讲也都是比较低的。因此，这种方式不仅可以尽早降低项目风险还可以增加开发团队的热情，因为他们每天都可以看到能够正常工作的系统，从而设计出质量更高的产品。每次迭能上的瓶颈。 成的新版本产品都可以进行测试，企业也就可以在测试结果中及早的发现缺陷并改正性如果在新一次的迭代中出现问题，那么意

41、味着这个错误一定是出现在新功能的模块上或者是新代码和原有代码的接口上 ，这样一来bug也就更容易定位，可以准确的知道应该到哪里查找错误的根源。具体来说，每一次迭代的问题都会是少量的、不会是多个问题的相互作用，而且在接口上产生的问题越多，迭代递增模式的优越性越明显，减少开发人员用在调试上的时间和精力，可以很大程度上提高开发效率。 由此可见，“迭代递增”集成方式有诸多的有点，但是在实践的时候会经常遇到两个典型的误区：“迭而不增”与“增而不迭”。“迭而不增”就是每次毫无效率的简单重复的迭代，而“增而不迭”又回归到类似瀑布模型的集成方式，如图2-3所示。 图2-3 “迭而不增”和“增而不迭”模式 这是

42、因为“迭代递增”集成模式并不能量化每次迭代之间的时间间隔，更不可能量化新一次迭代的工作量，因而经常会造成迭代版本之间并没有新功能的增加或者很长一段时间不进行新功能模块的集成测试这两个问题。 微软公司就建立了一个新的集成方式（每日构建），可以避免出现以上的两个问题，是在集成领域的又一大突破和创新。2.1.3 微软过程模型与“每日构建”集成模式 微软过程模型 (Microsoft Solution Framework, MSF)是由世界上最著名的软件公司微软公司建立的，它是基于自身的企业软件开发实践设计的一个准则。微软公司作为计算机软件的领导者，成立近四十年以来开发了Windows操作系统等众多软

43、件 ，微软把MSF应用到了所有的软件产品从最初的产品需求分析和策划到试用版发行最后到正式版本发布，微软的成功也证明了微软过程模型的成功。微软过程模型是一种递进式的、阶段性的软件开发模型，从“生命周期”来看，MSF分为分析、计划、开发、稳定和发布五个阶段，每一个阶段均涉及到了产品管理、程序编译、测试、发布等活动，各个阶段的结束都意味着一个里程碑式的进步。 微软过程模型与RUP相似，是以“迭发”为主题，系统设计、文档、计划、代码和其他的活动成果都是以迭代形式出现。MSF的主要思想是以建立核心功能为出发点，然后其他的小功能逐渐后续被加入，这也就是MSF的发布策略。一般情况，对一个小型的软件产品，只需

44、要一个版本，但是微软公司建议把这个产品仍然分成很多个版本，这样可以在开发的过程中找到改进的机会，而且版本的发布也不需要按照顺序进行，多个版本中间可以有重叠，发布周期也是随时根据项目的类型、规模、策略和客户需求的不同而不同。MSF 模型采用的这种递进式的版本发布策略要求开发小组在每一次的迭代过程中保证有新的功能 出现，这样就会高效的提高产品的质量而且也便于项目管理者了解产品开发过程并能随时调整开发的方向。 微软过程模型也是因为它的集成方式而出名，那就是每日构建(Daily Build)，从字面意思便可以知道，它是要求每天自动地、完整地构建整个代码库，这样也就解决上面提到的“迭代递增”中的两个误区

45、，原因是每日构建很明确的规定了两次迭代的时间间隔为一天、每天的工作量作为迭代之间的增量，这样同时也解决了“Big-Bang”模式的缺陷，还优化了“迭代递增”的优势。 2.2 敏捷软件开发模型与持续集成模式 尽管微软过程模型有很多优点，但是随着经济全球化的进行带动着软件业也飞速的发展，软件开发也有了更多的需求和特点，那就是能够在开发过程中快速高效的进行，在这种情形下出现了一些新的软件开发模式，敏捷软件开发模型(Agile Methodologies)就是其中的一个典型例子。敏捷开发是一种替代传统的项目管理和瀑布模型的软件开发方式，它可以通过增加迭代工作的节奏，以一种冲刺式的过程来帮助开发团队应对

46、开发的不可预测性。敏捷开发方法提供了一个评估整个开发生命周期方向的机会，包括每一个环节的要求、设计、测试的实施，这种方式极大地降低了开发成本并能够缩短上市时间，因为他们在开发的同时集成测试也在发生。面对开发过程中需求的变化，敏捷开发方法的策略是尽量减少变动，下面是它的一些实践方法： 1. 争取在第一到第三周就发布产品的第一个版本，以获得第一时间的反馈结果。2. 应用最简单的解决方案，这样有助于日后的修改。 3. 不断地改进设计以增加产品的功能，提高设计的质量。 4. 持续地集成，不停地进行产品测试，以便减少开发后期集成测试和修改的代价。5. 邀请用户参与软件的全过程，并在其中起着重要的作用。

47、敏捷开发中的其中一个成功实践就是持续集成，开发团队经常集成他们的工作，从而尽快地发现集成错误。其流程如图2- 4所示，开发人员每一次迁入新代码，持续集成模块都会自动从源码管理器获得最新源码，然后顺序执行之前规定的任务，先是编译，成功了则进行单元测试，接下来进行代码检查，只要哪一步失败了则终止过程。最后不管能否顺利进行整个集成过程 ，与项目相关的工作人员都可以到DashiBoard集成报告服务器查看分析结果和详细信息，同时也会收到电子邮件的相关消息。图2-4 持续集成示意图 从上图不难看出持续集成在本质上和每日构建是相似的，但是仔细分析就会发现他们在频率和对结果的反馈上还是有一些差异的： 1.

48、持续集成的集成频率比每日构建要频繁，现在普遍应用的持续集成系统一般就是过几小时就集成几次，这样每天都会进行多次，但是具体还要视实际情况来定。 2. 持续集成的目的是为了得到第一时间的反馈，而每日构建是以得到一个稳定发布的版本为目的，但是在开发人员修复过导致持续集成失败的bug之后也会得到一个成功的版本。 3. 持续集成非常鼓励开发人员尽快提交变更，每日构建则没有。2.3 本章小结 比较了常用软件开发模型与集成方式：瀑布模型与“Big-Bang”集成方式，RUP与“迭代递增”方式，以及MSF和“每日构建”模式，然后提出了最流行的现代敏捷软件开发与持续集成的优势，并比较了持续集成与每日构建的区别。

49、 3 持续集成研究与价值3.1 持续集成概述 持续集成(Continuous Integration)一词来源于极限编程(Extreme Programming)，是一种十分重要的工程实践过程。著名的软件开发领域大师Martin Fowler，同时也是Thoughtworks首席科学家发在他发表的一篇著名的文章Continuous Integration中对持续集成进行了定义并倡导各大软件公司开始实施持续集成应用实践。在软件产品的开发过程中，一个项目会被划分为很多的模块，而各个模块是由很多的开发人员分别对其进行编译，在所有模块都编写成功后集成到一起进行整合测试，这也就是比较传统和常用的开发方式

50、。但是这种集成模式有很多潜在的问题和风险：比较典型的就是当开发人员对各自模块运行无错误、无缺陷之后集成到一起会出现很多问题，而此时必然是已经接近软件开发的后期，留下可以排查bug的时间不会很充裕，定位错误的根源更是难上加难，则会造成开发停滞不前，软件开发可能会面临失败，带来巨大的损失和影响。持续集成则是完全自动化的过程，它代替了原来的人工手动操作，包括下载代码、执行测试用例、分析测试结果等，它使得一天中集成多次成为可能，几个小时就可以提交多次，同时确保每一次地操作都不会破坏原有的构建。这种方式可以将每次代码的更新快速的反馈给开发团队，能够使问题在最早的时候发现并留给开发人员充足的时间解决，而且

51、每一轮变更后出现的bug仅仅是由最新一次的更新带来的，问题会比较容易定位和改善，很大程度上提高了软件开发的效率， 缓解了测试工作带来的繁重的工作负担。 持续集成的出现在使得软件集成问题的解决方法得到了很大程度的进步，越来越多的开发人员慢慢的开始关注持续集成 ，通过各种成功的实践也证明了持续集成能够满足软件开发人员的需求。为了提升持续集成的技术水平，也使持续集成在软件开发行业得到更为广泛的使用，对持续集成实践的研究和应用都有着特别重要的现实意义。 一般情况，持续集成有着几下几个原则： 1. 设立一个版本管理软件来保证开发人员提交的代码能够顺利的进行构建集成，比较常见的版本控制软件有Subvers

52、ion、CVS 、IBM Rational Clear Case等。 - 7 - 2. 能够确保版本控制库定期会有更新，这就需要开发者及时提交代码，而且开发人员也必须定期地从源码库中更新代码到本地。 3. 要有一个专门的CI服务器作为设备保障，因为它是持续集成的“大脑”用来执行各种构建工作的核心。它的工作启动方式既可以通过变更来触发，也可以根据实际情况来设计定时启动的周期，比如可以半个小时执行一次构建。 4. 必须确保每一次集成构建最后都能成功。如果出现构建失败了，需要马上查找发生的问题和bug的根源，修复完成之后要再次启动构建，直到成功的集成所有的代码为止。 3.2 持续集成系统的工作方式

53、上面已经简单的介绍了持续集成的一些概念和流程，下面具体说明一下持续集成是怎样工作的：负责各自模块开发的人员把各自本地编译的新代码提交到版本库，就会触发到服务器开始工作，首先版本控制软件会自动更新代码库中的代码，然后把更新后的所有代码提取到另外的一个空目录中自动运行规定的测试用例，在一些版本控制工具中，也有分成不同的分支空间在进行测试的。如果测试成功则接受这次提交，成为一个新的版本，否则反馈给开发团队，这是一个失败的版本。 持续集成最重要的就是能够完成彻底的自动化和频繁的更新，因此需要采用持续集成服务器软件来实现，也就是像一个定时调度器，它会监视着代码库中的所有代码，类似一个监视器来检查代码的状

54、态，观察是否有更新，每当发现原有的代码库发生了变化，持续集成服务器就会自动地运行编译和所有的集成测试，然后还会记录并制作成分析报告反馈给开发的人员，便于对整个代码情况的了解。图3-1就是持续集成工作机制原理图： 图3-1持续集成工作机制原理图 由这幅图可以看出，持续集成工作是从“心跳检测”开始的，如果到了设置好的轮询时间检测版本管理器就会判断源码是否发生了变化，无变化则继续等待下一次轮询，有变化的话则更新源码到本地服务器然后执行构建（包括编译、静态检查、执行单元测试、打包、测试部署等步骤），最后在网页显示出本次构建的结果，以邮件方式发送构建结果个工作机制。这样每个开发人员都会很清楚的知道了软件

55、开发的状况。 3.3 持续集成的价值 ，然后循环往复这Mckey and Company（麦肯锡咨询公司）的一项调查研究总结了一则规律：一个好的软件开发流程可以在很大程度上提高企业的产品生产效率，相反，一个坏的开发流程甚至能搞垮一家公司。在调查中发现，发展较好较快的软件公司中 94%都在应用持续集成实践，而做的不是很好的公司则没有或者很少应用持续集成的构建。美国微软公司的软件部门经理也指出：持续集成就是软件项目存活的“心跳”，心跳如果停止，那么意味着软件开发项目也就马上面临死亡。由以上两个例子可以看出持续集成对于现代企业软件开发的发展有着非常重大的价值和意义。下面对持续集成的价值总结如下： 1

56、. 最大程度降低软件开发过程中的风险 一个大型的软件项目会由很多个研发团队分工合作，这样一个项目就会分成很多细小的模块进行分别各自开发，最后他们把各自的代码组合起来并进行集成测试，但是基本上得到的结果都是有错误的，项目越复杂错误可能也会越多，这会浪费很多的时间用来调试和修改，而bug的根源会在此时由于软件的复杂性而很难找到和定位。如果采用持续集成这种每天进行多次集成的方法并同时进行测试和分析就有助于今早的检查缺陷，随时了解软件的健康状况，减少最后时刻的大问题，最大程度的降低开发的风险，也能减少隐患的存在。 2. 减少人工的重复工作 自动化的持续集成过程可以把重复的、大量的人力工作让机器去实现，这样就不用花费很多的人工费用，也能够节省花在测试上的时间和工作量，能让开发人员更关注开发过程中更迫切需要解决和更有价值的事情上。 3. 随时可生成发布的软件 持续集成最显著的特点就是它可以允许随时发布可发布的软件，如果不进行持续集成我们理论上认为软件产品的质量是可靠的而且没有风险，但是并没有依据和证明，而客户最认可的则是可以发布的实际的产品。持续集成还能对这些软件进行进一步的更新和改动，然后将这些变更和原有的代码进行集成，如果不能顺利集成，出现的问题也会马上反馈给开发者并尽快的得到分析和修复方法