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

持续交付及其在大型项目中应用 　　摘要：敏捷软件开发方法已渐成主流，持续集成作为敏捷开发的最佳实践，近年来应用广泛。如何让软件从“开发完成”迅速实现“交付使用”，解决“最后一公里问题”，是不少企业孜孜以求的目标。持续交付以持续集成作为基础，使得频繁且可靠交付成为常规活动。结合G产品开发过程，对持续交付进行了详述。 　　关键词：敏捷开发；持续集成（Continuous Integration， CI）；持续交付（Continuous Delivery， CD）；G产品；Jenkins环境 　　DOIDOI：10.11907/rjdk.171744 　　中图分类号：TP319文献标识码：A文章编号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发