国内领先！郑州银行核心业务系统 DevOps 持续交付实践之路（附PPT）

2019 年 5 月 14 日 DevOps时代

编者按：2019 年4月12日，在 GOPS 2019 · 深圳站上，郑州银行”新版核心业务系统“ 通过 DevOps 标准之持续交付能力 3 级评测，同时，郑州银行成为全国首家通过 DevOps 标准评估认证城商行，其核心业务系统的 DevOps 持续交付能力被认定为国内领先水平。

郑州银行从2018年9月开始接洽到决定参评至今，其核心业务系统已经完成了270多个持续交付能力提升点。对比之前做的主机型号升级项目，功能测试和性能测试从三个月缩短到半个月（评测后）。

核心业务系统功能点重要收益如：

平均交付时间缩短了20%；
缺陷逃逸率降低了30%；
新增代码单元测试覆盖达到44%；
日均自动化部署次数提升了60%；
功能和性能测试周期从12周缩短到2周；
每轮回归测试节约467人天。

GOPS 2019 · 深圳站，郑州银行技术测试负责人刘婷带来了全国首家通过 DevOps 标准评估城商行的持续交付实践之路。

作者简介

刘婷
郑州银行

技术测试负责人

首先介绍一下郑州银行，肯定很多人不太熟悉。郑州银行是位于河南一家城商行，目前在H股和A股上市，在城商行的排名比较靠前，属于城商行的第一梯队。

我们行非常重视金融科技的发展，在银行家杂志社选举的最佳金融创新奖上连续三年都获得了这个奖项。

不知道现场有没有喜欢跑马拉松的？去年在郑州的国际马拉松比赛，就是我们行冠名的。说这么多是为了什么？不知道现场有没有河南老乡，如果想回河南，可以去郑州银行工作。即使不想去工作，可以看看我们行的理财，利息还是比较高的。

下面正式开始分享，主要提纲是这样的

第一，为什么做持续交付
第二，开展持续交付工作的前提
第三，介绍具体是怎么做的
第四，总结及未来改进方向

一、为什么做持续交付

核心业务系统可以说是所有银行当中最重要的系统，它会为数十个甚至上百个系统提供基础服务，功能非常多，比如各种存款、定期、活期；各种贷款，房贷、车贷等，这些最基础的产品管理功能都是核心业务系统提供的。

另外，它负责内部资金往来和资金清算。平时使用手机银行或者是网银ATM的时候，并看不到这个核心系统，但最终服务都会落到核心系统，所以它的逻辑也是非常复杂的。

我们的核心系统管理的基础贷款产品只有十几款，但它可以组合出上百款面向不同用户的产品。

第三，我们的交易场景也非常复杂，通常接触到的是一些实时的，还有定时的场景。除了这些，核心系统有日间批量，比如有大客户，一次开一万张，批量开卡场景，肯定需要一段时间进行处理。

还有日终场景，互联网企业一般不会接触到。比如五点银行下班不能存钱，但我们都不下班，我们在后面算账，系统一晚上都在做资金清算的工作。

核心系统这么复杂，质量要求肯定很高，一旦算错账，客户不满意，银监不满意，谁都不满意，我们的压力很大，春节银行放假了，我们还是要值班的。

我们日常做运维过程中遇到很多困惑，相信大家都遇到过。

首先，测试可能会抱怨代码质量低，上来就报错，耽误测试时间。

另外，很多人都会遇到一个问题，测试时间太短了，两周一个上线窗口，我们最长的测试时间可能是两周到三周，但我们在做核心项目的时候写了五万条案例，不可能全测完，只能测新功能。

新功能测试不全面的情况下，上线怎么保证不出质量问题呢？这是测试要思考的问题。另外，开发同学会遇到很多问题，上线流程太长了，要各种领导签字，比写代码还麻烦。这都是日常工作中遇到的困惑，我们希望通过 DevOps 解决。

我们发现在已有的工作中，DevOps 的确给我们带来了提升。

质量的提升

我们有接口级别的自动化合规测试，有不定期的性能测试，也有很多人工测试，又新增了单元测试，新增代码覆盖率从 0 提升到 40% 以上，这是非常快速的进步，做过“单测”的人应该都知道。

我们新增了一些代码扫描环节，工具是Sonar，我们采用了商业工具做国际安全标准的扫描。另外，我们还增加了测试频率，做 DevOps 之前只有每天晚上定期进行接口级回归测试，做了 DevOps 之后，每次提测都跑单元测试、接口测试、代码扫描等等，有不同的时机选择，后面会详细介绍。

效率的提升

首先是标准流程自动化。另外，我们可以提前发现问题并快速迭代，原来在没有快速迭代的时候，可能开发今天写的代码，十天后说有问题，十天前写的全忘了。现在当天写的代码，十分钟以后就可以看到问题，该怎么解决？脑海里的思路会非常清晰。

度量反馈

DevOps 标准中非常强调度量反馈，没有度量平台的时候，我们要出一些数据，一会儿去A平台看，一会儿去B平台抓，写总结的时候现测数据非常费时。

通过度量平台的建设，实时指标立刻可以采集，可以及时看到结果，我们还画了一些趋势指标，比如最关注的自动化测试，晚上回归测试会跑一万多条，如果在四个小时内完成，我觉得这个是可以接受的，如果都超过六个小时甚至七个小时，可能会影响白天的工作，上班了还看不到测试的结果，这是需要我们提升的地方，我们就通过各种趋势数据看到需要改进的点。最后，度量平台一定是自动采集的，这样写报告的时候就不用动手去算。

二、开展持续交付工作的前提

招商银行和去哪儿网的资金平台都非常先进，我们城商行科技部目前的规模大概是100多人，研发部门有60多个人，做 DevOps 的大概只有9个人。这么小的团队，怎么能快速做出来？我们想把这个分享一下，希望对大家有帮助。

首先，我们有一些基础。基础是什么？我们的项目管理流程非常规范，分为两类，一类是周期比较长的，还有一类是几天内就可以开发完的。

我们的项目管理规范大概运行了五年以上，每个项目怎么管理？从开发、测试到上线，都有一套通用的流程。还有配置管理整齐划一，所有的代码库都遵循统一的分支策略，代码库的结构都是一样的，环境管理规划清晰。

很多人都会问到环境规划的问题，其实做的好的企业，可能每次测试的时候会选择重新构建一套环境，如果能做到是非常好的，但对于我们来说，目前我们环境组只有两个人，但要管的系统有一百多套，而且我们有AIX服务器，在对容器和虚拟化技术支持不是很好的情况下，我们没办法很快交付从零到有的完整环境，所以我们会规划现有环境。

做 DevOps 之前，我们的自动化测试已经建成规模了，大概有6000-8000条的案例，已经运行很久了，我们的核心系统也已经实现了自动化部署，这都是我们做的基础工作。

最重要的一点，做这些工作的人都是一个团队的，大家平时配合得很好，很有默契。当我们接到一个新目标的时候，也可以很快达成一致并快速推进。

接下来说一下我们做之前的几个关键要素。

第一是标准化，要审查目前工作。比如项目管理、配置管理、环境管理，是否都实现了标准化？项目管理的标准化意味着有流程，环境管理的标准化意味着可以做自动化部署。如果你的配置管理和环境管理没有做到标准化就想做自动化部署，说实话模板管理难度会非常大。然后是测试管理和质量管理，如果没有标准，其实很难做到组织级的持续交付。

第二是一定要因地制宜。如果现在什么都没有，要新造几个流程吗？这个不可取。DevOps 讲究的是跨团队的交付，团队之间可能有天然壁垒存在，要改变你的流程，我认为这个流程更好，强推给你，其实在很多情况下适得其反。具体怎么做要看实际情况，我们的日常工作是如何开展的？能不能根据日常工作总结出一些标准流程，再把它做成自动化？或者看看发布过哪些体系文件，这些体系文件其实就是标准的描述。

第三是要做好标准的梳理工作，要开始制定目标。DevOps 的学习是循序渐进的过程，要先定一个小目标，DevOps 标准的要求非常高，完成小目标的同时，对标准的理解会不断加深，当时我们做的时候，标准一天会看 N 遍，中期目标要定一些有难度的，做完了会非常有成就感。

项目管理中的常见模式，DevOps 算是新生事物，要么自上而下做，要么自下而上做。自上而下好处多，领导支持，如果有自上而下的机会，一定要趁热打铁快速做出来见得到效果。

自下而上做也不是没有办法，要帮助别人解决问题，你想做 DevOps，要为开发、测试、运维解决什么问题？把别人的问题解决了，别人才会配合你。

第四是项目规划。DevOps 强调快速迭代，我们一定要利用敏捷模式快速做起来，我们用了很多开源工具，比如制品库、集成工具、度量工具，都有很多的选择，到底用哪个适合？要快速搭建起来，看看能不能满足最核心的需求，不行就立马换掉。

在初期建设的时候，我们可能有很多事情要做，包括流水线刚刚上线的时候，可能会不稳定，会因为一些异常场景没有考虑到，频繁报红灯，我们规定有红灯不下班，把问题解决完再走，这也是我们持续交付团队给开发、运维等其他团队宣导持续交付精神时自身做的表率。

为什么我们有专门的 DevOps 持续交付项目群？

我们核对标准后发现，标准里的要求，我们可以总结出非常多的提升点，前后大概将近有二百六七十项。这么多的需求，其实成立一个小项目是完全没有问题的。当时在做的过程中涉及开发能力的问题，一开始没有做单元测试，开发肯定要有学习单元测试的过程，开发也有学习过程。

我们选择好流水线的平台，要和十几个系统做对接。自动化测试，不能说做八千条案例就停止，原来写的是回归测试，现在要写新功能测试，把开发版的接口定义好，就可以做自动化。

自动化的部署也是，原来只是简单部署，DevOps 标准要求我们加一些新的功能，比如和CMDB的联动、检查、配置等等，包括源代码扫描的项目，我们做了组织级别的，不仅有我们参评的项目，还有我们行其他的系统，都要达到这个标准，我们把这二百多个需求划分成了五个小组，组织架构就会非常清晰。

说实话，我们这群人全部加起来，可能也有二十多个，天天在一起开会肯定会变成很多小会，我们就分开管理，每个项目间需要交付的地方，单独由敏捷教练进行沟通。每个项目有关联性，所以一定要强调按时保质交付，这样才不会影响整个的进度。

三、郑州银行持续交付实践介绍

工具链

这是工具链的总览，从头到尾给大家介绍一下。

REDMINE 是我们的管理工具，用了五年以上，我们觉得大家可以试用一下，它是开源的，跟我们界面上展示的其他工具都有插件可以用，并且官方网站有很多demo，不仅给你提供工具，会提供管理项目的思路，建议大家看一下。

GitLab是最流行的，没什么可说的。我们本地的开发环境是自己做的IDE，里面有很多插件。我们的流水线，使用的就是目前的主流工具 Jenkins。

右上方是代码质量检查相关工具，Maven是管理代码的工具，我们也用JUnit4、sonarQube。环境部署这块我们采用的是一款商业工具，优势我后续会介绍到，一个是编排步骤清晰，可以利用，另外是数据变更管理这块做的比较好。

下面是自动化测试平台，这两款工具是做 DevOps 之前就存在的，我们只是做了简单的对接。像这个自动化测试工具是接口级别的，最大优势是集成封装度非常高。

上面还有两个黑色的图标，这是我们的度量平台，除了用这款，当时还用其他的工具，后来发现这款工具的扩展性不错，其他的采集数据接口固定，这个我们可以自己定义数据采集生成器，可以和多个数据库做结合对接。

OpenLDAP是统一管理和登陆的工具，这么多工具目前没有做封装和平台，如果用不同的账户和密码登陆其实很痛苦，统一登陆，可以管理用户名、密码、权限。虚线左侧是开发测试区，右侧是准生产和生产区域。为什么准生产和生产区域没有这么多工具？我们认为在开发测试区已经完成了测试，上线产物基本固定，只需要到制品库拿包做部署。

流水线

下图是流水线，目前针对核心项目做了七条流水线。

首先是DEV环境，然后是SIT阶段，最后是UAT阶段。

DEV阶段有两条自动触发的流水线，一个是做编译和单测的，还有一个做静态代码扫描的。

为什么拆开？对很多企业来说，如果你的代码库不太大，或者你是微服务架构，完全可以放在一起。我们这个核心系统非常复杂，全部扫描完大概需要20分钟，开发肯定不愿意提交代码后等20分钟看结果，所以我们也在这里做了拆分，编译和单测每次的提交我们都会做。

什么时候做代码扫描？我们觉得分支测的没有问题，需要向其他环境送测时，会触发代码扫描，我们不会频繁扫描，毕竟扫描一次要20分钟，时间成本非常高。

中间SIT分支做的事情比较常规，编译、单测、部署，还有自动化冒烟测试，选取的是让系统转起来的最基础案例，大概有300多条。环境部署好了，测试没有问题，交给SIT做手工测试。

然后进入UAT阶段，两条绿色的分支都是手工触发的，这个要按需。我们可以向某个分支提交代码触发自动构建，但有时候测试人员并不希望测试过程中进程突然重启，所以我们做了手动触发。我们在UAT阶段部署的环境是多个的，环境规划不止一个，另外我们做自动化测试的时候，除了冒烟测试，还会加新功能的测试。

做完这一切，我们会交付给UAT人员做手工测试，还有三条流水线晚上定时跑，一个是sonar代码扫描，扫描对象不一样，前面扫描的是特性分支，这里扫描的是发布分支。第二个是安全扫描，我们的工具集成了国际上主流的安全规则。第三个是做自动化全量测试，在流水线的步骤里跑的测试案例可能是几百条，但晚上会跑一万五千条。这是UAT流水线的真实示例，流水线比较长。

一上来就是指定构建版本，会存在版本并行情况，可能这个上线窗口版本和下个上线窗口版本同时都在开发，到底要发哪个版本？需要有一个手工输入，后面切换到版本对应的分支上。

日常规划了三类版本号，这次上线版本是1.17.0，我们想记录一共发了多少次版本，所以后面会加“_1”、“_2”等等。因为我们的自动化测试要选取现有环境的脱敏数据进行使用，为了不跟手工测试人员发生冲突，我们有专门的自动化测试环境。自动化测试环境和UAT测试环境都在部署。

后面是接口测试，再后面的紧急发版跳过了，这是做到流水线里的选择。通常会规划好上线时间，但有时候情况紧急，也需要走一个紧急流程。紧急流程跟日常版本有什么不一样？

日常版本半年前就编制好了，但紧急版本是哪个环境空闲就在哪做，不仅要选择版本号，还有环境要进行选择。

还有一个人工确认制品升级。测试环境讲究单一可信赖的源头，上生产的包最终肯定是从测试环境拿出来的最后一次测试完毕没有问题的包。测试环境中每次发现问题，会多次发版，这时候肯定不会把有问题的包传到生产环境，只有确认包没有问题了，不需要再测试了，准备上生产了，我们才会选择制品升级。

如果要拆开做，要拆三条流水线。这个流水线提供给测试人员，我们不想让他有非常专业的持续交付知识，也不希望他记忆这么多流水线都是干什么的，所以把这个融合到一起，通过简单的提示告诉他你想做什么事情，应该怎么做。

另外说一下流水线的注意事项。一个是运行时间不宜过久。刚才也说到为什么把sonar的步骤拆出来？因为时间太久了，等不及，会忽略很多报错，达不到快速反馈快速迭代的效果。另外是做到错误的精准推送，并不是一报错先告诉领导和全体人员，邮件和短信很多，最终的结果是把它们放到回收站里。

我们会做一些分析，大方面来说会划分阶段，比如是编译问题、单元测试问题，会推送给开发。如果是自动化测试问题，会让自动化测试人员先做初步筛选，有问题提缺陷，开发者只需要关注缺陷。再往细说，编译出错推送给哪个开发？我们可以抓到GitLab上谁最后一次提交日志，谁交的发给谁。

配置管理

下面讲一下配置管理的分支策略。网上有很多流行的分支策略，但最核心的是分支策略的寿命都很短。因为我们项目的复杂度原因，我们接到的需求粒度都比较大，所以相对来说特性分支存在的时间比较长。当然我们也可以往下细分，比如分到功能点的分支。目前没有这样做，不能操之过急，可能有一两个人精通GitLab的使用，但对团队人员来说需要有一个转换，当他们熟悉了，可以把分支粒度变得更小。

现在正式介绍一下我们的分支策略。主干对应生产版本，发布分支是上线窗口，招商银行也是这样的，一个月两次上线窗口，不出意外这周四晚上是上线窗口，你的需求哪怕是提前十天或五天开发好的，都放在这等着，等到周四晚上一起上线。再隔一个周的周四晚上又是上线窗口，通常都是一起上线，这是节约资源的表现。每次上线需要开发、运维、网络、技术同事都要留下，如果随时上线意味着他们随时都要加班。

发布分支对应上线窗口，是由多个特性分支，我们行叫子任务分支，由这个汇聚而成，因为它们在同一时间上线。UAT测试人员的测试对象就是发布分支，最后会有集成分支，是一个混合版本。受环境限制，现在开发人员开发的子任务，可能有这周四上线的，有下下周四上线的，还有四个月后要上线的。按正常的版本和环境规划来说，我们应该给每一个上线窗口都准备环境，但资源有限，所以在SIT环境做测试，确保没问题再到UAT环境，这个跟版本是严格对应的。

接下来说一下配制管理之使用工具。主要想给大家分享几个细节的点，GitLab的功能很多，怎么用？介绍四个点。

合并请求，最下层的特性分支在合并窗口分支的时候，我们有一个审批的过程，利用合并请求特性来做。我们最早也想引入 gerrit 平台，后来发现技术方案复杂，也没有很好的汉化版本。

GitLab提供的一些脚本可以帮我们进行检查，比如提交时做是否规范的检查，检查子任务是否合并到了正式的窗口，明明应该合到本周四的窗口，就不要合到两个月之后的窗口。这个开发任务只给A来做，如果B在这个分支上提交，我们会做拦截。

GitLab可以和Jenkins对接，在GitLab上可以看到特性分支提交后触发的流水线情况，如果你的流水线不是通过状态，不允许你合并。

子任务编号可以链到项目管理平台看子任务的具体内容，在项目管理平台也可以看到需求究竟改了哪些代码，这都是我们做的一些对接。我们本地还会用IDE。

另外我们自动生成注释，通常要求大家首先写一下你改的是哪个需求，需求内容是什么，直接做成自动的，开发同事都比较喜欢。这个不写不规范，写了有点麻烦。

环境管理

我们的环境常规用的有集成测试环境，就是刚刚说的，不管你什么时候上线分支，都可以放到同一条SIT环境上，保证基本功能没问题。

但这里面测过的东西肯定不能上线，在这个环境里针对A需求测五个文件，这五个文件可能已经合并了，可能是其他功能冲突的问题，真正要上线的是把其他需求对这个需求冲突造成的影响拆掉，所以经过SIT环境后，会进入正式的UAT环境，进行最终上线版本的验证。窗口版本目前有两个，留给测试人员的时间大概是一个月。

我们还有长周期跑批环境，房贷可能会贷二十年三十年，如果按照一天一天去跑，最快也要跑十个小时，这样跑非常耗时。如果从一月直接跳到五月，会造成大量测试数据中间该计算的步骤跳过，导致很多测试数据不可用，所以我们专门准备了长周期跑批环境，不会过多使用生产脱敏数据，允许跳跑，使用的测试数据自己做，随便跑。

我们还会有一些专项测试环境，经常存在的像性能环境和自动化环境。比如有一些需求，要配合人行和银监验收，但不到上线窗口，进不到上线窗口的版本，会临时搭建环境。

上图展示的是自动化部署工具。我们部署的时候需要注意几个问题，一个是版本，部署在哪个环境里，部署的步骤是什么？步骤一定要是可选的剧本，比如有一些热发布，不需要重启进程，如果固化会浪费时间。有一些SQL也要进行规划。

很重要的一点是数据变更，应用可以全量发布，无限次部署，SQL有一定的编写规范，怎么区分让它不重复执行？比如第一次写了三条SQL放在文件里，执行报错了，我们再写一个文件，只有报错的SQL，把它改正确，保证SQL每次执行不冲突，都不是重复的。我们的SQL有状态，如果已经执行过，一定不能再次执行，不然肯定会失败。另外是SQL跟大的软件版本也是有关联关系的，比如1.17.0，执行的SQL就这么多。1.18.0执行的SQL又是另外一批，要考虑这个问题。

还有一点是SQL的执行顺序。上线的时候很少上单个应用，可能会上五个甚至十个需求，有些需求先上A需求、B需求，才能成功执行。我们通过SQL命名解决。

自动化测试

这个图是分层测试模型，我们倡导单元测试尽可能要多，接口测试是第二，界面测试是第三，人工测试最后。因为人工的成本非常高，但人工测试是更真实的。

具体看一下测试分层策略。首先说单元测试，启动非常难，但不得不做，因为好处非常明显。做了单元测试，可以明显看到代码质量的提高，而且在做单元测试的过程中，对你自己写的函数逻辑可以进行重新审查，你会发现很多之前没有考虑到的异常场景，可以把它补充进去。

做单元测试，刚开始的推行有一点困难，这时候一定不要强加硬性指标。像我们的核心项目，可能刚开始的时候已经有70万行的代码了，但一个单元测试没写。如果让大家去补单元测试，相信单元测试就做不起来了。我们不说旧的，就说新的，新增代码的单元测试覆盖率一定要上去。

定了这个规则之后会发现，刚开始的单元测试是2%，很快就可以上升。想说一下单元测试的成功率，因为是最底层的，所以我们一定要规定成功率百分之百，不成功不允许往下走。

接口测试可以看一下上图的案例。我们之前做的一些自动化框架和很多的开源脚本是需要我们写代码的，现在的测试平台封装程度比较高，我们可以看到一些简单的尾码，懂一些简单的逻辑就可以写测试案例。

这是我们的测试结构，把接口做了封装。我们认为一个组件是由最基础的接口加上报文头再加上默认数据组成的。我们有一个案例，多个组件加上实际案例需要的数据，再加上对结果的断言组成的。

举个例子，去银行转账，如果你没有卡，首先做的事情肯定是把基础资料提交上去，银行的人给你开卡，你才能做转账。这个过程中，我们会把开卡做成最基础组件。不管是转账、现金存款、贷款，都需要调用这两个基础步骤，通过这种方式提高案例的复用程度。

很多人刚做自动化的时候都说，自动化肯定能代替功能测试，一上自动化赶快把功能测试的人砍掉，不是这样的，自动化测试的问题是代码实现的问题。如果代码少实现一个功能，靠自动化实现不了，所以人工测试不可或缺，最好由一线业务人员参与。因为他每天使用这个功能，只有他才能提出最正确的意见。

上边是我们的测试报告，可以看到最终UAT测试报告的出具人和执行人，都是我们业务部门的同事。

另外想说一下非功能测试。一般是性能测试、运维专项、安全专项的测试，这里重点说一下性能测试，我们之前做过，大概需要一周时间，因为场景比较多，有单交易、混合场景、热点账户等等。

后面做了一些裁减，两周上线一次，每次上线前三天左右，系统有稳定状态的版本代码，只做混合场景的测试，大概半小时内可以完成，检查系统有没有运维的变更引发比较大的问题。我们还要定期做一些深入测试，为什么？其实我们的交易模型会变，可能这段时间银行出了一个比较热门的理财活动，买理财的交易就成了我们的高频交易。再过一段时间，可能会出很优惠的贷款政策，贷款交易就又成为热门交易，所以一定要随着时间的推移定期更新每次测试的交易模型。

下边列的是选取交易的准则。

首先选取的测试交易都是在高峰交易时段的交易占比超过整个联机交易约90%的交易量。有些交易的量很少，我们不测，因为精力有限。像我们现在的交易，核心接口一共有500多个，但真正通过这种方法筛选出来的高频接口，其实只有二三十个。我们会根据开发和业务的建议，选择一些他们认为比较重要的交易。

比如中间的交易模型有一个热点账户模型，这个热点账户就是银行比较特殊的场景，可能是多人往同一账户在指定一段时间不停转账，这时候会引起数据库锁表等一系列问题，这是我们业务人员提出的场景，要针对这个进行重点测试。按照高频交易筛选的原则，我们筛不到这个交易。

度量反馈

度量反馈是整个持续交付过程中比较重要的环节，怎么选择度量指标？下图是指标的定义，做一个指标并不是要什么就有，做指标一定要想清楚，比如这个指标你想看什么问题，它属于什么领域，我们的是实时统计、一天统计一次还是一小时统计一次？统计的频度不一样，会影响准确性。

另外是指标样式，是展示当前的数据，还是想要一个趋势？比如刚刚举的例子自动化测试时间，光看今天或明天运行了多久没意义，要看变化，希望整体呈下降趋势。

怎么选取指标？要说一下之前走过的弯路。最开始我们根据网上的经验，别人都关注指标，我们搞了一个大杂烩，五十多个指标，做出来之后发现没有人愿意看，所以后面我们就变了，去看日常工作中大家都关注什么。

比如像银行，可能有很多的外包人员，我们可能会关注外包人员工作的时间、提交代码的行数，把它做成指标。每个季度甚至每年都要写总结，总结汇报的指标肯定也是关注内容。有了指标也要形成有效反馈，如果只是在平台上看一眼，很快会把它忘掉，尤其是对于趋势指标，要设立容忍值，一旦超越这个容忍值，立刻就会在项目管理系统里形成跟踪事项，等级跟日常开发任务的等级一样，不用害怕解决不了，它不会消亡，只有这样才能达到有效改正。

这是我们指标的示例，每个人提交了多少代码，提交了多少行数，一个是可以看到工作量，第二个是可以看到提交的行数，如果一次提交很多行代码也是一个异常，应该找他谈谈话了。

四、总结及改进

很荣幸，之前很多人可能都没有听说过郑州银行，但我相信现在大家都知道了，因为我们是全球首家过评的城商行，大概从2018年5月份开始，历时一年把核心项目上线后，逐步开始自动化测试和自动化部署，三个月的时间做工具链的调研选型，12月正式开始一直到3月，整个都是在打造标准的过程中，时间还是比较短的，中小型企业如果有意愿，我们可以交流一下如何实现这个目标。

我们做持续交付，肯定是希望提升价值流转、研发速率，所以我们非常重视研发团队的反馈，我们的需求就来自于研发团队的反馈。通过做持续交付，在认证过程中得到了一些提升。

一是配置管理的转型，把配置管理工具从SVN切换到GitLab，可以提供丰富功能，界面更友好，建议大家有条件的都试用一下；
二是建了7条标准流水线作业，加快持续集成持续部署的速率；
三是建立了完整的测试分层策略，单元测试覆盖率从无到有，从0到44%，核心的500多个接口都覆盖了，现在上线很放心；
四是自动化部署，原来都做过，这次核对标准发现需要有改进的地方，我们和配置中心做了联动，每次部署前都检查配置项的正确性，另外会检查SQL的危险操作；
五是打通上线流程，原来每次上线要找很多领导签字，现在自动创建上线单，只要点通过，等领导审批就可以了；
六是度量指标，五十多个指标经过筛选分类裁剪，形成了6个领域，一共31项指标，督促我们的工作更好进行改进，也给我们提供了决策依据。

这是我们未来的改进方向。

首先，深入敏捷开发。就像刚刚提到的，分支目前存活的时间比较长，因为需求粒度比较大。目前正在做功能点的拆分，把它拆成更小更合适的，需要是完整可交付的需求，才能做到提升价值交付速率的目的。
第二，流水线触发上线流程。上线流程虽然做了线上化，但目前需要人工确认过程，下一步会把上线流程和流水线进行对接，做到自动抓取数据、自动审批。
第三，容器的推广和应用。
第四，环境的智能运维。

如果想要容器，网络、服务自发现、统一日志监控等等，都是需要考虑的问题，所以上容器不是一件简单的事，一定要想好再上。但我们一定要上容器，因为我们想快速交付可用的环境，除了容器我们觉得没有更好的选择。