京东到家的持续集成实践之路

内容来源：2017年4月8日，京东到家资深测试开发工程师孙斌在“饿了么技术沙龙北京测试专场”进行《持续集成实践》演讲分享。IT大咖说作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数: 1716 用时: 11分钟

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编辑、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

1、减少风险：越早发现的错误，修正的费用越低。及时检查软件测试的健康状况，减少发布时的风险。

2、减少重复性的工作：通过自动化的持续集成可以将编译、部署、测试等动作都变成自动化的，无需太多人工干预。

3、任何时间、任何地点都可以部署软件：利用持续集成，可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到。

京东到家是基于地理位置的o2o生活平台。虽然业务和京东商城不太一样，但是系统的复杂度不低于商城，从成立到现在有200+个服务。系统之间依赖度高，但是由于业务的特殊性，迭代速度比较快。如何使各个服务能够快速部署快速测试上线，对测试和研发工程师形成了很大的挑战。我们引入了持续集成的概念，并开始逐步实施。

持续集成帮京东到家解决了三个问题。

1、提测质量差。如果压缩了开发周期，质量一定是不行的。

2、测试周期长。一旦代码质量变差，测试投入成本就会很高。

3、重复性的工作多。

持续集成需要整个team都达成共识，按统一好的规则去做同一件事。

我们先找了易做的、影响力大的事情去做，然后用一个项目去做试点，会得到一些数据，就可以用这些数据去说服领导和同事。

提高代码到git，代码静态扫描，然后单元测试和代码覆盖job会运行，之后编译打包，部署到对应的服务器上。

UI、jsf和App会运行自动化测试，并修复和分析失败的case。如果有需要再做功能测试，收集功能测试代码覆盖率。

目前我们对这套代码的要求就是要修复阻塞和重要级别的bug，新增代码必须达到一定的覆盖率。所有系统都做到自动编译、打包和部署。必须覆盖主流程，不断添加测试用例。及时查看覆盖率报告，对于新增代码业务逻辑必须全覆盖。

第一阶段：需要手动编译、打包、部署。解决方案就是引入jenkins自动化编译打包部署。

第二阶段：服务器硬盘打满了，一台机器上部署的服务太多，服务停止。我们做的就是定时清理硬盘空间，监控服务状态，自动重启服务，保证总体服务可用。

第三阶段：主要问题是分布式服务之间调不通。是因为迭代速度快，开发在本地调试，随意修改本地配置文件。组名不对导致调用不到服务。

我们部署了两套测试环境，一套对外提供服务，供他人测试调用，一套自己使用。保存本地配置，与线上配置比对，防止误改。使用自动化测试，检查整个系统的健康状况，及时修复。

1、配置Sonar环境。

2、配置jenkins环境，下载sonarqube插件，并进行配置。

3、在jenkins代码静态扫描的job后，配置运行sonar。

Jenkins运行mvn clean install命令，生成代码覆盖率报告。

1、启动脚本中插入监听参数。

2、Dump出监听文件。

3、使用Ant脚本生成最终的html。

配置到jenkins的持续集成环境。

1、配置maven pom.xml文件。

2、配置Jenkins job。

当时选择appium是因为它支持android和ios系统，支持现有框架和多种语言，而且可以跨应用。最重要的是appium不依赖于源代码。

APP自动化测试在持续集成中也遇到了一些问题。针对网络不稳定失败率高，我们引入了重试监听，如果重试3次还不能通过，那就是有问题的。第二个问题是不容易定位case失败，我们加入了截图和log日志功能，多打日志加截图，就能发现整体的问题所在。还有就是运行速度慢，android可以启动多个服务，分布运行。

以上是我今天分享的内容，感谢聆听！

点击【阅读原文】进入干货密道