持续交付及其在大型项目中的应用

2017-11-02张文林

软件导刊 2017年10期

张文林

摘要：敏捷软件开发方法已渐成主流，持续集成作为敏捷开发的最佳实践，近年来应用广泛。如何让软件从“开发完成”迅速实现“交付使用”，解决“最后一公里问题”，是不少企业孜孜以求的目标。持续交付以持续集成作为基础，使得频繁且可靠交付成为常规活动。结合G产品开发过程，对持续交付进行了详述。

关键词：敏捷开发；持续集成（Continuous Integration， CI）；持续交付（Continuous Delivery， CD）；G产品；Jenkins环境

DOIDOI：10.11907/rjdk.171744

中图分类号：TP319文献标识码：A文章编号：16727800（2017）010015903

0引言

随着通讯技术的快速发展，用户需求也愈来愈多样化，随之而来的是企业间竞争的加剧。迅速、高效、高质量的产品发布成为企业有力的竞争法宝。通讯产品特有的高复杂性，对软件的实时性、稳定性、环境适应性提出了更高要求。作为一种发布可靠软件的系统方法，持续交付通过一系列的原则和技术实践，解决了传统软件发布中普遍具有的周期长、风险高等问题[1]。

G产品是B公司针对市场推出的一款新一代产品，要求开发周期短，且能够按时高质量完成交付。因为“替换竞争对手产品”需求的特殊性，高效高质量交付成为关键。B公司虽引入了敏捷开发模式Scrum，在持续集成、快速迭代、测试驱动开发等方面开展了一些实践，但从整个产品交付周期来看，仍存在开发周期较长、风险较高的问题。因此，公司决定在现有敏捷开发模式下引入持续交付的系统方法。

1持续交付系统方法

持续交付指软件从版本控制库到用户手中这一过程的自动化表现形式[4]。软件的每次变更都会经历一个复杂的流程才能发布，包括软件的构建提交以及后续一系列不同阶段的测试与版本管理，这些活动通常需要多人或多个团队协作。持续交付描述的是从原始需求识别到最终产品部署过程中，以小批量的需求形式在各环节间顺畅流动，在短周期完成需求的小粒度频繁交付，使软件的反馈更及时。这种方式促进了需求分析、产品的用户体验以及交互设计、开发、测试、运维等角色之间的密切协作。相比于传统的瀑布式软件开发方法，效率明显提高。

为实现持续交付，需遵循一系列软件交付原则[4]：①为软件发布创建一个可重复且可靠的过程；②尽力将所有事情自动化；③将所有内容都纳入版本控制；④提前计划；⑤内建质量；⑥“DONE”意味着“已发布”；⑦交付过程是每个成员的责任；⑧持续改进。以上原则对应持续交付系统方法的不同阶段。

2持续交付阶段

2.1提交阶段

提交阶段包括配置管理和代码检查两个部分。

配置管理目的是保留每个文件的所有版本历史信息，并使之易于查找；持续交付必须以全自动化方式进行，以全自动化方式构建、测试并部署软件，源代码、测试脚本、构建与部署脚本等都必须纳入版本管理[3]。

將所有事项都纳入版本控制，意味着每个团队成员都使用相同的配置，团队成员发现问题、提交问题、讨论问题都在同一个语境中；同时，任意成员（不一定是团队成员）也可根据需要直接提取代码，部署可运行的软件版本。

代码检查指开发人员在编写完代码后，将代码提交到“源代码库”，从技术角度确认整个系统是可以工作的。开发人员一般做一些简单的编译、代码审查和单元测试工作。这些代码检查工作多为自动化检查。因为是针对个人代码的检查，所以无法集成到整个开发团队的CI环境中。

2.2自动化验收测试阶段

自动化测试环境和脚本由开发人员和测试人员合作创建。开发人员和测试人员是相对的。敏捷团队可跨职能，团队里每个人都可以是测试人员[5]。自动化验收测试阶段一般要构建和集成一个CI 环境，以保证代码的编译、单元测试、组装打包、代码分析（CppCheck、Coverity等）、冒烟测试、模拟环境测试等部分自动化运行并反馈结果。

尽可能自动化是持续交付的前提条件。构建过程自动化使代码频繁提交成为可能；单元测试、集成测试、验收测试的自动化，使持续集成成为可能；数据库升级自动化、网络配置自动化，使持续交付成为可能。

每个阶段的自动化测试运行时间以及复杂性要适度。过长或过于复杂的自动化测试会影响执行；自动化测试时间太长，会导致下一次自动化测试包含多次提交，难以及时准确发现问题，同时，提交的效率也会降低，因为大家会坐等上一次自动化测试的完成。

2.3手工测试阶段

手工测试阶段主要用来发现自动化测试没有捕获的缺陷，是自动化测试的补充。手工测试一般在Sprint结束之后产品发布之前进行，测试人员要反复做几轮测试，以确保产品质量[2]。手工测试通常包括探索性测试、性能测试以及用户验收测试。

2.4发布阶段

发布阶段指在试运行环境上进行冒烟测试和集成测试。

发布阶段不同测试反馈周期不同，运行规律就不同。单元测试是代码提交的基本测试，要求周期短、反馈快，一般要在半小时内完成。自动化验收测试又分为验收基本功能的冒烟测试和验证全部功能的集成测试，前者一般要求一两个小时内完成，后者一般要求当天完成。

2.5度量

这里把度量单独列出，是为了强调合理度量的重要性。度量存在于上述各阶段中。从持续交付流程图（见图1）可以看出，所有的流程都是为了尽快得到反馈，以期提高质量以及持续改进。而改善反馈的最佳方法就是缩短反馈周期，并让结果可视化。衡量持续交付软件系统的能力指标不是通过自动化测试发现的缺陷数目，也不是团队成员代码提交的速度，而是持续交付的反馈周期。提交代码后自动化测试周期有手工测试周期、发现缺陷周期、发现缺陷后解决问题的周期。通过观察持续交付流程中的各个阶段，发现周期时间的关键路径，找到办法缩短它。endprint

3实践与应用

G产品由于需求的特殊性，交付速度成为产品成败的关键，不能及时交付就意味着机会成本的增加。为快速交付高质量的软件产品，需要频繁且自动化地发布软件。基于这一目标，G产品采取了以下步骤、方法。

3.1G产品配置管理

G产品配置管理工具采用Mercurial。Mercurial是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。

G产品与项目相关的所有内容都提交到版本控制库，包括产品代码、测试代码、构建和测试脚本，以及相关第三方工具、软件。

G产品每个版本保留的信息：①当前版本号；②Baseline，也就是修改的上一个发布的版本号；③修改记录。通过这些信息可以清楚地找出两个版本之间的差别。

G产品代码采取主干加分支的管理策略。分支的目的是帮助团队进行并行开发，即在同一时刻同时在两个或多个工作流上开发，且不会互相影响。每个分支的代码合并到相应主干时进行一系列測试。合并和测试都是自动化持续完成的。最后交付到release branch或者MS（mainstream）上的代码，就是可面向用户发布的代码（见图2所示）。

图2G产品分支策略

采用分支的另一个好处就是G产品开发团队的每个成员都可频繁提交代码，不用担心影响到其它功能或软件版本。频繁提交代码优点：①由于每次改动都比较小，所以很少会构建失败。即使构建或后期测试失败，也很容易查找出问题或回滚到上一个正确的版本上；②查找问题或回滚的代价较小。

3.2G产品自动化测试

G产品自动化测试：①代码静态检查，包括代码构建、Cppcheck、Coverity。代码静态检查一般几分钟就可完成；②单元测试。这里的单元测试主要是系统级的，也就是集成了所有软件模块的单元测试。开发人员在提交代码前会单独进行模块级的单元测试，模块级的单元测试一般时间很短，易于执行，可以是手工的，也可以是自动化的。系统级的单元测试一般十几分钟就可完成；③冒烟测试。主要针对系统基本功能及已经提交成功的部分新功能进行测试。冒烟测试要求测试时间短、反馈速度快。G产品的冒烟测试一般会在一小时左右完成，每次构建成功后会触发运行；④回归测试。回归测试主要用来保证新的版本不会破坏原有版本功能。由于G产品的复杂性，其回归测试的case比较多，测试周期也较长，大概1 100多个case，需要运行8个多小时，所以一般放在下班后执行，晚上10点左右触发，第二天早上就能看到结果。

反馈是所有软件交付流程的核心。改善反馈的最佳方法是缩短反馈周期，并让结果可视化[3]。G产品针对这两点作了相应处理。

为了缩短反馈周期，G产品不仅从自动化测试用例上拆分为冒烟测试和回归测试，在构建上也进行了拆分：①基本构建只编译新功能和尽可能少的原有功能，以保证在半小时内反馈结果。基本构建的触发条件是有人提交代码；②完整构建，编译所有功能时间较长，一般要2～3个小时。完整构建的触发条件是每隔3小时触发一次。

G产品结果可视化方法：①自动化集成结果图的可视化。通过显示器显示，团队成员抬头就可看到当前的执行结果是红色的（失败）还是绿色的（成功）；②每个测试结果都会自动发邮件到相关开发人员邮箱，邮件标题提示本次结果是失败还是成功，邮件内容包含当前执行的版本信息及改动人信息。如果是失败邮件，相应人员可很快定位到哪个改动影响了本次运行。

3.3G产品手工测试

G产品自动化测试全面，但由于产品的复杂性，需要在不同环境下作一些其它测试，如容量测试、探索性测试、易用性测试等，这些需要开发人员手工完成。

G产品自动化测试平台可每天发布一个版本，手工测试人员不仅可每天得到一个确定可用的版本，还可查看每个版本的修改记录，比如某个高优先级的缺陷是否解决？某些新功能是否加进来？从而选择自己想要的版本。

G产品手工测试周期比较长，一般需要一周时间。

3.4G产品版本发布

G产品版本发布要根据手工测试的结果确定，所以需要手工触发自动化发布流程。手工触发指需要手工输入版本号，然后一键式触发发布。

发布测试阶段包括boot软件烧制、APP软件下载、试运行环境上的自动测试等。如果成功，会进入批量发布阶段。批量发布只包括boot软件的烧制、APP软件下载。图4是运行发布流程的jenkins环境。

图4G产品CI环境——发布环境

4结语

本文结合实际案例对持续交付系统进行了研究和探索，可作为相关开发和应用的参考。希望软件开发团队能够正确认识和使用，从而高效地创造出具有国际竞争力的高质量产品。

参考文献参考文献：

[1]林鑫瀚.敏捷方法与小型团队的软件开发[J].软件导刊，2009（9）：2931.