【摘要】在完善银行信息体系的建设中，如何将专业的信息技术和工具与银行的实际相结合，成为当前银行业关注的重点。本文在对商业银行软件研发现状及持续集成相关概念进行分析的基础上，对商业银行应用持续集成的实践进行了研究探索，详细讨论了持续集成在商业银行软件研发过程中所发挥的积极作用。
【关键词】持续集成 商业银行 实践
随着国内银行体系的日益开放和监管要求的日益加强，我国银行信息体系的内部建设也在经历着巨大的转变。经过20年的高速发展，我国银行科技部门及各业务部门的现代信息技术的知识和管理水平得到了快速积累和提高，信息风险防控能力、IT治理能力及软件研发能力等方面都取得了长足进步和发展。但是，在完善银行信息体系的建设中，如何将专业度颇高的信息技术和工具与银行的实际相结合，成为当前银行业关注的重点。
近年来，商业银行的业务规模取得了长足发展，软件研发的数量和规模不断增长，软件集成的复杂度和频度也不断提升。各商业银行通过将持续集成应用到软件研发的实践过程中，切实在提高软件资产安全、降低项目研发风险、提高软件产品质量、提升研发效率等方面发挥了重要作用。
一、商业银行软件研发现状
当前，国内商业银行业务应用系统规模庞大、功能繁多、需求变更频繁，采用传统瀑布模型的开发和管理模式运作的项目组在项目研发过程中遇到很多影响软件质量与管理效力的问题：
（一）工具种类繁多，未实施有效集成
为提高信息科技的基础管理能力，商业银行陆续采购了配置管理、变更管理、缺陷管理和测试管理工具等涉及软件研发生命周期不同阶段的管理工具，工具不仅种类多而且工具之间缺乏有效的集成，数据无法有效共享。比如，配置管理工具的代码变更集未同缺陷管理工具的缺陷实例进行关联，无法方便、及时地获取代码变更集和需修复缺陷的对应关系。
（二）手工操作繁琐，自动化程度低
在商业银行软件开发过程中，大量地开发和管理类活动均采用手动过程，不仅降低了整个开发团队的工作效率，而且增加了引入人为失误的风险，重复执行也浪费了大量人力，使得发现、解决问题变得异常困难。比如测试人员在测试环境中所发现的问题，可能是由于部署人员忘记拷贝了某个配置文件，也可能是由于没有删除某些临时文件。
（三）集成构建较晚，无法有效控制产品交付时间
商业银行应用系统的架构一般分为前、中、后台三层。一个项目往往由一个主办方和多个协办方统一协调完成，应用系统之间的耦合度越来越紧密。同一系统的不同层级之间或不同应用系统之间的集成构建往往到了产品发布前的最终集成时才刚刚开始，使得“从代码到编译集成”以及“从编译集成到可交付软件”2个过程的时间长短无法有效控制。比如一般解决编译甚至测试出现十几个问题，可能会耗费团队一天的时间来修补出现的错误。但是，如果到一个月以后的集成构建才发现这些问题，这些问题可能会出现数十个，有时可能会出现近百个错误，这可能会花费团队两到三天时间进行修补，构建越不频繁，变化的堆积也就越多，开发部门应对这些变化的所花费的时间也就越长。
为解决上述问题，进一步提高软件的产品质量和产品研发的工作效率、保证软件系统处于一个稳定可控的状态，商业银行纷纷引入了持续集成的理念，并和已有管理工具有效融合。
二、持续集成的方法论
在一个人开发的项目中，依赖外部系统比较少的情况下，软件集成不会成为太大的问题，但是随着项目复杂度的增加，就会对集成和确保软件组件能够一起工作提出更多的要求——要早集成、常集成。等到项目快结束时才来集成会导致各种各样的软件质量问题，解决这些问题代价很大，常常会导致项目延期。持续集成以较小增量的方式迅速解决这些风险。
（一）持续集成的概念
大师Martin Fowler对持续集成是这样定义的： 持续集成是一种软件开发实践，是现代软件开发的必备配置。在持续集成过程中，团队成员可以频繁集成他们的工作成果，每次集成会经过自动构建的验证，从而尽快地检测出集成的错误。
（二）持续集成的特征
1.源代码编译。持续的源代码编译是持续集成最基本、最常见的特征。编译指的是将开发人员编写的源代码生成可执行的代码。
2.测试。没有自动化、持续测试的持续集成不能算是真正的持续集成。没有自动化的测试，开发人员或其他项目风险承担者对软件的变更很难有信心。
3.审查。自动化的代码审查（包括静态和动态分析）可以通过强制遵守规则来提高软件的质量。
4.部署。持续部署可以在任何时候都可以拿出能工作的、可部署的软件。
5.反馈。持续集成的本质是及时向开发人员和项目风险承担这提供反馈信息。
（三）持续集成的实施要素
持续集成是一个以人为核心的过程，常常与一个或多个工具相关联，但持续集成远不只是个工具。实施持续集成需要五个要素：
1.开发人员。当一名开发者根据分配的任务进行了所有的修改之后，他将执行一次私有构建，然后将变更提交到版本控制库。只有当这些变更提交到版本控制库后，才会开始后续的集成构建。
2.版本控制库。版本控制库的目的是通过一个受控的访问库来管理源代码和其他软件资产的变更。提供一个“单一源代码位置”，这样所有的代码都可以从一个权威的位置获得。同时本版控制库能够进行回溯，取到源代码和其他文件的不同版本。
3.持续集成服务器。持续集成服务器在变更提交版本控制库之后执行集成构建。集成构建可以采用手工、定时和轮询的方式进行。
4.自动构建。持续集成过程会经常集成软件，这需要通过构建来完成。通过使用自动化构建脚本可以可靠地自动执行编译、测试等任务，甚至可以执行代码检查和部署。构建策略是成功的持续集成过程最重要的方面，如果缺少适当的构建过程，持续集成就难以发挥作用。
5.反馈机制。持续集成的一个关键目标是提供集成构建的反馈信息。反馈机制包括邮件、短信息，即时通讯等方式。
三、持续集成在商业银行的实践
近几年，国内商业银行为提高风险防控能力，适应互联网金融的发展需要，快速响应银行客户的需求，纷纷引入了持续集成来降低产品研发风险、缩短产品研发周期，并解决软件研发过程中出现的问题。
（一）持续集成的流程
商业银行的持续集成流程一般都以自动化为基础，以配置管理为核心，通过将配置管理、变更管理和构建管理工具有效集成，实现了代码下载、编译打包、发布部署等功能的标准化、流程化、工具化、自动化，尽早而频繁地构建以尽早发现系统问题、保证系统的正确性。其流程如图所示：
持续集成的工作流程为：
第一，通过集成变更管理与配置管理工具，实现需求变更（缺陷）与代码变更集的对应关系。以需求变更（缺陷）为基础能查询到修改的代码，以变更集为基础查询到对应的需求变更（缺陷）。
第二，对已经完成代码修改的需求变更（缺陷），查询到对应的变更集，将变更集从开发分支归并到测试分支，在测试分支创建全量标记。
第三，将测试分支全量代码下载到集统一编译服务器。
第四，利用构建脚本实现代码的自动化编译和创建程序包。
第五，利用集成的代码检查工具，实现自动化的代码检查并发布代码检查报告。
第六，利用FTP将程序包发布并部署到测试服务器，并执行自动化测试，同时发布测试报告。
持续集成流程涉及的人员角色分别为：
需求或测试人员：针对测试中发现的问题在变更（需求、缺陷、工作任务）管理工具中进行登记。
项目经理：在变更管理工具中将工作分配给具体的开发人员。
开发人员：接受开发任务，在配置管理工具的开发分支建立变更集，同时将变更集和变更管理工具中的任务进行关联。在开发完成后，在本地机器执行完一次私有构建后，将修改后的代码以变更集的形式提交到配置管理服务器。
构建管理员：手动启动持续集成运行流程，并维护相关的配置信息。
业务测试人员：对已完成部署的软件进行测试，并在变更管理工具中填报测试结果。
代码审查人员：查看持续集成服务器自动发送的代码审查报告。
持续集成服务器可以快速地反馈构建过程中的问题，同时也要求项目组对引起构建失败的原因尽快处理，以保障后续阶段的顺利进行。
（二）持续集成的主要功能
持续测试：自动化测试提供对单元测试和集成测试的支持，通过调用自动化测试工具生成测试报告。如有需要，还能给出代码覆盖度分析报告。
持续构建：实现对代码的自动化下载、编译和打包。
持续评审：基于配置库中的代码进行代码规范性检查，检查内容包括商业制定的JAVA编码规范。
持续部署：将构建工作的输出持续部署到目标测试环境，并利用自动化部署脚本完成产品部署工作。
持续反馈：通过各种渠道将上述持续性工作的具体结果分发出去，包括邮件、FTP等方式。
四、持续集成的积极作用
从技术角度来看，持续集成帮助商业银行软件研发团队更高效地工作。这些团队有些是跨部门的，有些是在地理上分散的。持续集成解决了许多传统模式下研发团队都经历过的早期陷阱，使更多人可以利用敏捷研发模式，并让敏捷方法更高效地工作。
从业务的角度来看，持续集成又帮助商业银行提供了更好的业务成果。通过实施持续集成，在问题的早期并且还是小问题时发现它们，而不是等到这些问题变成大问题且更难解决时才发现它们，实现了商业银行将产品更快地推向市场。同时还在产品开发过程中更快速地响应市场需求，为未来的互联网金融打下了坚实的基础。
（一）降低软件研发风险
1.随时随地生成可部署的软件。从客户和用户的角度看，一个可以部署或执行的构建产物才是最重要的。在使用持续集成工具的环境中，开发人员对源文件进行修改、提交，持续集成服务器会将这部分修改与其他的代码进行整合、测试，并重新生成最终产品。如果其中任何一个环节出现了问题，相关人员可以很快得到反馈。在没有使用持续集成工具的环境中，大量的问题只有在产品发布前进行最终集成时才会发现，开发团队往往在发布前承受着巨大的压力，并有可能导致产品延迟发布或者在进行Hotfix（修补程序）的过程中引入更多、更严重的缺陷。
2.尽早发现软件缺陷。持续集成的过程可以帮助开发人员快速发现并解决问题。与开发人员的机器相比，持续集成服务器运行在相对稳定、干净的环境中（可减小跟踪调试的难度）。持续集成过程的失败，通常意味着最近一次更新破坏了软件现有功能或引入了新的缺陷。在持续集成过程结束后，除了构建结果，通常会生成代码分析报告，帮助项目管理人员更好地了解并改善项目。
3.提高软件产品质量。持续集成过程要求开发或测试人员事先编写好很多的测试用例，在代码提交后就对代码进行测试，这样的尽早测试能够最快速地发现软件代码中的错误和缺陷，及时修改，从而提高软件的质量。在项目研发过程中，编写测试用例都至少会额外增加30%的工作量。初看，这些工作增加了工作量，在时间和资金上是很大的开销。然而，在商业银行实施持续集成过程中，要求每个项目必须有明确的测试报告，因此编写测试用例是必要的，而且这样也省去了人工测试的时间，确保了软件产品的质量，有利于提高商业银行软件产品的质量管理。
（二）转变软件研发理念
持续集成的理念是持续集成的灵魂。持续集成的实施不仅是持续集成平台的搭建，更是一个系统性工程，涉及开发理念、测试理念和管理理念的转变。
开发理念的转变。开发人员针对每个变更（需求、缺陷）编写代码，代码提交后触发自动化构建、代码检查和部署测试等。该流程使得开发人员意识到不仅需要编写功能实现的代码，还要确保提交的代码不会造成其他成员的代码构建失败。
测试理念的转变。在开发人员编码时，测试人员要同步编写相对应的测试用例并对已开发功能进行测试，需求人员、开发人员和测试人员组成小团队以并行迭代方式协同工作。
管理理念的转变。持续集成反映了系统开发的真实进度和质量，管理人员从关注计划和文档向关注持续集成的结果转变。应管理和效率并重，持续集成只是管理的一种手段。
要让所有的干系人接受持续集成的理念，商业银行采取了从易到难、逐步推进的方式，从自动化编译开始到自动化代码审查，再到自动化测试，逐步地让项目组成员认识与接受，最终实现整体的自动化。
（三）加强团队之间沟通
软件开发本身就是一项强调沟通和协作的活动，持续集成以制度的形式加强了商业银行不同部门成员之间沟通和协作，因为每一次的构建都会涉及到项目软件团队中的所有成员，“每一次构建的成功，是整个团队的成功；而每一次构建的失败，也将是整个团队的失败”，因而所有成员的最终目标都是朝着每次的成功构建努力。
（四）增强安全感
软件开发过程最终表现为人与人之间各种形式的合作，安全感与信心是合作中最基础也是最重要的。通过使用持续集成工具，开发人员可以了解到新的代码是否引入了缺陷，管理人员可以通过使用各种形式的报告对项目进行评估。不断发布的构建结果，使测试人员得以自始至终地参与到整个开发过程中，而不是在软件开发的最后阶段才加入团队。
五、实践总结
持续集成不仅是一种软件研发技术上的实现，也是一种管理制度的实现，需要整个团队的密切配合才能实现。商业银行大多在历经现状调研、试点验收、实施推广等工作后.最终实现了持续集成在软件研发过程中的顺利实施，并达到了预期的结果，为商业银行信息化的发展开启了全新一页。
参考文献
[1]陈刚，羌铃铃.持续集成在项目中的分析与研究，电脑编程技巧与维护，2011（24）：12-15.
[2]黄永刚，王斯洋.持续集成方法在项目中的应用实践.中国金融电脑，2008（8）.
[3]王英.持续集成在软件项目管理中的作用.福建电脑，2009 （12）.
作者简介：孙绍伟（1981-），男，汉族，北京人，供职于中国农业银行软件开发中心，研究方向：金融信息技术；李明（1971-），女，汉族，北京人，供职于中国农业银行软件开发中心，研究方向：金融信息技术；苏小彦（1982-），女，汉族，河北廊坊人，供职于中国农业银行软件开发中心，研究方向：金融信息技术；姚元庆（1977-），男，汉族，辽宁凌海人，供职于中国农业银行软件开发中心，研究方向：金融信息技术。