基于DevOps的流水线可视化自由编排方案与实践

居彬 王启威 谢承翰

（中电鸿信信息科技有限公司 江苏省南京市 210029）

1 引言

某电信企业承接多种类型产品和项目的开发运维工作，具体归纳有如下几点：

（1）企业内部产品项目，如本企业内部自研自营系统及平台；

（2）企业承接电信体系内项目，如某单位的故障预处理系统；

（3）企业承接电信体系外项目，如政企项目。

随着软件系统架构复杂度的增加、项目规模、交付成果和交付环境要求差异逐渐扩大, 规范化和标准化的构建和交付流程往往成为影响产品成败的重要因素。如何在满足研发管理规范的前提下解决这一问题，成为企业亟待解决的关键。

2 相关工作

近年来，微服务、容器技术以及各种自动化运维工具的发展，大大推动了DevOps 的研究、实践和应用，业界诸多企业及学者对其进行了广泛研究和应用。文献[1-2]关注DevOps 在国内的发展中，得出如Docker、Jenkins 等60 多个自动化工具带来的实际影响以及其带来经验和问题。在文献[3]中探讨了持续集成/持续交付过程可视化的结果，可以大大提升信息共享的效率和效果；文献[4]提出了通过可视化方法，对敏捷团队中各成员的贡献进行统计和呈现。

综上文献调研结果与思考，本文提出一种基于DevOps 的流水线可视化自由编排方案，来解决企业实践中遇到的问题。

3 方案设计

3.1 流水线可视化自由编排

针对固化的CICD 流水线导致DevOps 执行困难或失败情况，本文创新性的引入流水线“可视化”+“自由编排”任务的方法来解决。在前端视图中，组织级管理角色拥有权限可对任意任务，如更新代码、单元测试、静态代码扫描等进行灵活的排序。故，针对某一项目实际情况，可制作出不同的CICD 流水线模板以供使用。

3.1.1 步骤1.流水线原子任务模型定义

通过组织级调研，分析研发过程涉及的系统和工具，分解并抽象出系统原子任务，并且提取这些任务在不同项目中特异性的配置作为任务的参数，如更新代码任务的分支配置、部署任务的环境选择和配置等，部署任务应提供多种环境供用户参考选择，如开发环境、测试环境、预发布环境、生产环境。

其中原子任务包括两大类，固有任务指流水线阶段初始配置中固定存在的任务，包括准备任务、更新代码、单元测试、静态代码扫描、编译打包、构建镜像、部署、晋级、自动化测试、发布；通用任务指流水线阶段初始配置中可自由选择的任务，包括邮件通知、人工审批、自定义脚本。

3.1.2 步骤2.流水线阶段模型定义

图1：总体技术方案流程

分析出项目或产品研发过程中的所有活动，并设计出流水线阶段，流水线阶段一般根据软件所处环境和涉及人员角色来进行划分。流水线阶段中包含流水线阶段名称、固有流水线任务、通用任务的配置，值得一提的是，流水线阶段名称可以与原子任务重名，以明确显示该阶段的作用。如流水线阶段名称为更新代码，可为其配置更新代码固有任务，以及邮件通知、人工审批等一种或多种通用任务。如此配置，在项目流水线初始化中，使得流水线阶段具备自由选择通用任务的能力。

3.1.3 步骤3.可视化自由编排流水线模板模型

流水线模板的制定，简化了流水线初始化流程。具体来说，流水线模板中包括模板名称、流水线阶段和流水线阶段顺序的定义，基于此可提供一种流水线模板可视化自由编排能力。在前端视图中，通过添加流水线阶段的操作，可添加步骤2 里定义的流水线阶段，通过删除流水线阶段操作，可去除步骤2 中定义的流水线阶段，两者结合可实现流水线阶段顺序的自由编排。

通过此方法，可自由编排适合各类项目或产品的CICD 流水线模板，以供流水线初始化时选择使用，完美解决了固化的CICD 流水线使用不佳的体验。

3.1.4 步骤4.流水线初始化

流水线初始化时，重点研究论述流水线初始化中，流水线模板的选择以及配置。

假设流水线模板选取代码检测模板，选择更新代码阶段时，可指定更新代码这个固有任务的分支；同时，亦可添加一种或多种通用任务，并配置通用任务的参数信息，如添加邮件通知任务，添加邮件通知地址，或企业微信、短信账号等；亦可配置通知方式，如执行成功/失败时进行通知。因某一流水线阶段下可能含多种任务，为方便调整这些任务顺序，前端视图具备拖动改变任务执行顺序功能，通过此举，实现了在流水线初始化时期，流水线任务的可视化自由编排。

需要指出，已创建的流水线原子任务信息、流水线阶段信息、流水线模板皆存储于Mysql 数据库中。

3.2 流水线可视化监控

针对在CICD 流水线执行过程中，如何建立可视化的流水线监控功能，方便开发运维人员对问题的及时定位与解决，本文提出以下方案：

后台服务程序通过定时任务调用JenkinsAPI，一方面同步流水线状态，另一方面获取运行中流水线日志，经服务程序处理后，将运行状态与运行时间等信息通过Websocket 返回前端显示；日志存在ES 数据库，状态，时间等信息存在MySQL 中流水线记录表中。基于此，可实现如下流水线监控内容：

（1）流水线的最新执行状态；

（2） 流水线最近的执行信息：流水线实时日志、阶段日志、任务日志、流水线状态、任务执行状态；

（3）展示或下载执行任务产生的报告或制品；

综上所述，流水线监控可贯穿流水线构建每一个阶段。

3.3 总体技术架构与流程

为形成完整的方案架构，需选择实用的运维工具，本文选择Git 作为版本控制；Sonar 作为代码扫描工具；Katalon、JMeter 等作为自动化测试工具；Jenkins 作为集成部署工具等（不包含全部工具）。

本文技术方案流程大致如图1 所示。

后台服务程序作为整合各类资源的核心中枢，负责连接前端、Jenkins 服务器、制品库与数据库服务器，其主要任务有接收前端请求、调用JenkinsAPI、响应结果的处理、执行定时任务（获取运行中流水线日志、同步流水线状态等）、更新与获取数据库信息、执行制品下载任务等。

数据服务器A（MySQL）存储组织级研发管理角色创建的流水线任务、阶段和模板信息；项目或产品团队根据自身项目需求，在前端选取合适的流水线模板并进行流水线配置，初始化流水线后，后台服务程序一方面将配置信息存储在数据服务器A 流水线配置表中，另一方面服务程序以配置信息为基础，调用JenkinsAPI，在Jenkins 服务器中创建持续集成或持续部署流水线；当开发人员通过提交业务代码/合并代码，或在前端手动启动流水线操作，均可触发流水线构建；构建记录同步于数据服务器A 的流水线记录表中，运行中日志信息同步于前端流水线详情页中，运行结束日志存储于数据服务器B（ES 数据库）中，以供查看历史构建记录以及实现流水监控；流水线任务构建中产生的War 包、Docker 镜像等制品，经Jenkins 服务器推送到制品库中，通过后台服务器处理，可在前端展示或下载。

4 企业实践

根据第3 节的研究，可对引言中三类项目的困境实施以下方案：

4.1 自营产品A

根据本方案，设计出自营产品A 的持续集成流水线：开始-》更新代码-》单元测试-》代码检测-》编译打包-》构建镜像-》开发环境部署-》制品晋级-》测试环境部署-》自动化测试-》结束；设计出自营产品A 的持续部署流水线：开始-》更新代码-》制品晋级-》预发布环境部署-》自动化测试-》制品晋级-》生产环境部署-》结束。

软件产品A 的团队通过使用上述配置的持续集成流水线可以对每次的代码提交进行测试、集成、上传制品以及开发、测试环境部署验证，及早集成并发现代码阶段问题，降低产品集成和发布的风险。

大规模应用基于流水线的精益平台，项目生产率从4.037 人时/功能点提高3.99 人时/功能点，每轮迭代可实现的功能点数从78.474 提高到80.984。项目生产率的模型公式是：6.39 - 0.0529*开发人员技能水平 - 0.0188*sprint 开发规模（功能点）- 0.951 *需求一次接收率。通过蒙特卡洛模拟和假设检验，将迭代规模从78.474提高到80.984，能够满足项目生产率的要求。

通过此方案的实施，帮助企业顺利取得CMMI 成熟度5 级资质，并通过信通院首批《DevOps能力成熟度模型标准八》的工具评估（持续集成、流水线）两项优秀级。

4.2 智能预处理系统B

电信体系内项目，在打通本企业与客户企业之间的网络后，按照客户要求，需选择不同的部署环境，开发环境是部署在本企业开发环境上，测试和生产环境部署在客户机的生产环境上。具体流水线可参考企业内部自营项目的选择，需要注意的是，在配置部署任务时，按照客户需求来指定部署环境。

通过本文提出的方案，项目集成频率从一周一次缩短到一天一次，发布频率从一月一次缩短到一周一次，发布成功率从75%提高到100%。

2019年12月，智能预处理项目B 顺利通过了由中国信息通信研究院（简称信通院）开展的《研发运营一体化（ DevOps ）能力成熟度模型》持续交付部分3 级评估。

4.3 某政企项目C

电信体系外项目，因某政企项目C 网络需要隔离，无法直接将制品部署到生产环境，这种情况下，需要配置一条不包含部署阶段的流水线，通过平台构建后，将构建生成的制品通过安全合规的方式，部署到政企内部的生产环境上。

通过该方案，交付的代码质量和开发效率得到了显著提高，交付质量得到了提高，提升了客户满意度。

5 总结

企业实践证明，采用本文方案既满足了不同形态产品的交付要求，又提高了交付效率，保障了交付质量。此外，为进一步提升产品下若干条流水线的自由编排能力，解决微服务构架项目中构建与部署流水线难以自动化执行问题，产品流水线编排设计将是本团队下一步的研究重点。