3月11日晚8 ~ 9 Jenkins持续集成答疑帖

请大家把问题回复在这里,我们答疑时间为3月11日晚 8~9.

问题1:持续集成如何作用在开发初期?
一个版本还没有稳定,功能还没有都实现,接口、UI可能随时处于变动状态,请问这时如何介入自动构建版本后自动测试?这时准测条件如何设定?

1 Like
  1. 对于测试环境的自动发布与app自动打包条件允许可以先推进代码开发与调试,后期开始测试之后这2部分的内容的自动化肯定对提升测试效率有帮助;

  2. 对于自动测试,在前期产品功能不稳定的情况下,可以先推进代码的开发,中间有问题的功能在测试代码中给Mock过,待功能完善之后再把Mock代码拿掉;

  3. 常规而言可以设定产品的主流程能够成功为准测条件;

1、docker管理jenkins有什么优点吗?老师您的公司是何如部署的?
2、jenkins master和slave模式,是master只负责调度,实际工作都靠对应slaver执行吗?那么是不是master也不会装很多的插件?

问题2:怎么评判我用了jenkins持续集成后增加了工作效率,以有利于推广到整个项目组;能否讲下老师公司用jenkins具体实现了什么吗?

  1. Docker 的优势在于方便持续集成、持续发布、版本控制、容易移植,对于Jenkins这种工具而言采用Docker部署是否划算要是否经常需要做上述的这些事情;如果Jenkins只是作为一种工具,不是经常需要升级、移植之类的,个人认为没有必要一定用Docker来部署自己的Jenkins, 除非你想通过Jenkins的使用顺道也学学 Docker。 我们团队目前使用的Docker就是直接Java启动的,使用起来也挺方便的。

  2. Master 与 Slave 上都可以执行工作,可以自己规划一些策略分类, 比如可以控制安卓的任务限定在一个Slave上运行, iOS的任务在Master上运行。

  3. 插件其实是Jenkins本身的功能,master 与 slave上都可以利用插件的功能。

评价效率这种事情可以有一些简单的算法,比如如果没有Jenkins 一些任务手动去做,每执行一次需要多长时间,然后一周需要做几次,时间 * 次数 = 每周节约的时间

我们的Jenkins主要做的事情是 持续集成做测试包 + 功能自动化测试 + 单元自动化测试

如果说Jenkins 可以集成做单元 接口 ui自动化 这些事情,那么把这些东西打包到docker里的意义,我理解的是这一套的东西可以装在docker里 ,换到另外一个机器 ,直接展开就可以用了,不用再重头搞一遍环境。


我的Jenkins里面好像没有这一项。

对,如果这样持续集成的搞,在做这种环境迁移的话Docker肯定会有很大的优势。


testng的插件怎么才能显示失败的构建?

在Nodes 里面设定至少一个slave节点,看看能不能解决这个问题。

需要故意造一个结果失败的用例试试。

老师使用的$BUILD_STATUS这个job的内置变量是在哪里获取的到的?
我查了百度,官网,都没有查到。
比如我本地的jenkins,下面的url中都找不到BUILD_STATUS这内置参数。其他同理。难道是因为jenkins的官方文档不够详细,以至于只能使用那些散落在网上的参数。
http://localhost:8080/pipeline-syntax/globals#env
http://localhost:8080/env-vars.html/

用Jenkins发邮件的时候,可以在邮件中引用这个参数。

如果是APP的自动构建、然后自动UI测试,那这时如果要Mock接口返回的数据(为了让UI自动化能进行下去),UI自动化和接口的mock如何结合?

一般来说Mock方法是为了开发自动化过程中的为了让自动化可进行才“不得已”做的事情;

在这种自动构建+自动UI测试的所谓 “全自动” 环境里建议别轻易"mock",因为Mock很容易让问题被绕过。

如果必须走Mock, 可以考虑用环境参数来控制接口的返回值。

关闭