中国银行DevOps标准化实践 助力信息科技高质量发展

在数字化转型的大背景下,中国银行已开展DevOps能力成熟度模型评估，聚焦于将应用的开发、测试、部署和运营统一起来，打通了开发、测试、运维端到端的流水线，助力业务部门更快地响应市场变化，满足客户需求。然而也面临着一系列的挑战。

（1）中国银行业务需求覆盖广，信息科技人员众多，各个产品代码组织、实现、部署、环境管理等存在差异，在持续交互方面并没有统一标准和规范。

（2）中国银行软件中心已全面从传统瀑布式开发转向敏捷开发模式，旧的瀑布模式的准则已不适用，但是适用敏捷模式开发的规则还未统一。

一是有些产品采用主干开发模式，提交频繁，冲突多，主干代码不稳定，一旦出问题，所有工作被阻塞。

二是质量落地不可见，依靠制定规范文档，质量管理依赖于人，质量活动可跳过。代码交付质量也缺少量化方法，主观判断大于客观准则。

三是问题反馈较慢，很多问题在测试阶段才能被发现，修复成本较高。

面临上述困难和挑战，有必要实施适合各产品线的规范化、标准化持续交付工艺流程。为此，借着中国银行企业级架构建设项目，开展了标准化、规范化探索实践。

针对面临的痛点，通过探索实践，提出开发测试一体化的DevOps标准化流程工艺方案。以特性分支策略为基础，采用“分支开发，主干发布”的开发模式。以质量内建为原则，通过分级构建与阶段性检查，将质量控制落实到开发的各个阶段以加速质量反馈，做到了缺陷前移和高质量交付，实现了降低成本、提高开发效率的最终目标，贯彻了开发测试一体化的理念。

规范分支管理策略。采用“分支开发，主干发布”的特性分支开发策略，把控与敏捷故事开发相匹配的分支粒度，解决了主干分支开发造成的代码冲突多、不稳定的问题。为此，将代码分支进行了分类，主要有以下5类分支：

Master，用于生产版本的发布。

Release，用于功能版本的发布。

Develop，用于开发环境的版本发布，是迭代开发的主干分支。

Feature，用于特性功能开发，即特性分支。

Fix，专门用于Bug修复的分支。

为了确保开发人员按照设计质量控制流程提交代码，确保标准化流程得到落实，对Master、Release、Develop分支仅允许开发人员通过发起代码合并请求来提交修改，而Feature、Fix分支不设限制，允许开发人员直接进行代码推送，这样既保证了重要分支的稳定性，同时也保证了开发的灵活性。

在规范分支策略的基础上，通过流水线规范化执行，由人为管控转化为自动化流程管控，确保质量标准严格落实到开发过程，落实到应用开发的各个阶段，实现提测前的质量内建。我们将开发流程拆分成七步，并在每一步中，通过制定相应的质量标准，严格按照质量标准进行检测，称为质量内建七步法（如图1所示）。

图1 质量内建“七步法开发”示意

质量检查主要有三类，分别是本地工具检查、人工评审、流水线检查。其中本地检查是一个低成本、高效率的方案，并可以根据不同的开发语言灵活选用检查工具。人工评审的步骤是为了保证代码实现的业务功能的正确性，保证避免代码的功能逻辑的错误。流水线检查则分别提供了日常质量反馈，合并代码检查，部署代码检查的功能，是整个开发流程质量把控的重要组成部分。

第一步：特性分支拉取

根据敏捷迭代故事创建特性分支，一般以故事或子任务维度创建特性分支，要求粒度小，能够三天内开发完成合并到主分支，特性分支需每日都要拉取主分支最新代码，防止长时间封闭开发造成代码冲突。质量检查点，规范分支命名。例如feat/内容/开发人员/日期/批次任务。

第二步：本地代码检查

本地代码修改提交后，触发对提交信息的规范性检查，再通过静态代码扫描工具对本次增量代码进行扫描。本地检查具备效率高，纠错成本低的优点。本地代码检查不同开发语言可以选择适合自己产品的检查规则。要求质量标准：一是提交信息符合规范；二是代码符合语法规则。

第三步：CI集成流水线

特性分支代码提交后，会触发特性分支流水线检查，并通过质量红线检测不符合质量规范的代码。这个节点的质量控制点在Sonar代码扫描之后，设置了日常构建质量红线，包括0bug，0漏洞，0坏味道，也设置分支覆盖率指标和案例100%通过。

第四步：预编译流水线

由于Develop主干分支为保护分支，因此，特性分支功能代码编写完成之后，开发人员需发起合并到Develop分支请求，当开发人员发起合并请求时，Git会自动创建一条对应的评审记录单，也会触发对应分支合并请求的预编译流水线。这里会要求开发人员将本次合并的流水线执行情况贴在记录单上面方便后面评审。

预编译流水线质量控制点和标准主要包括：

（1）代码合并无冲突，若冲突直接停止。

（2）通过日常构建质量红线以及构建过程无问题。

第五步：代码评审

评审人员在看到对应的流水线执行成功记录之后，进行代码评审，这个阶段主要是人工代码走查为主；代码评审质量控制点主要是代码业务逻辑走查以及单元测试有效性走查。要求是符合团队内的代码走查checklist，满足业务逻辑要求，单元测试有效。评审通过才可以合并代码。能够保证每次变更都必须走查，走查也及时，范围清晰，基于GIT系统沟通成本低，缺陷修复成本也低。

第六步：CD流水线

评审通过之后，流水线使用变基合并分支，自动触发部署流水线，成功之后通知迭代测试人员对故事测试。

CD流水线质量控制点和质量标准主要是质量红线设置，除了要通过日常构建质量红线之外，还要通过安全插件的质量红线。

第七步：迭代测试

部署流水线通过后自动完成代码部署，并触发ATP自动化测试组件，同时开发人员可将对应迭代故事交付测试。

除了以特性分支策略的质量內建七步法，各产品线可以根据产品特点，持续自研相关工具，丰富DevOps工具链，进一步提升开发效率，减少人工出错的机会。如SQL脚本、测试脚本编写等。

通过实际项目开展DevOps标准化工艺的实践，并总结经验，取得成效如下：

通过实践，统计发现迭代开发阶段发现的缺陷（包括质量红线拦截、代码复查）占比76.5%，迭代测试阶段发现的缺陷占比18.1%。在DevOps标准化工艺实施下项目的缺陷前移效果显著。绝大多数的代码质量问题在开发阶段通过本地检查、预编译流水线和代码合并前评审等环节发现并解决，有效降低解决问题的成本，交付测试的代码质量得到提高。

采用主分支开发的时候，流水线失败比例非常高，执行成功率仅为65.7%。开发人员一直忙于解决流水线红灯问题，由于多人并行提交或合并代码导致定位问题更加困难，很难保证CI纪律。在采用预编译流水线之后，通过代码扫描和预合并编译等手段检查提交代码质量，流水线执行成功率达到99.3%。开发人员通过使用预编译流水线保障部署成功率，提高代码交付质量，保障迭代测试环境的稳定。

未采用分级构建，开发人员前期使用单流水线串行的方式一次性完成代码提取，代码检查、单元测试、代码编译和部署等多个环节，每次等待流水线执行完成的时间需16分钟以上。同时由于单一串行的方式，各阶段反馈质量问题速度较慢，无法及时跟进解决。

采用分级构建方式，将原有的单流水线串行分拆到不同环节的流水线上并行处理，资源利用率提高，整体耗费时间得到有效降低，各阶段发现的缺陷问题均能及时获得反馈，更早被开发人员捕获并解决，解决问题成本更低。

分级构建前后如图2所示。

图2 分级构建前后示意

通过实践验证，为中国银行数字化转型的DevOps提供标准化参考指南，除了实现了缺陷前移，质量内建，更重要的意义在于此标准化工艺流程可以很好地屏蔽因开发人员的水平参差不齐而带来的差异，保证开发效率和质量。

标准化不是终点，而且新的起点，未来在DevOps标准化过程，将逐步完善各个阶段的功能和DevOps工具链，推动自动化端到端测试等，进一步提升自动化率，推动产品的高质量建设与交付。 

前期精彩原创推荐（点击图片进入阅读）：

这是科技创新最好的时代，这是属于我们每个人最好的时代，关注“BanTech智库”，专注银行科技发展，探索无界金融生态！