从无到有：京东持续集成实践分享

讲师 | 潘晓明
编辑 | 黄晓轩前端

讲师简介

潘晓明
目前就任于京东商城平台产品研发部，主要从事测试开发一职，擅长测试工具的设计与开发。前后就任于惠普，腾讯，在测试领域奋斗了 10 多年，对黑盒测试，白盒测试，性能测试，专项测试有必定的了解。《移动 App 测试实战》做者之一。京东移动 app 持续集成项目负责人，主要负责持续集成项目的总体架构设计和维护的工做。

前言

---

我今天主要分享三个主题，首先是京东在持续集成的历程，是怎么从无到有的。其次是京东现有持续集成设计的架构以及提供的服务能解决哪些痛点。最后是咱们在使用持续集成之后，给京东APP测试流程带来的收益。正则表达式

1、持续集成在京东的发展历程

---

这是我刚进京东的时候，京东开发的流程，你们看到这是一个典型的瀑布流程，开发和测试正好是一个对接的关系，全部的测试是在开发这块的下游。测试必须等待开发工做所有完成后才能开始测试工做。数据库

这样会产生的问题是：测试团队各自为战。微信

你们知道咱们测试都是有本身的测试团队，每一个测试团队都会有本身的测试模块，测试模块就对应不一样的开发，形成的问题就是每一个测试团队都是各自为战的。每一个模块都由开发打包提测。这种状况下就带来了一些效率的问题：网络

• 测试干等，没法工做。之前咱们的测试包都是等开发打，开发这边若是说工做很忙，或者说本地代码出问题了，测试就只能等着。架构

• 新bug，追溯源困难。测试过程当中发现一些BUG，但今天一天开发给你许多提测包，开发说这个BUG何时引起的，上午测试的时候有没有发现。那你只能根据你本身本地文件时间排序，大概找一下上午第几个包出问题，这个包引起的代码变动，包括一些东西你都不知道，你彻底就是一个黑盒的状态去开发那边拿包。并发

• 测试本身本地打包测试，熟悉成本过高。有的测试人员等不及了，我本身本地拉代码编译打包吧。确定也有这样的测试，这种测试可能会插入一些本身须要的代码的测试插桩的东西，包括作一些埋点的东西。这样作测试的话，对测试要求比较高。特别是安卓和IOS的环境，IOS涉及到一些证书及配置的管理。测试同窗若是对这块不是特别了解的话，会常常形成编译失败，编译失败的错误日志还看不懂，得找开发问这个错误是什么缘由致使的，是否是某个编译的环境或者某一条编译的设置是须要改的。app

• 模块1测试完了，模块2还没提测。咱们某个测试团队已经完成测试了，但还有测试团队的包还没拿到，尚未测完，就会形成集成项目的delay。整个项目的集成就被另一个模块拖住了。

诸如此类还有不少的问题，都是由于分散测试管理模式致使的问题。负载均衡

那咱们期待怎样的改变：运维

咱们期待可以经过持续集成统一出平常提测包，这样就不须要找开发进行对接了。咱们须要有一个统一的持续集成平台来拿到提测包。同时咱们可以经过持续集成追溯哪一个包或哪一个构建的时候出的问题。咱们也但愿有特殊的插桩测试包可以经过持续集成帮咱们作到，而不须要咱们本身每一个人打本身特定的包，最后还有更多需求的介入。

之前的流程走不下去了，咱们要作持续集成的团队，我了解的这个团队有的公司是运维作，有的公司是开发作，有的公司是测试作，具体哪个团队作其实没有关系，关键的点是可以把持续集成这块流程和这个部署的东西知足现有公司的须要。

2、京东持续集成服务设计及解决的痛点

---

刚开始作持续集成初版的时候，就暴露了一些问题：

• 持续集成环境没有备份容灾。咱们持续集成服务是单点的，这是一个内部的系统，给内部用的，首先没有大量的流量，也没有大量的并发访问，根本不用考虑性能方面的问题，知足平常的构建就能够了。

• 没有统一的入口。一开始是直接使用到Jenkins，Jenkins咱们针对不一样项目部署不一样Jenkins的服务，大大小小各类项目进来之后，不一样的服务是不可能让公司内的员工本身去登到服务上作触发，这样不现实。这个服务太多，并且暴露给用户也不太现实。

• 手动部署环境。当有新项目进来或者新的东西要作发布，靠手工去堆这样的构建，效率也比较低。

• 缺少有效的配置管理。配置管理一开始作的时候没有想到这么多，配置管理这块是有所忽视的。

• 未关联测试工做。一开始持续集成的目的只是为了出包给你们作测试。给你们作测试可能没有关联到后续测试的东西。

  • 没法知足敏捷项目的需求。如今各个公司都在推敏捷，敏捷怎么作，持续集成怎么跟上敏捷的步伐。

这是安卓app构建的架构图，就是简单的四层架构的结构。前端用户进到咱们的平台（简单的Nginx+PHP搭建的平台），中间是咱们持续集成微服务的中间件，底层是Jenkins给全部项目的服务，持久层使用到了MySQL的DB+京东云上的云服务。全部的构建包都是上传到京东云。这个图能够关注的重点，全部服务、全部机器都是作的双备份，就是多机的备份，作到这样容灾和负载均衡的工做。

这是持续集成中间微服务的架构。主要是服务网关进来的，是按照功能模块作服务划分的，涉及到Jenkins的基础服务，Job服务。这个涉及到Jenkins基础服务，咱们的节点管理就会经过使用一些基础服务作咱们本身节点的调度管理工做。

这样我就解决了前面说的第一个问题，备份容灾的问题。不管是从平台、微服务、Jenkins容器和数据库，全部都是作了双机、多机的备份。

同时这边的Jenkins容器服务，甚至还设计了跨机房的服务。这样保证在极端的状况下即便是一个机房出问题了，机器全挂了，另一个机房能够保证还能使用。

这样就知足了7*24不间断提供服务，还能作到负载均衡，知足极端的状况下服务的可用性。你们不要忽视公司内部的服务单点的问题，好像以为内部服务这个没什么人用，不太会坏，必定要考虑到它是须要有备份的，全部机器你想不到就是会莫名其妙出问题。

关于统一平台，咱们说咱们须要怎样的平台。刚刚提到这么多Jenkins服务，咱们是否是须要一个统一的平台，把全部项目统一块儿来。让用户可以直观的以黑盒的方式去使用。

这个是持续集成平台的手动构建的界面，左边的菜单是现有加入到持续集成的项目，好比说京东商城、金融、京东冰箱。

右边是每一个项目具体的构建类型，你们能够选IOS构建也能够选安卓构建，每一种构建都有相应分支给你选择，还有相应的构建类型。这里点击开始构建，你们就能够等待构建完成之后，到构建历史里面拿包。

这就是构建历史的界面，能够拿到历史上的和你上一次构建完的测试包。这里有包名、上传的时间，包的大小，是在哪个分支、哪个用户触发的，这些信息均可以看到。

咱们作这个东西是有时间的搜索，你们能够经过历史的时间搜索过去某一个时间的包。咱们作到全部的历史都是可追溯的

这是系统构建的统计页面。这个主要是用来作每日构建或者每个月构建数据的统计。这些数据能够告诉咱们哪些项目，哪些平台构建的数量是怎么样的，它之后是否要扩容或者缩容提供强大的数据保障。

这是配置管理页面，主要是作前端的Job和后台Jenkins Job作映射，同时提供了平台的配置、用户管理。提到用户管理这里全部的平台，在每一个用户进来的时候均可以配置一套权限，当你被赋于一种权限的时候，例如仅赋予你安卓权限，你是不能打IOS包的；你是构建打Release包，你不能打Debug包。主要是在这里作权限管理。

这样咱们平台的问题也解决了。咱们平台主要是三个大方面：

• 统一性。集中全部的项目和使用，把全部的东西集中起来。

• 可用性。经过前端的注册，包括使用以及操做的话，对用户来讲是彻底黑盒和简易的。全部的用户不须要去直接触发后台Jenkins服务，那些很是复杂的东西已经都帮他封装好了。

• 信息化。全部信息均可以直接展现，包括构建的数据，每月的构建数量，这样咱们整套构建数据能够作到闭环。

接下来我讲一下节点管理。Jenkins自带节点管理，其作的也很是好。他的master /slave机制容许你能够对Job作并发构建。京东这一块主要是作混合的节点管理，有用到master/slave，也有用到咱们本身的一套东西。咱们这边的节点主要是Docker加Jenkins的环境。

使用Docker的好处是每一台容器能够作备份，Docker image能够作环境的快速部署，就是说IOS或者说安卓底层的构建须要依赖的构建的东西，包括安卓SDK的构建环境，这些东西都是通用的，能够经过Docker image快速的生成，方便新项目的接入，若是有新的项目，能够直接帮他生成一个新的节点，这个底层环境就能够直接用了。

同时这么一个Docker化的节点管理，就能够支持一个并发的构建。并发的构建前提是有持续集成的微服务，微服务能够经过前端调度每台节点的使用状况，作一个动态的负载均衡。

最终Docker这块的部署，包括Docker这块的管理，对运维同事来讲，这块的管理就能够作到很是统一的管理，不像线下的机器你们手动管理，全部的均可以经过系统或者平台统一管理这样Docker的信息。

节点的监控，也是节点管理的一部分。节点监控咱们是保持在分钟级别的，可以在第一时间发现若是某一个节点出现问题，会有第一时间的微信告警，责任人收到这个告警之后，咱们就会修复出问题的节点，保证全部的服务是可用的。第一时间解决问题，不能让掉线的节点或者出问题的节点一直在那边不知道。

配置化管理是比较重要的，我认为是持续集成核心的东西。咱们环境配置化能够经过Docker实现，咱们Job的配置化，一些Job参数化的东西，以及各类插件、各类本地编写的脚本，这些东西所有能够经过版本管理工具作这样的配置。

这样作有什么好处呢？若是咱们全部的东西实现了全配置化，咱们的配置化管理可使咱们的部署彻底的自动化。咱们说一个配置，或者一个Job，若是说出现了更新，你们在Jenkins服务上有更新，或者须要更新某些东西，使后面的构建不稳定致使的问题，怎么办？回滚就能够了。

咱们全部东西都是有配置管理的，一样咱们不一样的Job能够拉不一样的分支，作不一样策略的管理。

这样每一次构建的项目咱们能够经过不一样配置化的管理，应用到对应不一样的分支上面的配置信息，这样就能够作一个很是灵活的按照配置管理部署，就作到很是简便。

第一能自动化，第二能作到很是灵活，全部手动信息就不须要你手动输了，并且你手动输入以前的信息根本没办法记录，这是配置化管理带来最大的好处。

图片
全平台的支持。咱们这边是IOS和安卓两个平台的构建，须要依赖的一些环境支持。咱们编译的类型也是支持Debug和Release的包，也包括发布包、企业包、预发布包。

参数化的构建。咱们每个Job的构建，是尽可能用到参数化，参数化最大的好处是能够作到Job的复用。你们在新建Job的时候大部分的配置是同样的，在大部分配置同样的状况下，若是在一个Jenkins list里面有成百上千个Job，这些Job是否是能够作这个参数化的合并。大部分的Job是否是能够经过参数化合并在一块儿。

合并的好处有不少，一个是快速能够接入项目；还有一个是灵活的配置，按需产出。例如在构建完一个包之后，上传到京东云的时候，京东云的节点是能够选择不是上传到固定的点，而是上传到另一个点，这个节点的信息就能够动态的来修改。

一样，咱们gradle编译的信息，在项目过程当中开发须要调试，调试时我须要在2.14版本上编译一次，在2.2版本上编译一次，你不能在环境变量中固定死，这就能够直接经过参数化的方式实现就好了。这样就能够实现一个按需的产出。

还有一个好处是节省磁盘空间。一个Job最大的占空间的点就是workspace。如今虽说跟十年前比起来，磁盘每兆的价钱单量已经不值钱了，但若是在有限的空间里面，咱们可以节省这样空间的话，为何不去作呢。

并且这么多的Job累积的代码量对实际最终构建的结果，或者说总结的数量，其实占用空间仍是很是大的。

这是构建状态实时获取。咱们用户刚刚在平台上手动触发了构建，这个构建不是一下子就好的，这个时候有一个构建状态告诉你，你的构建已经开始了。

而后你们能够等待构建完成，会有一个状态记录告诉你构建成功了，至关于一个通知的功能，你能够知道你刚刚的构建是成功仍是失败，失败的缘由是什么，构建时间多长，这些信息都是一目了然的。

而后是构建的历史，刚刚讲到能够到构建历史里面拿测试的包。这些构建历史信息最大的好处是追溯过去发生BUG的信息。若是每次都是从开发那边拿包的话，这块的历史包括这块的构建记录不清楚，经过构建历史能够作到BUG的追溯，包括作数据的分析。

这是构建版本的差别信息，我认为这是很是重要。某一个构建或者每一次构建当中，引入一个新的BUG，就能够经过这个信息追溯，这个BUG是什么缘由致使的。上一次在拿到这个包的时候没有出现这个BUG，此次拿到这个包出BUG了。

咱们经过提交记录和changelog信息，就能够知道开发在何时，在哪个类上作了哪些改动，这些信息就一目了然，经过这些信息这个BUG的定位和追溯就简单了不少。

这是一个构建日志的获取，构建日志的获取这是Jenkins自己自带的，咱们把这个信息就无缝地结合到咱们平台上。这个好处是，咱们能够经过构建信息判断本次构建失败的缘由是什么，或者说构建成功还好，主要是构建失败。

构建失败的话，失败的缘由是什么，为何会失败，咱们能够经过这些信息追溯这些构建失败的缘由，同时能够验证一些相关参数的使用，是否是正确的。

这个就是数据的统计。数据统计基本上是围绕着平台各个项目和模块按时间的纬度，它构建的数据。这个构建数据包括它的成功率，这些数据对咱们开发有着鞭策做用，它的成功率低的话是什么缘由致使的，为何会常常出现编译失败的状况。

若是成功率不是由于编译的问题，是咱们本身自己的缘由，是否咱们能够回去找一下，或者自己定位一下咱们这边构建长期不稳定的缘由是什么。其次也是做为后续CI这块是否须要扩容，咱们能够根据这个数据作依据。

有些项目一年下来或者一个月下来，构建次数很低，有些很高。这些数据能够做为咱们参考的依据。

新需求的接入到咱们这个持续集成的系统，怎么方便的接入新需求。咱们持续集成的服务和平台是针对整个大部门的，必定会有其余的部门同事找你，问一下能不能接入咱们持续集成平台。

接入新需求，要么是新项目，要么就是新的工程，在已有的工程下接入新的子工程，要么是在已有的基础上须要增长他的节点。

全部的信息咱们只要知道每个项目须要依赖的东西，经过咱们前面的配置化管理和Docker管理，咱们能够很是快速的帮他生成一个Jenkins服务，而不须要手动或者人工的核实、排查或者手工创建这个东西。

测试的介入，有测试准入标准、单元测试和UI自动化测试。每日的自动测试还会涉及到一些代码扫描和接口自动化。

测试准入流程是自动或者手动的时候触发建立包的时候，若是发现这个包是编译失败的状况，这种编译失败的状况会第一时间邮件告警到相关开发责任人。

这个告警信息会包括本次构建和上次成功之间代码的差别。还有此次构建是谁触发的，开发是谁提交的。开发的老板是谁，这些信息都会告警出来。

测试准入标准：

• 构建成功是测试最基本的标准。若是这个构建连成功都不行，那就不要谈后面的测试了。

• 不负责任的提交代码致使的构建失败是很是低级的问题。是须要严重跟开发团队交涉的，由于这个严重影响咱们的测试效率。

• 持续集成须要时刻保证项目的输出是可测试的。持续集成是保证咱们测试包是随时随地能够测的。咱们输出是随时随地能够测试的。

单元测试，咱们这边在构建的时候同时完成单元测试的构建。能够经过覆盖率的工具完成这块的单元测试覆盖率报告的数据。

单元测试实际上是跟集成测试最方便集成的东西，这必定要作。由于他的投入产出比很是高，不少问题不经过黑盒的方式，经过单元测试就可以发现。单元测试是整个测试金字塔最核心底层的东西。

单元测试也能够从覆盖率的角度、业务异常输出角度作。我这里重点提一下行覆盖率和方法覆盖率，你们不要特别依赖这个东西，若是只是从行覆盖率角度来作，测试必定是不全面的。

举个例子，咱们有个开发写的代码，他的方法是判断一个字符串是否为数字，他的实现很简单，就是作了一个正则表达式。若是你测这个方法，正向的输入和反向输入，这个方法和行的覆盖数必定是100%，这个100%对你来讲没有意义。

还有不少异常场景没有测到，负数的状况就没有考虑到，小数点的状况他也没有考虑到。这种异常的状况，是咱们测试须要关注的，而不是单单考虑到分支覆盖、行覆盖、方法覆盖的数就认为测试是完成的。

单元测试和UI自动化测试比起来，其最大特色就是很快。除去以前构建环境的时间不算，几百条单元测试可能在几秒以内就执行完了。他的速度很快，他就能够做为天天回归测试重要的步骤，天天持续的构建，持续的测试，这样能够第一时间发现咱们代码变动致使的问题，这是单元测试这块的重要性。

单元测试讲完了之后，能够跟构建信息集成起来了，构建代码提交次数、构建成功率、每次构建花的时间，这是从构建的角度作的数据统计。

测试就能够从测试代码覆盖率、圈复杂度、缺陷数量和代码风格的问题，经过整个测试和构建最终的数据获取。咱们能够把这个报告，天天发给同事或老板看，这是很是重要的数据度量的指标。

UI自动化测试，这是老生常谈的问题，这个我不想说的更细，UI自动化要作吗？必定要作，但UI自动化为何作起来这么让人讨厌呢？它很不稳定，用例维护起来成本很是高。

其次就是执行起来很是慢。若是把它放在天天的构建当中作的话，这个时间太长了。

能够考虑一个策略，天天晚上作一个持续集成，作一个每日自动回归，能够考虑作这样的UI自动化，固然咱们持续集成平台是能够支持UI自动化选择的，支持选择本次构建要不要执行UI自动化测试，还能够支持选择对应的模块用例。

由于本次代码变动若是只是在购物车这个模块的话，就没有必要把其它模块的自动化再去跑一遍。只是作一个增量的测试

。同时咱们UI自动化的执行，也是在线下多台机器作了这样分布式的执行，由于它真的很慢，若是不去实现分布式的话，这么多用例执行完不知道等到猴年马月了。

同时咱们支持用例在线编辑，就是当你刚刚选择一个模块用例，我也能够选择这个模块下部分用例执行，部分用例不执行，这样能够更小缩小UI自动化执行的范围。

最后咱们还有一个自动化执行的报表产出，这样全部的东西，全部UI自动化和持续集成平台相结合。

京东这块敏捷怎么走，京东选的是Scrum的方式去作，如今已经从一个月一版变动到了两周一版。两周一版的迭代，形成的问题就是产品、研发和测试，各个团队压力都很是大。

对测试来讲，根本没有时间对每一个包都作测试。咱们作持续集成怎么同步跟进，让持续集成的脚步可以跟上敏捷的脚步呢？

先说一下构建时机。平台上手动触发的构建，这是按照用户须要。还有是自动构建。可能有同窗想到说构建触发机制是怎样的，是按时触发，仍是按照开发提交代码后当即触发。我以为仍是根据实际须要，个人建议是按时触发，由于你没有办法判断或更改开发提交代码的频次。

能够第一个开发提交代码触发了构建，第二个开发又提交了，这是他的提交可能就没有办法当即触发构建，他可能会被并到下一个构建当中。

还有一种多是在很长一段时间内开发都没有提交，这时候就会出现空档期，出现空转期这时候再有开发提交，那这个空档期就会把以前全部的提交都拉出来，这样时间跨度比较大，同时增量内容比较多。

因此我这边建议是考虑用定时的方式触发。定时的方式有不少好处，定时触发构建，测试就不用再去拿包了，也不用再去等了。

咱们这边平台是支持扫码安装的，第一时间拿包，这个包必定是保证几分钟以内是最新的，这样就免去了等待时间，提高了整块的测试效率。

敏捷的出包策略，我想说代码分支管理每家公司都不同，若是走敏捷的话，大部分都会经过Feature分支作常规的user story开发，Intergration分支作每日集成代码的开发，Master分支是发版的一个稳定的分支。

咱们说无论哪个分支，Feature分支必定是天天定时Merge到Intergration分支，作每日的集成回归测试。因此Intergration分支天天的合并量是很是大的，必定要保证它的回归是正确的，是没有问题的。

它的每个user story被合进来之后，是须要作一个tag标签来指定这个story合并进来而且是没有问题的。咱们项目经理说此次发版出哪一个版本，就能够从Intergration分支选择ABC三个需求，D不上了，能够选择在这个tag下面直接合并到Master分支。因此Master分支基本上是随时随地都能上线的分支。

经过这样的方式，咱们要作到Master分支、Integration、Feature分支都能及时的为测试团队出测试包。最频繁的是Integration和Feature分支。天天的回归集成必定会经过Intergration分支去作，包括天天Feature分支的功能测试，这块自动出包的策略彻底是跟着咱们项目的策略来走的。

问题总结

这里总结一下刚刚提到全部的问题。没有备份环境就经过多点部署。没有统一入口是使用持续集成平台，经过平台作统一功能封装和项目管理。

手动部署环境和缺少有效的配置管理是经过数据全配置化作到自动部署，还有按需版本管理的部署，包括后面的测试和敏捷项目的需求都有经过出包的策略解决。

3、持续集成在京东的价值体现

---

这是三个提高点

• 沟通成本。在最开始的时候，没有持续集成平台怎么办？就是产品、测试、开发，这三我的处处跑，处处沟通，说何时出包，何时测，项目会盯着，产品会盯着测试说这个东西作的怎么样了，能测吗。开发会盯着测试说完成了没有，有问题吗。测试会盯着开发何时出包，何时功能是否解决了。这些大部分的时间都是一些无效的沟通，或者说无心义的沟通，咱们说统一使用持续集成平台的话，能够过滤这样大部分的沟通。

• 测试效益。咱们引入单元测试和自动化测试概念，经过每日持续的构建，持续的测试，就能够帮助咱们节省大量人力测试的投入，单元测试能够帮助咱们很是快，同时很是高效的去发现代码当中的问题。

  • 时间成本。这些实践能够节省有效人力资源的东西，为咱们节省整个项目的进度。

带来的成果

7×24小时提供构建和编译的服务。支撑了超过10万次有效的构建。每日触发400多条单元测试用例，100多条UI自动化测试用例，300多条接口自动化测试用例，超过300万行代码扫描（这是IOS和安卓代码加起来的总量）。这个是属于天天一次惯例的每日执行。成功的帮助了京东大大小小版本按时发版超过15个。

总结

最后总结一下持续集成的方案，京东持续集成可能不是业界最好的，每一个公司内部开发的限制，包括网络运营限制、测试的流程，每家公司不同，一套方案确定不能适用于全部公司，因此只有最适合本身公司的东西才是最好的持续集成方案。我今天的分享就到这里。谢谢你们！