自动化构建测试环境讲述.docVIP

Jenkins Docker 自动化构建测试环境 2015年5月23日 履历变更 文档版本 更新日期 变更内容 操作人 1.0 2015.05.12 创建文档 新增创建Jenkins用户章节 新增安装Jenkins Publish Over SSH插件章节 新增常见问题处理章节 郑桐 1.1 2015.05.23 1.新增自动化构建测试环境介绍章节 2.新增假设章节 3.新增声明章节 4.新增宿主机环境介绍章节 5.新增宿主机环境设置章节 6.新增宿主机安装Docker章节 7.更新容器中安装Jenkins章节 8.更新创建Jenkins用户章节 郑桐 1.2 2015.05.24 新增dm.basesize不起作用章节 新增Docker容器导出/导入章节 郑桐 1.3 2015.05.25 新增如何设置Docker镜像和容器的存储目录章节 新增Docker镜像导出/导入章节 更新宿主机环境设置章节, yum增加tar、dos2unix两个包的安装。 更新制作一个通用环境镜像章节，yum增加tar、dos2unix两个包的安装。 郑桐 目录 一、自动化构建测试环境介绍 4 二、假设 6 三、声明 6 四、宿主机环境介绍 6 五、宿主机环境设置 7 六、宿主机安装Docker 7 6.1安装docker，并做相应设置 7 6.2网桥模式设置 7 6.3启动docker 7 6.4 开机自启动 8 6.5获取CentOS6镜像 8 6.6 查看本地镜像 8 6.7 制作一个通用环境镜像 8 6.8 创建容器(即启动镜像) 9 6.9 容器管理 10 6.9.1 使用脚本创建容器 10 6.9.2 启动所有Exit状态的容器 11 6.9.3 重建容器 11 6.9.4 创建配置文件 12 6.9.5 创建脚本文件 12 七、容器中安装Jenkins 17 7.1 创建一个Jenkins容器 17 7.2 在容器中安装Jenkins 17 7.3 启动Jenkins 17 7.4 开机自启动 17 八、创建Jenkins用户 18 8.1用户创建流程描述 18 8.2开始配置 18 九、安装Jenkins SSH远程插件 21 9.1安装插件 21 9.2配置主机列表 22 十、常见问题处理 24 10.1用户无法登陆处理方法 24 10.2 dm.basesize不起作用 25 十一、附加参考 26 11.1 Docker容器导出/导入 26 一、自动化构建测试环境介绍 对于软件公司而言，人员流动是一个非常常见的现象，大部分有激情的人在一家公司很难超过三年，原因是企业一般每年调薪幅度在8%-15%之间（对于一个学习能力很强的人来说，除了跳槽之外很少有其他选择），致使软件公司每年都会出现阵痛期，阵痛的理由大致有几种，其一是日常工作产出不完善，其二是创新部分得不到继承，其三是交接存在遗漏。 我老大说过这么一句话，是个人都能做测试的工作。其门槛过低伴随着薪资也同样非常低，刚培养出来的人，甚至还未能独挡一面就会觉得自己的价值和能力应拿更多的报酬，因此选择跳槽来为自己加薪。 若一家软件公司产品过多，每个产品与产品之间都有相当高的耦合时，对管理人员则是一种挑战，每个产品除了自身的业务之外，还要常常考虑到多产品联合测试（联调），若源头产品在原有耦合高的业务上进行变动则会导致一条产品线的所有产品都需要配合改动。 在过去两年的测试工作中常常会遇到一种窘境，研发总是抱怨测试人员提交的问题大部分是测试环境缺表或者缺字段和试图等环境问题，上述所描述的所有情况都在我所处的这家公司一一兑现着并正在持续进行中。 环境的复杂程度正日益剧增，属于十年前的工作模式（研发版本发布之后，手动上传到redmine/jira，测试人员下载下来手动将环境部署，执行测试，更新升级说明文档，测试完毕后发布程序包，运维人员按照更新说明文档升级/实施人员按照更新说明文档全新部署，上述这些环节对测试人员的依赖特别严重，若测试人员能力不够则会在部署完毕后出现一大堆问题并且产生出大量的无效bug拖延整个产品进度，若测试人员不够仔细更新文档致使文档出现遗漏则会导致后续环节产生大量的线上bug）在当前环境下已不再适用，若在不改变原有工作模式，当问题积压到极限时会在未来不长的某个时刻一触即发。 最理想的状态是，测试人员只需要关注当前版本修复的功能及新需求的测试。如此简单的一句话，背后需要展开以下两个方面的工作，一、自动化构建测试环境，保证测试环境正确，研发不再说这是一个环境问题导致的bug。二、基于原有业务有自动化的ui测试和白盒测试以及正确的断言，保证原有功能正确。 想象一下，当研发提交了代码并发起测试申请后，测试人员仅需在j