持续集成在软件开发过程中的应用

邢晓伟

(中兴软创科技股份有限公司，江苏 南京 210000)

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，这就意味着每天可能会发生多次集成[1]。在实际使用中，持续交付主要关注于构建、部署、测试和发布过程[2]，每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快地开发内聚的软件。在软件业，谷歌作为当前科技领头羊率先在内部推行并使用了持续集成模式，在其内部的持续集成系统中，数以亿计的构建动作会出发几百万自动化测试[3]。谷歌的先行开辟了快速开发领域的测试新模式。

1 持续集成开发模式

1.1 持续集成的目的

持续集成是用来解决随着不断提高软件开发复杂度带来的软件质量风险问题。为了快速响应不断变化的需求而提出的敏捷开发概念导致版本更新速度非常快，而软件内部相互模块间的干扰自然变得更加频繁，这时候就需要严格的软件测试。软件测试不能等同于程序测试，软件测试应当贯穿软件生存周期全过程[4]，持续集成在敏捷开发中可以保障快速适应和软件质量，重点使得持续集成显得尤其重要。

1.2 持续集成的方法

持续集成是为了达成快速质量保障进行的一种软件开发实践。它倡导开发团队必须经常集成他们的工作，每天集成一次甚至发生多次集成。如果每次集成都需要人工完成其中的编译、发布和测试就显得成本太高。因此通过自动化的构建来验证每次的集成，包括自动编译、发布和测试，从而尽快地发现集成错误，这就是持续集成在实际应用中需要解决的问题，它让团队能够更快地开发内聚的软件。

1.3 持续集成的特点

持续集成中无需太多的人工干预，其任何一个环节都应该是自动完成，从而减少重复过程以节省时间、费用和工作量。

1.4 持续集成的价值

持续集成在需求不明确或是频繁变更的情景中显得尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对产品的信心。同时可以实时反馈出软件的实际开发进展，能够很明确地给出当前时间点以及哪些已经完成的功能是可用可部署的。

2 设计原理及特点

持续集成平台的建设目标是：在给定成本、进度的前提下，在架构设计上需要具有适用、有效、可靠、可互操作。这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。同时需要功能上满足持续集成的需求，必须具备相应的调度、执行、统计、推送等持续集成的基础功能，在性能上需要能及时有效的完成流程各个环节，尽量降低一轮集成的时间，基于以上要求，在架构上选择了C/S(Client/Server)与B/S(Browser/Server) 的组合模式，以达到性能与使用性的最优。在功能设计上，采用分层设计和开发，在不同的层次实现不同的业务功能，即便于开发也便于后期各模块之间的调度。

2.1 架构模式

持续集成作为一个系统化的平台，不仅要提供用户的介入平台，也需要提供完善的服务器运行维护管理，这就对软件的架构提出了很高的要求，经过论证，决定将整体的软件分为用户界面与服务器管理两部分，分别采用B/S与C/S架构。其中提供给客户使用的部分为B/S模式，主要考虑到用户数量众多，频繁的客户端升级与安装将占用太多的维护成本。而用来调用相关的代码检查、编译、部署的部分则采用C/S架构，由一个主控与多个客户端构成，这样既能提高运行效率，也方便在服务器上进行统一部署。

2.1.1 B/S架构模式 B/S结构最大的优点就是只要安装有浏览器即可在任何地方进行操作，不用安装其他任何专门的软件。只要有一台能上网的电脑就能使用，客户端几乎零维护。系统的扩展性非常容易，只要能上网，再由系统管理员分配一个用户名和密码，就可以使用了。但是B/S架构依赖浏览器，而浏览器的版本繁多，很多浏览器核心架构差别也很大，导致对于网页的兼容性有很大影响，尤其是在CSS[注]CSS:一种样式设计语言。布局、JavaScript[注]JavaScript:一种客户端脚本语言。脚本执行等方面，会有很大影响。基于这样各种问题，目前本系统在内部推广时，推荐使用安装最广泛的IE8浏览器。

2.1.2 C/S架构模式 C/S结构，是大家熟知的软件系统体系结构，通过将任务合理分配到Client端和Server端，降低了系统的通讯开销，需要安装客户端才可进行管理操作。

客户端和服务器端的程序不同，用户的程序主要在客户端，服务器端主要提供数据管理、数据共享、数据及系统维护和并发控制等，客户端程序主要完成用户的具体的业务。

C/S结构最大的优势在于其优异的性能和稳定的运行能力，在系统实际选型时考虑到系统的执行性能(不含展示部分，仅考虑后台运行模块)，分布式部署的C/S架构自然就是首选。

2.2 总体功能

持续集成系统在架构设计层面采用分层设计和开发，降低模块间的耦合度，使每一个子系统相对独立，降低维护成本。分布式部署和调度，降低主机网络等环境异常带来的损失易于统计分析。

从我国民族体育发展来看，将其与旅游业态相结合尚处于起步阶段。虽然高端定制民族体育旅游发展市场目标明确，但是对于高端定制的发展要求较高，且不仅市场定位人群有限，而且在项目选择，旅游产品服务质量保证方面在均存在一定的问题。针对高端定制民族体育旅游发展中存在困难，希望能借助“互联网+”时代的到来而得到解决，让民族体育在时代洪流中大放异彩。

系统有BCL(Business Component Library)、 ZCIPA(Ztesoft Continuous Integration Platform Agent)、 ZCIPS(Ztesoft Continuous Integration Platform Server)3部分组成，互相独立，又有内在联系，其中BCL管理所有的可用组件，ZCIPA负责接受服务器的指令并调用BCL中的组件来实现其命令，而ZCIPS主要作为一个计划调度器的存在，在其中集成了配置页面、命令调度、报告系统等。

使用此方案的目的是：1) 减少系统间的耦合；2) 集中式管理，分布式部署和调度；3) 核心数据数据库存储使得后期报表统计和质量分析容易处理；4) BCL组件和ZCIPA分布式部署，降低主机异常带来的损失；5) 日志分布部署，提高机器的利用率，减少对高性能主机的依赖；6) BCL组件可单独使用。

2.3 数据存储方式

系统的核心数据采用关系型数据库进行集中存储，同时使用了分布式日志存储，所有的静态配置数据以及接口数据都存储在数据库中。系统内部主要采用的是数据库接口的方式进行信息传递，对外提供消息接口、文件接口等多种接口方式。客户端调度主要使用消息接口，而各个客户端在完成其自身任务后通过表接口通知服务器进展并记录关键日志，相关的日志信息以文件方式存储在各个客户端本地，只有在有查询需求的时候以文件接口的方式传输给服务器，有效降低了数据的传输量，提高了运行效率。

2.4 任务调度

在系统中，为减少人工工作量，持续集成的流程处理都是推荐以定时计划的形式存在，但是也包含手工拉起任务的方式。为了进行统一调度处理，考虑到拉起进程的时间消耗其实很少，主要的消耗是在客户端，在服务器定义了一个唯一的任务调度线程(下称主线程)。主线程负责拉起对应的处理线程，而处理线程实时监听和调度对应客户端的处理结果。

系统中实际的任务调度模式如下：首先系统会在数据库中加载所有的定时任务，将其交给定时任务线程，该线程按照规则将其编制成带派发的带时间的任务列表，同时手工拉起的任务也在这个队列中，在任务需要激活的时间点将其通过内部消息队列交给主线程，主线程按照任务生产相应的处理线程，处理线程通过消息通知对应的客户端接受任务，而客户端按照消息命令拉起对应的任务组件，从而完成整体的流程调度。

3 实际应用结果及分析

持续集成和持续发布的理念提出后，首先看到的是当前的发布模式与持续集成理念的不一致。当前发布模式是制订版本计划在指定时间点完成规划工作后发布，而持续集成和持续发布的理念提出，应该随时集成并且相应地要做到随时发布。因此需要以某个版本试点持续集成和持续发布的模式。

3.1 实际应用

在系统基础功能就绪以后，笔者团队选用了一个业务版本，将其部署在持续集成系统上，并进行了监控。执行结果统计见表1。

表1 两周内运行结果比较

3.2 结果分析

在实际使用中，有定时的邮件报告，可以实时看到代码静态检查结果与回归测试用例的运行结果，使得开发人员在进行代码开发时有了很多的督促，从表1可以看出，CppCheck的结果在第一周集中整理时有较大的下降，而且，在之后的开发过程中，数量没有上升，可见在其后的开发过程中，开发开始关注的代码编写规范问题，这使得代码的可读性得到了有效的保障。

再看版本制作，实际执行时由于各种原因，并没有每天都得到完整的结果，但是在成功运行的3天中，可以确定这生成的3个版本是有效的。因此即使在成功率很低的情况下，在2周内仍然获取了3个可用版本，相比以前一个月才能出一个版本，效率得到了很大的提升。

在实际部署时也出现了不少问题，例如运行时发现主机宕机、网络故障、数据库故障等经常导致整个系统的运行不正常。也发现有代码编译不通过的情况，在后继的实施过程中，这些都是需要重点考虑解决的问题，应该将非版本因素的影响降到最低，在出现版本质量问题的时候也能够及时有效地进行反馈。

4 结 论

持续集成的开发模式是近年来新兴的一种快速迭代的开发方式，能有效提高开发效率与版本质量。持续集成主要考虑的问题有：多种工具的协调使用，快速的执行速度，与各种平台和环境的集成。在实际应用中，以研发持续集成平台的方式来实现。

持续集成作为一个系统平台，有效地整合了软件质量保障的各个系统与功能。实现以下建设目标：1) 通过各种代码编写规范的检查，提高并保障了代码的可维护性。2) 通过对圈复杂度的检查，降低了代码的复杂度，提高了可修改性与可理解性。3) 通过定期频繁的编译与部署，保障了软件版本的有效性。使得出现编译与部署风险的可能性大大下降。4) 通过自动用例的定期执行，保障了代码功能的可靠性。5) 通过每天的版本发布使得需求的发布周期大大缩短，提高了系统的可追踪性。6) 通过对代码的扇入扇出度检查，降低了扇入扇出度，提高了代码的可移植性与可重用性。

通过续集成系统，在软件开发过程中达成持续集成的目的，实现快速实时的版本发布。问题快速发现快速解决，将软件开发提升到一个新的阶段。

[1] Paul M D,Steve M,Andrew G.持续集成:软件质量改进和风险降低之道[M].王海鹏,译.北京：机械工业出版社,2008:2-10

[2] 乔梁.持续交付的魅力[EB/OL].[2011-10-12].http://www.infoq.com/cn/zones/baidu-salon/content-16.html

[3] James W,Jason A,Jeff C.Google 软件测试之道[M].黄利,李中杰,薛明,译.北京：人民邮电出版社,2012:1-10

[4] Robert C M.敏捷软件开发:原则、模式与实践[M].邓辉，译.北京：清华大学出版社，2003:98-119

[5] 徐仕成.持续集成在现代软件开发中的应用与研究[D].长沙：中南大学，2007