京东持续集成实践
目录
京东持续集成实践
1、持续集成简介
2、持续集成实践
3、集成环境的部署及自动化测试
3.1、搭建J-auto系统
3.2、J-auto系统使用
4、持续集成数据分析
1、持续集成简介
持续集成不仅仅是一项项目实践，而是多项项目实践的总和。在尝试这些实践时，不可避免要遇到一个问题：为什么要持续集成？如果不能很好地理解为什么，持续集成可能会进入误区，不能带来期望的效果。
质量、进度和成本是软件项目关注的三大要素，它们互相依赖、互相制约。以前软件生命周期模型是程序员负责编写不同的模块，在项目完成之前，一次性的把各个模块集成在一起，再进行测试。使用该种方式会为项目引入很多的未知因素和巨大风险－－开发工程师往往发现越来越多的Bug 等待他们去修复、许多严重问题不能在前期及时发现修正、需求频繁变更导致项目后期时间严重不足等等，这些风险很有可能会威胁到项目的成功。随着对产品的发布要求越来越高、越来越频繁，以前老的方式已经越来越不能满足要求。持续集成允许代码分批提交，代码提交后立即测试，测试在开发过程中一直存在，直至开发完完毕，避免代码积累很多后集成，造成代码质量低下。可以有效地解决项目过程中的许多问题，快速、及时发现系统错误，有效地确保系统质量，减小项目的风险，使得团队从容面对各种各样的变化。在项目过程中持续集成更能及时呈现各种分析报告，让项目中各种角色了解项目的真实状况，从而为正确选择提供了数据基础。
2、持续集成实践
随着京东业务爆炸式增长，需求迅速增加，这对应用系统及时且保证质量交付产生了极大的挑战。此时如果没有良好的管理和高效的工具来帮助测试，整个测试团队必会处于混乱的状态，导致无法在短时间内保质保量地完成应用系统的测试任务，那么整个测试团队命运必然是被淘汰。在此背景下，交易质量部提出一套高效可行的解决方案——京东持续集成JCI (JD Continuous Integration)。从而节约了时间成本，提高了应用系统质量，增强了项目的可见性，使研发工程师与测试工程师之间的协作更完美。持续集成闭环系统环节如图25-1所示：
图25-1 京东持续集成
持续集成方案如图25-2所示：
图25-2 持续集成方案
京东持续集成包含子系统：
- J-one：其负责静态代码扫描、代码编译、提交测试并发送提测JMQ消息等；
- J-auto：其负责接受提测JMQ消息、解析JMQ消息并自动搭建部署测试环境、自动执行测试用例并发送测试详情报告、保存测试执行数据等；
- J-cim：展示各种分析汇总的结果数据等；
- Source：存储系统代码、测试脚本等数据等；
3、集成环境的部署及自动化测试
测试环境部署是一个重复且费时的工作。随着需求增加，测试环境部署及应用系统测试的成本显著增加。为了减少工作成本提高效率，经过测试工程师们积极探索，成功地引入自动化部署及自动化测试。
自动部署及自动化测试方案整体流程图如下：
图25-3 自动部署及自动化测试方案整体流程图
流程图解释说明如下：
①通过京东J-one系统提交测试时，J-one会产生提测的JMQ消息：
②J-auto系统接受并解析JMQ消息，获得提测的详细信息，如：应用名称、开发工程师、测试工程师、被测代码分支、安装介质下载地址等等；
③获取应用于任务映射关系，关系包含：应用名称、部署任务名称、自动化测试任务名称、部署目标主机ip、任务是否启用等信息；
④调用主任务，主任务负责在京东云下载安装介质、分发安装介质及部署脚本、调用部署子任务；
⑤执行部署，部署任务根据映射关系信息，执行部署脚本。部署完成后，发送部署结果反馈。如果成功部署则启动自动化测试，否则回滚环境；
⑥自动化测试任务，从Source系统获取测试相关测试脚本，运行测试脚本并反馈测试结果等信息。
3.1、搭建J-auto系统
J-auto系统包含两部分，Jenkins任务调度模块及Jenkins模块。搭建步骤如下：
安装JDK：
在应用服务器上的指定目录下新建目录，如：/xx/xx/java。将安装包剪切到java下，并解压。命令如下：
| mv ./jdk-7u80-linux-x64.tar.gz /xx/xx/java/jdk-7u80-linux-x64.tar.gz cd /xx/xx/java/ tar –xvf jdk-7u80-linux-x64.tar.gz |
配置JAVA_HOME环境变量,命令是
| Export JAVA_HOME=/xx/xx/java/jdk1.7.0_80 |
安装tomcat：
在应用服务器上的指定目录下新建目录，如：/xx/xx/tomcat。将安装包剪切到tomcat下，并解压。命令如下：
| mv ./apache-tomcat-7.0.30.tar.gz /xx/xx/tomcat/apache-tomcat-7.0.30.tar.gz cd /xx/xx/tomcat/ tar –xvf apache-tomcat-7.0.30.tar.gz |
将Jenkins任务调度模块部署到tomcat 容器中。
安装jenkins：
将安装包剪切到/xx/xx/tomcat/apache-tomcat-7.0.30/webapps/jenkins下并解压。
命令如下：
| mv ./ jenkins.war /xx/xx/tomcat/apache-tomcat-7.0.30/webapps/jenkins/jenkins.war cd /xx/xx/tomcat/apache-tomcat-7.0.30/webapps/jenkins/ jar –xvf jenkins.war |
启动jenkins，在tomcat的根目录下，执行
| cd ./bin ./startup.sh |
jenkins全局配置
访问jenkins系统，注册用户并登录后，点击左侧的【系统管理】菜单，再点击【系统设置】，界面如下：
图25-4 Jenkins系统设置
图注：
- Jenkins主目录，存放Jenkins任务数据、构建数据等；
- 选择【Role-Based Strategy】搭配【Role-based Authorization Strategy】插件实现根据角色权限命名任务；
- 邮件配置，包含邮件服务器，邮件模板等信息
角色权限配置，首先，点击【系统管理】，在点击【Configure Global Security】，启用及配置安全策略，如下图25-5所示：
图25-5 配置安全策略
图注：
- 启用安全
- 安全域选择【Jenkins专有用户数据库】并允许用户注册
- 授权策略选择【Role-Based Strategy】
其次配置角色权限，如图25-6所示：
图25-6 配置角色权限
图注：
- 创系统中的全局角色及赋权
- 创建项目角色及赋权
- 建机器节点角色及赋权
最后，为用户分配角色。点击【系统管理】，点击【Manage and Assign Roles】，点击【Assign Roles】，界面如图25-7：
图25-7为用户分配角色
图注：
- 给用户关联全局角色
- 用户关联项目角色
- 用户关联机器节点角色
配置机器节点
点击页面左侧【系统管理】，点击右侧页面的【管理节点】，点击左侧的【新建节点】，节点信息编辑界面如下：
图25-8配置机器节点
- 节点名称
- 设置执行者的数量
- Jenkins执行目录
- 机器节点的标签名
- 机器节点的使用方式，选择【只允许运行绑定到这台机器的Job】
- 机器节点的启动方法，选择【Launch slave agents on Unix machines via SSH】
- 节点链接启动时的ip地址
- 节点链接启动时鉴权的账户与密码
- 节点机器上的工具配置，支持JDK、maven、ant等
配置完成后，链接节点。
Jenkins主任务配置
首先创建任务时，选择【构建一个自由风格的软件项目】，如图25-9所示
图25-9 构建自由风格软件项目
配置【General】信息，如图25-10：
图25-10 项目常规信息
- 任务名称；
- 任务描述；
- 历史构建信息保存策略设置；
- 设置任务运行时的接受的参数，图片中只展示部分；
- 设置任务支持并发运行；
- 设置的任务运行的目标机器节点；
配置【构建环境】，如图25-11，介绍如下：
图25-11 配置项目的构建环境
- 勾选【Abort the build if it's stuck】，超时策略选择【Absolute】，时间阈值25分钟，此设置保证运行异常时，任务可以中断，防止影响后续其他任务的运行。
配置【构建】，如图25-12所示，介绍如下：
图25-12 构建配置
增加构建步骤时，选择【Execute shell】，编写脚本。
配置【构建后操作】，如图25-13所示，介绍如下：
图25-13 构建后操作
点击【增加构建后操作步骤】，选择【Editable Email Notification】，设置构建后的邮件通知策略。
3.2、J-auto系统使用
J-auto系统搭建完成后，下面就是应用J-auto系统进行自动部署和自动化测试了。首先，需要在Jenkins中新建一个自动化测试任务，与主任务不同，在创建任务时选择【构建一个maven项目】，如下图所示：
图25-14 构建maven项目
【源码管理】配置中，①处配置测试脚本源码地址及鉴权账号和密码；②处设置测试脚本的分支名称。
图25-15 设置代码分支和鉴权
【Build】环节设置
图25-16 build环节设置
①配置Maven的.pom文件
- 置Maven的运行命令
然后新建一个自动部署任务，其与主任务配置类似。需要注意此任务存在shell脚本调用shell脚本的情况，【构建】环节编写shell脚本时，需要加BUILD_ID=[DoNotKillMe]。防止外层脚本运行完成，但是内层脚本仍在运行时，内层shell脚本被终止，如图25-17所示。
图25-17 自动部署任务的构建
另外【构建后操作】除了发送反馈邮件配置，增加【Trigger parameterized build on other projects】步骤，用来关联上一步建立的自动化测试任务，启动自动化测试任务进行测试。
图25-18 自动部署任务构建后操作
- 需要启动的自动化测试任务名称。
- 设置启动后续任务策略。图中配置是部署成功后启动后续任务。
- 勾选后，启动后续任务不使用参数。
映射关系配置，是整个系统运行起来的关键环节。指明了那个应用系统部署在那台机器及应用部署的目录、应用的域名等信息，链接提测到自动部署自动化测试环节，如图6-19所示。
图25-19 链接自动化部署
此时研发通过J-one系统提交测试，J-auto接受提测的JMQ消息，就可以触发后续的自动部署、自动化测试、及各环节反馈，如图25-20。
图25-20 提测界面
图25-21 自动部署结果反馈
图25-22 自动化测试结果反馈
4、持续集成数据分析
持续集成过程中，我们可以从编译、部署、测试等环节中拿到许多相关数据。通过对这些数据分析和数据挖掘，可以帮助我们后续质量评估分析、质量趋势分析、质量可回溯分析等，有效地规范项目流程，发出项目风险预警。下面单从应用缺陷方面进行分析。
应用缺陷数据分析，是持续集成数据分析中一部分，顾名思义就是对测试过程中发现的各种缺陷的汇总分析。既然是数据分析就得有数据模型，应用缺陷数据分析的模型如下:
| 指标 |
指标说明 |
| 所属项目 |
被测应用归属的项目 |
| 所属模块 |
产生缺陷的功能模块 |
| 发现阶段 |
发现缺陷的时间，如：需求评审、设计评审、编码开发、单元测试、功能测试等 |
| 研发工程师 |
编写相关模块及解决该问题的人员 |
| 缺陷级别 |
缺陷的严重性，如：建议、轻微、一般、严重等 |
表25-1 缺陷数据分析模型
通过构造缺陷在软件生命周期的各环节的属性进行分析，从不同维度得到各类缺陷的缺陷个数和缺陷比例，积累得到各类缺陷的基准值，用于评估测试活动，指导测试改进和整个生命周期流程的改进。比如，按模块进行单维度分析，可以得出各个功能模块的缺陷密度，从而了解各个功能模块的质量状况；还有按发现阶段分类分析，按模块加验证程度分类分析等等；
图25-23 按照项目统计bug数
再有通过已有项目历史数据进行缺陷趋势分析，缺陷趋势可以通过每日新建bug、每日关闭bug、累计未解决的bug，累计关闭bug、bug总数等指标进性分析，通过缺陷增长和减少的趋势，了解测试的效率和开发修复bug的效率、测试瓶颈等。可以通过每日新建bug趋势来了解测试的效率，正常来说提测中前期每日新增bug指标应该逐渐增加并达到一个峰值，然后呈下降趋势，最后趋向于0。符合这个趋势说明测试效率和测试质量较高，且开发修复bug新引入bug的概率是比较小的。每日关闭bug指标反映了研发工程师的处理响应速度。每日关闭bug数大说明研发修复bug效率高。如果新建的bug数越来越小，但是关闭的bug数量一直小于累计未解决的bug数，则说明研发同学效率低，是项目的瓶颈。bug总数曲线和累计关闭bug数应该大体一致并且最后重合。
图25-24 bug趋势图
文末备注：
此文书写实践是一期摸索实践，写了很久没有时间发布分享给大家，最近才有时间整体出来，这并不是最佳实践，只是记录实践探索，希望能给大家带来思路和借鉴，我的二次摸索实践在进行中，希望后续有机会能给大家分享最佳实践；