行业案例

black;珍爱网;基于微服务的DevOps落地指南

扫一扫分享此案例

2015-2016年，珍爱线下门店已新增覆盖城市9个，与此同时，CRM系统大小故障却发生了数十起... ...

珍爱网是以“网络征选+人工红娘”模式提供婚配服务的婚恋相亲平台。CRM系统承载了整个珍爱网会员的全生命周期管理，涵盖资源挖掘、用户触达渠道以及服务跟进体系。

CRM系统对珍爱5400名红娘来说，是承载她们全部工作的核心平台；对公司业务来说，承载着引流、转化、支付、客户服务等全部环节。最最重要的是，公司收入的80%都是依托CRM系统完成的。

然而在珍爱网成立10年之际，运行10年之久的CRM系统已不足以支撑业务的快速发展了。

##  !!#2f58b8 Part 1 我们为什么要做DevOps!!

经过分析，我们发现CRM系统目前面临着以下问题：

__技术上——__

- 传统的系统架构，不再适应敏捷开发，模块耦合，数据库存在单点故障；

- 容错性差，冗余代码多，修复bug和实现新功能变得困难和耗时。

__产品上——__

- 产品功能不够场景化、电子化、智能化；

- 无法快速响应业务变化，迭代周期长。

我们可是背负着“成就天下姻缘”使命呢，系统重构，研发流程改进，迫在眉睫。
2017年1月25日，捷豹项目组成立，只为给业务打造一个“简单·好用”专注于婚恋相亲的综合服务平台。
捷豹CRM系统（PC端、Pad端、小程序端）的版本发布周期为一周一个常规迭代，紧急版本按天发布。
捷豹CRM系统整体设计思路如下图，我们希望能够实现系统的服务解耦、动静分离以及高可用。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522500_86.png)

然而大家都知道，微服务架构中每个服务都具有业务属性，并且能独立地被开发、测试、构建、部署。换句话说，每个服务都是一个可交付的“系统”。

那么问题来了， __!!#e69138 如何让需求以小批量形式在团队的各个角色间顺畅流动，并以较短的周期完成小粒度的持续发布呢？!!__

答案当然是 !!!#f9cb9c TAPD DevOps流水线!!! ，简直是神助攻！

##  !!#2f58b8 Part 2 整体效果!!

TAPD DevOps流水线支持集成主流的研发工具，覆盖产品研发全生命周期，提供可视化交付流水线，可以将DevOps各个环节进行统一展示和管理，真正实现一站式持续交付。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522520_41.png)

自2017年10月起，我们就应用TAPD的DevOps流水线，开展了一系列持续交付和持续改进实践。

__!18 1.持续交付部分!__

CI和CD实现过程使用Gitlab、Jenkins、Sonar、Jacoco、Nexus、EasyOps、Docker、Kubernetes等工具，分别在代码管理、集成编译、包管理、自动化测试、发布阶段集成到TAPD流水线统一展示和管理。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522539_31.png)

__!182.持续改进部分!__

在TAPD流水线实践DevOps的过程中，我们也打通了各环节的研发数据。

通过TAPD迭代详情中的Dashboard，可以统计并展示当前迭代的研发效能数据，包括： !!#e69138 __需求完成情况、缺陷新增和解决情况、代码提交与关联趋势、每日构建统计、构建产物版本情况、自动化测试、部署发布__!!  等全过程数据，研发效能度量更直观、更深入，让改进方向更明确，也让效能提升更明显。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522558_41.png)

__!18 3.改进效果!__

基于以上持续交付和持续改进实践，我们的研发效能也有了质的提升。

我们从业务响应周期、持续交付能力、开发质量、交付质量四个方面来衡量研发效能，下图展示了各个维度的改进效果。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522572_79.gif)

##  !!#2f58b8 Part 3 我们的DevOps是如何落地的!!

那么我们具体怎样利用TAPD DevOps流水线，一步步实现持续交付，最终提升研发效能的呢？

下面我将分享我们在各个环节的做法。

###1.代码管理环节

__!16 1.1 建立TAPD分支管理规范!__

__!!!#f9cb9c 改造前：!!!__

开发编码过程中最崩溃的应该是：“我刚写好的代码又被谁覆盖了！”

并行开发过程中，最痛苦的莫过于开发的需求太多， 记不清哪个需求在哪个分支上，或者多个需求在一个分支上开发，撤代码撤到望眼欲穿……

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522608_90.png)

__!!!#f9cb9c 改造后：!!!__ 
通过走访调研，最终我们确定遵循 __!!#e69138 “一个需求一个开发分支”!!__ 的原则，方便管理且可追溯，并行开发，互不干扰。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522629_80.png)

在Jenkins上创建Job，通过TAPD和Git的API，将TAPD需求ID与Git分支关联，创建的分支名为 __“工程名-创建日期-TAPD需求ID”__ ，开发小哥哥去Gitlab上拉创建好的需求分支便可努力搬砖了。

待需求上线后转关闭状态的21天，自动将该分支删除， __整个分支管理过程实现自动化。__

__!!!#f9cb9c 效果：!!!__

截至目前， 通过该Job创建分支次数达到 __1564次__ ，创建成功的分支数 __远大于1564*3 个__ ，而合并冲突数 __小于5次__ 。

__!16 1.2 TAPD源码关联!__

__!!!#f9cb9c 改造前：!!!__

在测试过程中， 最繁杂的应该是代码合并环节了，一个需求涉及到多个工程的代码变更，每天各个开发针对不同的需求，提测到测试同学进行代码合并。

开发/测试的比例为4:1，需求涉及的前后端工程40余个，面对一个需求到底要合并哪些工程，测试同学每天要在风中凌乱好几回……

__!!!#f9cb9c 改造后：!!!__

与研发效能度量深度结合，良好编码习惯，从源码关联开始。

通过源码关联功能，我们实现了以下闭环：

所有研发任务都必须录入TAPD，并且只能通过需求ID来创建Git分支 → Commit信息必须关联源码提交 → 度量数据只获取关联源码的代码行 → 根据这部分数据进行研发效率和质量的度量。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522649_57.png)

测试同学只用关注该需求的Gitlab提交记录即可知道本次变更涉及的工程有哪些，不用和开发一个个确认，减少沟通成本。

由于提交比较频繁，我们写了一个爬虫脚本，将抓到的版本库去重，得到该需求要合并的工程。然后我们将待合并工程，生成TAPD的合并任务分发给指定同学，将整个过程 __自动化管理。__

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522670_72.png)

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522681_31.png)

__!!!#f9cb9c 效果：!!!__

综上，通过“源码管理”和“TAPD分支规范”，有效规避了代码管理过程中，冲突多、管理乱、不可追溯的问题，同时也实现按需求粒度、灵活发布的效果。

自2018年10月以来，通过这套代码合并任务自动分发方案，我们成功迭代上线了 __18个常规版本和10个紧急版本__ ，整个过程简单清晰， __单任务合并整合环节，从原来的40分钟，减少到5分钟。__

###2.代码质量分析

__!!!#f9cb9c 改造前：!!!__

Sonar其实很早就开始在项目过程中使用了，但是效果并不太好。无论对于开发还是测试同学，都需要多维护一个系统，并且改动频繁，!!#e69138 __当某一个服务经手的开发过多时， Sonar扫描出问题后无法快速分配责任开发。__!! 
另外Sonar配置到集成环境构建时触发， __!!#e69138 让bug从发现环节开始滞后，修复过程也对版本稳定性带来风险。!!__

__!!!#f9cb9c 改造后：!!!__

在2018年底，我们发现TAPD流水线集成Sonar，还可以一键创建缺陷到TAPD。

于是，我们将Sonar扫描前置到开发每一次提交到Git仓库便触发构建，让Sonar缺陷在开发自测环节暴露出来，同时，每一次构建能清晰展示本次代码的变更人，开发可以安心地收下这一页的bug啦。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522704_39.png)

当然，有的开发小哥哥可能没有及时修复，没关系， 测试小姐姐将未及时关闭的Sonar缺陷通过 __“批量导入缺陷功能”__ 每天自动化（通过TAPD的API实现）创建到你的缺陷清单里，开发小哥哥再也不会错过那些被遗忘的bug啦。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522749_99.png)

噢，贴心的TAPD还在缺陷详情里把bug的文件名和代码行都给展示了呢，开发小哥哥和测试小姐姐终于可以不跨系统维护Sonar了。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522782_60.png)

###3.集成编译环节

需求分支经过静态扫描和自测通过后就要提交到集成环境啦。

在这个环节，除了常规编译步骤，我们还增加了__!!#e69138 开发的单元测试和Jacoco覆盖率检测!!__  。在集成环境我们也增加了Sonar进行最后一次扫描确认。

单元测试框架为JUnit，与TAPD进行关联，构建后在“自动化测试”板块可以看到本次构建的单元测试用例总数和通过率（单元测试通过率是我们对研发质量度量的一个很重要的指标），单元测试不通过的case和Sonar扫描的bug处理方式一致，由API脚本统一录入TAPD缺陷进行跟踪。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522796_43.png)

单元测试的覆盖率情况，方便开发同学分析单元测试用例对测试对象的分支覆盖情况。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522808_74.png)

编译后就是Sonar进行最后一道集成环境的全量代码扫描工作了。

###4 包管理环节

我们在包管理环节的实践主要分为对 “jar包”和“Docker镜像”的管理。

构建生成的jar包，推送到Maven仓库（用于其他项目的依赖引用）。将Nexus集成到TAPD，通过“构建产物”可以看到软件包的详细信息。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522893_9.png)

同时，流水线可以清晰看到构建步骤的耗时分布，也帮助我们有针对性地去优化构建效率。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522902_91.png)

然后进行Docker镜像打包，推送到Docker仓库，生成配置，并推送到配置仓库。

顺便说说为什么要用Docker吧！

项目初期只有一个dev环境，随着版本构建的频繁，稳定的测试环境对测试同学来说尤为关键，但是部署一套40余工程的环境对运维同学来说工作量也非常之大，于是我们引入了容器技术。在环境搭建、应用迁移方面都有很好的收获。

同时，基于珍爱的业务背景，特别是对于特殊节日搞活动时候，容器化能快速对服务进行横向扩容；减少对环境的依赖，部署快、扩容快。同时容器运行时会对服务运行环境进行隔离，也有效提升了安全性和服务运行的稳定性。

###5.自动化测试环节

自动化测试分为接口测试和UI自动化测试两个部分。

__!!#e69138 接口测试!!__ 主要通过开源工具实现，但涉及到跨系统维护，以及测试结果不能很好地跟踪，因此在TAPD上尝试用Python Unit Test做些核心场景的接口测试，以便于将这部分测试纳入到整个研发流水线当中，  __!!#e69138 构建成功后自动触发场景接口测试，失败的用例也能直接在TAPD跟踪。!!__

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522919_36.png)

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522944_80.png)

UI自动化，则是我们自己研发的平台，通过关键字驱动实现，并增加了代码覆盖率检测，以帮助测试人员分析哪些分支情况是没覆盖到的。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522959_35.png)

测试结果转为XML格式后也可以统一集成到TAPD管理，可以清晰直观地展示自动化测试结果。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522978_11.png)

目前我们的自动化用例覆盖业务流程达 __!!#e69138 239个，case成功率94%!!__  ，运行时长15min，代码覆盖率21%。

###6.部署发布环节

我们整个发布流程简单分为以下几个步骤，部署发布环节主要用主流部署工具完成。

![图片描述](/tfl/pictures/201907/tapd_20106291_1563522995_52.png)

##  !!#2f58b8 Part 4 研发效能度量!!

每月通过TAPD产生的过程数据进行研发过程效率和质量分析。同时我们也设立了相关奖项激励大家正向PK，提升效率的同时更加重视研发质量。