Jenkins与持续集成流水线

发表于:2017-10-31 15:55  作者:Kevin_Y   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试工具 jenkins 集成测试

  目录:
  1.序言
  2.job的基本配置
  ---2.1 源码管理
  ---2.2 构建命令配置
  ---2.3 构建触发配置(何时开始构建)
  3.插件及常用功能
  ---3.1 构建后操作:触发下个构建
  ---3.2 构建后操作:邮件通知及附件
  ---3.3 构建后操作:单元测试报告展示
  4.流水线配置
  5.结语
  1.序言
  当传统工业的大部分工作都交由软件控制时,软件生产商还有什么理由人工处理机械性的工作呢?
  当我们提交了一部分修改完成的代码后,我们总是希望可以快速、持续地得到直观且有效的反馈,以达到我们持续快速交付的目的。持续集成也是敏捷开发的好伙伴。Jenkins工具则是我们达到目的的利器。
  我们在平时的工程中,总有一部分工作是相对机械化,易出错的(例如部署,打包),把这部分工作较给机器来做,我们仅需要轻轻地点一下鼠标泡杯咖啡就能让自己轻松地完成工作,岂不是美滋滋?
  简单地说,使用自动化持续集成工具的目的是为了,让我们仅仅去关注我们最核心的功能(用户需求的代码编写)。
  先来介绍什么是一条流水线(骨架),然后再一步步完善每一个步骤(血肉)。过程中会介绍两种常用的构建工具,gradle(Android工程)与maven,还有常用的插件、功能。
  不妨先梳理一下日常工作的步骤:
  1.编写功能(程序猿的核心价值)
  2.使用IDE编译  //gradlew build & mvn complile
  3.运行单元测试用例(遵循TDD的良好开发习惯)//gradlew test & mvn test
  4.运行集成测试/功能测试(如果有的话.....) //? gradlew integration (自己配置的job 可以参考gradle in action) & mvn integration-test
  5.部署/打包 // gradlew assembleDebug & mvn package
  6.@#¥%……&*()
  步骤2-5则是机械性的重复工作,若交由工具完成,可以让我们专注于其他核心价值。先贴一张流水线(pipeline)的图,介绍完基础步骤后再介绍流水线的搭建。
  流水线(绿色:通过,红色:失败,蓝色:未执行,黄色:不稳定的)
  图中的信息表示为:第254次构建-->客户端代码编译及风格检查-->运行单元测试用例-->运行集成测试用例-->打测试环境包(部署到测试环境)-->打正式环境的包(手动启动,前四步为自动执行)
  我们可以通过流水线的一次构建,来快速地知道我们是否在哪个环节有错误,如果没有错误,我们就可以很自信地交给QA或部署。
  我们再回头看一眼我们的工作步骤及括号中的命令,其实每一步都是在运行构建工具执行一条命令。而Jenkins的核心也就是代替人工一条条地去执行工程中约定好的命令,并且对每一条命令进行反馈。所以配置Job无外乎配置所需要执行的命令。
  2.一个Job的基本配置
  点开流水线中的任意一个job的配置项,我们可以看到如下图
  红色框框出了大体的配置思路的目录,可以说是非常友好了。
  general:基本配置,job名、描述等
  源码管理:git or svn 用户名及密码亦或是上游工程的源代码
  pre setep:构建命令执行前的操作
  build:构建命令
  构建操作:包括对测试覆盖率的收集等
  构建后操作:构建后发送邮件、是否把某个文件发布到workspace、配置下游job等
  我们从大方向说起
  2.1 源码管理
  在这里介绍两种常用的来源
  1.Git:通常为pipeline的第一个job的来源,从远程代码库拉取代码即可,配置如图,包括仓库地址、账号、分支就够了
  2.clone workspace:该选项的意思是,克隆某一个workspace(这TM不废话),兄弟你先别急。选择了clone workspace就可以直接使用上游构建的代码库,可以省去一次执行build命令的时间,并且保证本次pipleline的构建使用的都是统一的代码库。通常使用在非第一个的job。
  使用clone workspace时候有一个需要注意的地方,就是上游“构建后操作”必须添加如下配置,不然你无法拉取到上游的workspace
  2.2 BUILD 构建命令配置
  maven工程
  maven工程的构建命令很简单,配置好pom文件的路径,以及所要执行的命令就可以了(图示即为打包为jar的命令)
  Android工程
  gradle命令作为构建工具依旧简单,只需要配置gradle版本,需要执行的命令即可(图示为运行android的测试用例,并且生成测试覆盖率报告)
  2.3 构建触发器
  构建触发器就是说何时开始构建,比如当jenkins检测到git上有新的代码提交就进行构建,又或者是2小时轮询一次,发现有新代码就进行一次构建。
  图示的配置项即为通过轮询方式进行构建,每2分钟进行一次源码变化的检查,如果有新的提交,则构建,否则不作操作。
  通常配置为:第一个job进行轮询,后续的job的触发方式由上游job build成功后自动触发
  由上述的3个步骤就可以配置出一个独立的job,但是它远远无法达到持续集成的目的。
  但是一个持续集成的流水线正是由数个job配合工作的产物。
  下面我们来完善我们流水线中的细节。
  我们始终要记得持续集成中的主体思路
  1.编写功能(程序猿的核心价值)

  2.使用IDE编译 ? ? ? //gradlew build & mvn complile
  3.运行单元测试用例(遵循TDD的良好开发习惯)//gradlew test & mvn test
  4.运行集成测试/功能测试(如果有的话.....) //? gradlew integration (自己配置的job 可以参考gradle in action) & mvn integration-test
  5.部署/打包 ?// gradlew assembleDebug & mvn package
  步骤2-5均为一个job,每个job都需要前面已经介绍过的配置,才能运行起来,但是每个job都有各自不同的地方。
  通常步骤2即为一个pipeline的起点。当编译结束后,我们应该运行单元测试(进入步骤3,进入下一个job),如何做?
  你还记得构建后操作吗?


21/212>

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2019, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道