匿名吐槽 可持续集成是这么做的吗?

匿名 · June 04, 2016 · Last by ting replied at August 15, 2016 · 1341 hits

公司最近在搞可持续集成,我来配合配置工程师将自动化测试脚本放到可持续集成环境,然后开始了我毁三观之旅:

  1. 构建流程是 jenkins调用slave节点发起构建命令,然后slave把所有需要东西再分发另外一台机器上部署运行,在流程上毁了我一观,难道部署运行不在jenkins节点服务器上运行,而是单独开辟另外一台孤零零的机器去部署运行成果物???一切的噩梦源于此种流程
  2. 运行脚本的基础环境在集成环境中木有,需要提供初始化用例运行所需要的基础环境,包括jdk、python、maven等等。。。。运行环境要特么这么干净吗 ?我要提供所有初始环境所要求的安装包,而且要特么绿色版,还要在脚本里配置各类型的环境变量,保证我的自动化脚本能够找到第三方库和自己开发的库,这样折腾了几天,终于把相应的bat文件提供给配置工程师了
  3. 最不能忍的就是构建结果jenkins不发邮件,要特么自己开发程序去发邮件,还得是命令行类型,然后测试报告也不能在jenkins里展示,需要在运行测试脚本之后提供把测试报告文件上传到指定ftp上去

我在想 jenkins到在可持续集成里到底扮演的什么角色?就是简单调用bat命令即可吗?那我用jenkins有个屁用啊 ??我是可持续集成的小白,但是看可持续集成的资料没有这么去落地的,完完全全地毁三观,想问问社区的各位筒子们 可持续集成是这样的做的吗?

共收到 6 条回复 时间 点赞

我说一下我的看法吧。关于第一点。把自动化测试放到单独的slave上运行的情况,一般是master机运行的东西太多了带不起来,或者master机不具备自动化测试所需要的环境。例如如果你的测试是UI自动化,那么一半由Linux组成的master机就跑不了,或者你们用的jdk不一样等等原因。我不清楚你们是哪个情况哈,如果都不是那我觉得那是没什么必要单独弄一台机器。
关于第二点呢。有些情况来说,确实要qa来提供搭建自动化测试环境脚本的。因为很多情况下OP或PMO只能给你一个原始的环境。他是不知道你的自动化测试框架到底依赖了什么东西。测试框架与开发框架本就是可以互相独立的。例如以前我们开发用PHP开发,我用java语言照样测试。OP和PMO最多也就是帮你搞定产品的部署,让他们去部署自动化测试环境确实强人所难。毕竟他们平时的工作已经很忙了。当然了如果你们的op和pmo十分强大或者很闲那就另说了。创业公司可能都没有这两个职位,都是开发和测试兼职做了。例如我的自动化测试环境都是我自己做docker的镜像,下载开发代码,打包,部署。安装jdk,maven什么的都是基本的
至于第三点,我也不太理解为啥不用jekins发邮件和看报告。这些功能jekins都有,是你们公司不会用?还是你们公司有别的特别的考虑我就不知道了。

#1楼 @ycwdaaaa 第一点我也是理解master带不动,用slavey去跑任务,关键是现在slave节点也不去跑,而是slave节点再发程序到另外一台目标机上运行测试,完全脱离了jenkins的监控范围,就是因为此种方式,导致jenkins解析不了测试报告,因为测试报告不在jenkins的workspace中生成
至于第二点,倒真是因为后期可能很多台机器要部署环境,配置工程师也说这样我没加一台机器就要重新部署一次环境,我想既然你都开始用虚拟机来扩容增加节点,为什么不做一个带有基础环境的虚拟机镜像,这也算是一劳永逸的事情,为什么要运行脚本的时候我要提供基础环境,而且在windows中,不是所有依赖都可以用绿色软件来解决的
第三点,配置工程师总是和我强调后期可能多个事业部都会用到这一套环境,其他所有部门都是这样做的,为什么你们测试部这么特殊,我是想什么我都用批处理干了,那我特么要jenkins有毛用,这不重复造轮子嘛

#2楼 @anonymous 我觉得你们应该用 docker 或者虚拟机,隔离不同部门,甚至不同项目的运行环境。

一个环境多个部门共用以后绝对是噩梦。

曾经做过好几年配置管理的人来回答:
1:持续集成是一种理念,从最早的每日构建开始发展到持续集成,即尽早编译,尽早测试,尽早的发现和解决问题。
2:任何的持续集成工具,都只是一个框架,从很早的cruisecontrol是这样,IBM的buildforge也是一样,就是和版本管理工具做集成,发现变更,触发构建脚本,触发后续操作(通知,部署,测试等),Jenkins也是一种框架,至于里面的构建环境的准备,部署的过程,触发通知等操作都需要自己用Plugin或写脚本来实现。

另外,你说的几个:
1:构建环境和发布环境肯定是要独占的,因为你要确保你的构建环境是正确的环境。多系统共用更是噩梦。
2:环境肯定要干净,要不然出问题都不知道哪里出的, 另外, 这活只要干一次即可。
3:Jenkins是一个框架,如果没有发邮件通知的功能,自己可以定制,另外,测试报告本来就不应该在Jenkins中展示。

我觉得还不如你自己搞一套测试自己的就好了。

本人专职持续集成测试,
1.不在slave上跑case的情况也常见。但不代表脱离jenkins控制范围。我们这儿是在slave上启动测试,从机器A开始执行测试脚本,对机器B上的待测软件做测试。一样可以把测试结果收回slave上。你没收,自然没有结果。
2.也很正常,还是那句话,都能做,只是在于你有没有做。我们这里,上一点上提到的机器A,在旧时代是自己装好软件的机器,现在云时代是自己装好之后再复制出来n台的虚拟机。
机器B的待测软件环境,旧时代是用脚本在每次测试时重装整个系统,云时代是每次测试时重新建栈。
3.邮件也是能发的,但如果你指望配置一下就完事,连个插件都不用装,那真是做梦。最基本的原理是让你的slave等着真正的测试机跑完测试结果并发回slave机。这一点都想不到或不愿意去想,你还搞什么持续集成?

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up