基于DevOps的轻量级持续交付方案①

王红蕾

(青岛科技大学 信息科学技术学院,青岛 266061)

随着互联网市场竞争日趋激烈,市场逐步细分促使产品的个性化需求不断增加,众多互联网产品如何在激烈的市场竞争中获得用户青睐,能够快速适应市场需求变化并能实现高质量持续交付是关键.为适应不断变化的市场需求,产品的持续交付需要重复整合需求分析、设计、编码、测试、部署和维护各阶段工作,大量重复、缺乏协作的工作严重制约团队效率和产品质量提高,DevOps 模式下的pipeline 流水线可以实现从版本控制库到交付用户过程的自动化[1],成为互联网产品开发与管理的可行途径.

1 国内外研究现状

近年来,DevOps 在国内外已有广泛的研究和实践,并在不同领域、不同行业证实基于DevOps 模式的项目研发,在系统质量控制和缩短客户的交付响应时间上有突出的表现[2-4],可以显著提升产品持续交付的质量和效率[2,4,5].然而,DevOps 的实践没有固定模式,受制于公司的规模、架构和文化,呈现多样性特征.Roche结合自己在Amazon,Adobe 公司大型项目研发经验,提出了一种多角色协同的DevOps 模式,并研究了该模式下的质量保障体系[6];Kamuto 等研究了大型分布式项目中DevOps 实施的各类制约因素[7];Rajkumar 等研究了DevOps 文化在基于云环境下的产品交付和开发的影响,指出DevOps 模式需要对组织机构、管理策略等进行较大的改变[8].而由于交付的频繁,能够设计符合企业实际的自动化交付方案,确保软件处于一个稳定的、可随时发布的状态,是持续交付实践的关键.Krusche等提出了利于持续交付工作流快速交付产品的模型[9].Düllmann 等提出一种基于DevOps 实践的高可靠性的持续交付流水线实现方案[10],Shah 等探讨了采用Jenkins、GIT 等自动化工具构造持续交付流水线的可能模式[11].文献[4,12] 调研了国内外众多知名企业DevOps 实践,实践过程中使用的自动化工具进行调查,其中Jenkins、GIT、Docker 被广泛应用[13].随着DevOps的日益成熟,其逐渐成为大型互联网企业首选模式,而中小规模企业实施持续交付时完全借鉴现有的DevOps模式,难以落地.一方面企业规模、管理模式、人员结构存在差异,完全抛弃企业原有的辅助工具、管理模式成本较大;另一方面随着发布频率提高,产品维护和升级操作频繁,身兼数职的人员难以完成工作.

针对DevOps 模式在中小规模企业实践存在的问题,提出了一种轻量级的持续交付方案,将软件交付流程进行优化,通过调查问卷的形式了解区域互联网企业的DevOps 应用现状和特点,以企业实践和组织成员访谈论证了方案的可行性

2 轻量级持续交付方案设计

以灵活的自动化形式实现从版本控制库到交付用户的方案,首先要选取相应的工具,目前在版本控制、代码扫描、自动化测试、构建和部署等方面的主流使用工具如表1所示.

以开源性、可扩展性和操作简便性为原则,本文使用GIT[14]作为版本控制工具以Jenkins[13]为持续交付服务,集成sonar 进行增量式代码扫描,以Maven 完成自动编译和打包,在Robot Framework[15]框架下编写自动化测试用例.

表1 主流工具对比

新功能的开发或缺陷问题的修复产生软件版本的迭代,开发人员将产生迭代的代码提交到版本控制库时便触发一次产品的交付.这包括将代码集成后交付给测试人员进行人工验证以及在生产环境上线部署交付到用户使用.由于项目的频繁更新迭代,将记录交付测试、用户的流水线脚本和测试脚本以版本库的形式实现保证了交付过程能够持续进行[4],一个完整的轻量级持续交付方案如图1所示.

(1)无论是新功能开发完成还是线上问题修复均需要在测试环境验收通过才能交付用户,项目交付到测试人员时,代码编写规范、空指针、内存溢出等规范性和阻塞性问题要尽早发现,同时保证本次提交不能对以往版本产生影响,因此项目远程仓库更新后,持续交付服务自动调用已编写有代码审查、单元测试、打包和回归测试的流水线构建脚本.执行完成后以邮件的形式通知测试和开发人员,若执行失败开发人员进行代码修复,反之成功则将当前版本打包归档,测试人员开始冒烟测试和系统测试,测试通过等待上线.交付到测试的流水线脚本结构如图2所示.

图1 轻量级持续交付方案

图2 交付测试的流水线脚本结构

(2)为了实现后续快速上线,执行交付用户的流水线过程如下:

① 代码获取:新代码在测试环境验收通过后手动合并到主分支,通过git clone 的命令获取主分支上的代码以便在后续的阶段中部署到生产环境.

② 构建:Maven 项目的构建以mvn clean package命令完成编译和打包的过程.

③ 部署:部署时实行停机更新时是先停止服务的进程,把项目打包完成后将war 包放到指定路径启动服务.

④ 通知上线结果,应用构建部署成功则通知相关人员并将当前版本的包归档,若部署失败则相关人员根据构建日志进行问题修复.

交付用户的流水线过程如图3所示.

图3 交付用户的流水线结构

3 实验

3.1 行业调查

为调查青岛市互联网企业组织现状,反映DevOps应用特点,为企业实践提供组织管理依据,本文通过第三方调查平台发起调查问卷.问卷设置问题均为客观选择题,第一部分组织管理问题,包括:组织实施模型、团队自动化程度、员工培训投入、团队DevOps经验,第二部分为IT 组织性能调查,问题包括项目交付周期和部署频率.

问卷中将组织模型分布设置为4 类,主要探讨不同模型在项目交付上的区别.其中瀑布模型依次进行设计、开发、测试和运维过程,开发周期长,项目成果整体交付[16];敏捷和瀑布混合模型下交付方式视项目需求而定,在新功能的引入和缺陷修复中使用敏捷方法[17];敏捷模型项目采用敏捷开发方法逐渐迭代[18];DevOps 模型则高度引入自动化测试,实现持续集成和持续交付.

经过统计共收到72 份有效的问卷,其中仅有9%的企业组织过程能采用到DevOps 过程模型,有24%的企业能够实施敏捷模型,而67%的互联网企业仍然采用瀑布模型或瀑布模型与敏捷相混合的过程.组织模型的分布如图4所示.

① 员工培训投入包括:未对员工进行任何新技术培训;关注员工业务知识培训;定期组织技术分享会议.在统计中85%的DevOps 企业定期组织技术分享会议,占整个调查的30%.

② 自动化程度:无自动化工具;仅使用自动化进行问题验证;有涉及集成和交付的自动化岗位.在统计中仅27.8%的公司能够设立专职的自动化岗位,DevOps企业均有专职的自动化岗位,占其中的35%.

③ 团队DevOps 经验调查的问题包括:无相关经验;仅对DevOps 有学习了解;关键领导岗位有DevOps实践经验.其中对DevOps 有学习了解或经验的占总数的43.05%,而所有的DevOps 应用企业关键领导岗位均有DevOps 实践经验.

图4 组织模型分布

结论1:DevOps 在青岛互联网企业中应用较少.而企业要成功实施DevOps,一方面要重视团队技术培训的投入提高组织自动化程度,另一方面,一个有较强领导力的团队领导也是DevOps 能够成功实施的重要因素.

如图5所示,在组织模型与交付周期关系的图表中,瀑布模型或瀑布与敏捷混合的两个过程中分别有30%和7.69%的企业存在项目延期的情况,分别有40%和61.65%的企业交付周期在3～4 周完成交付,仅有30%和30.77%的企业交付周期能实现2 周完成一次交付,无企业在这两种形式下进行1 周完成多次的项目交付,而敏捷模型和DevOps 模型的企业中有12.50%和66.67%的企业能在一周完成多次的交付.

图5 组织模型与交付周期

如图6在组织模型与部署频率关系的图表中,采用瀑布模型的企业70%的部署频率为每月部署一次,无企业的部署频率在一周部署多次;瀑布和敏捷混合的组织模型中相比较瀑布模型的部署频率更多的达到每2 周部署一次,仍然无企业实现1 周部署多次的情况;在敏捷模型过程中75%的企业能实现1 周部署一次,无企业部署按月进行,相比较前2 种的频率有所增高,DevOps 模型中首次出现1 周部署多次的情况,所占比例为33.33%但大部分即66.67%的部署频率在一周部署一次,相比较前3 者的部署频率最高.

图6 组织模型与部署频率

结论2:随着企业采用的组织模型由瀑布模型向敏捷模型、DevOps 模型的过程转变项目交付周期逐渐缩短,相对应的部署频率也就越高,这与敏捷模型和DevOps 模型提倡项目迭代和持续集成的目标是一致的.

3.2 轻量级持续交付方案企业应用分析

自2019年1月,S 公司开始在原有敏捷开发的基础上采用轻量级的交付方案,并在持续交付服务基础上研发了持续交付管理平台,如图7所示的流水线管理模块,在新建一条流水线后可灵活选择验证过程和回归测试用例,对交付流水线进行修改、查看详情、执行流水线以及删除操作.如图8所示的项目迭代管理是对上线功能的版本管理同时进行发布.

图7 流水线管理模块

图8 项目迭代管理

经过一段时间的实践在项目交付能力和交付质量上有较明显提升.如图9所示,以交付周期和部署频率体现项目的交付能力,敏捷方法的交付周期和部署频率在10 天左右,采用轻量级方案后交付周期和部署频率有下降到6 天作用,交付能力得到提高.

项目变更失败比例是指在项目上线时需要进行系统修复的比例,包括代码回滚、服务重启、缺陷修复等现象,以项目变更失败比例来衡量项目交付质量.如图10所示,采用流水线方案前失败比例在8.5%上下浮动,而采用方案后交付过程进行标准化操作,降低了人为操作失误,同时测试更加充分,失败比例逐步降至4%左右.

图9 项目交付能力对比

图10 项目变更失败比例对比

修复问题的过程是开发人员修改完代码后交由测试人员进行验证,验证通过交由运维部署上线,如图11所示,原敏捷过程通过查找代码提交记录和运维记录可粗略统计平均在3.5 小时.而采用流水线形式之后自动化回归验证通过可直接上线,用时逐步下降到2.5 小时.

图11 问题修改平均时长对比

4 总结

本文在敏捷过程的基础上将项目交付中重复度高的工作利用自动化工具,使用流水线形式实现,通过问卷调查明确企业要实施DevOps 需要进行的组织管理改进,对存在角色重叠的互联网企业使用流水线前后的组织性能包括项目交付能力和交付质量进行对比,为企业实施DevOps,实现持续交付提供了参考.

本文的不足之处主要体现在两个方面,一方面在流水线方案中,一个流水线执行完测试验证需要上线时要进行申请,经过专人确认后方能上线,需要申请的原因是当有多个功能需要上线时防止项目代码相互覆盖,如何有效的解决上线等待问题将是今后的研究方向.另一方面本文调查问卷仅对青岛市企业进行统计且企业数量相对偏少,在今后将对不同地区互联网企业的持续关注,不断完善调查报告.