本文介绍如何构建与 OpenStack continuous integration platform贯穿的测试平台。开始前最好对本文upstream OpenStack CI platform in detail中的背景有所了解. 读完本文后,你将具备构建测试平台所需的所有背景知识。
简单的说,就是 运行第三方的独立测试 — 通过将三方驱动或硬件配置到 OpenStack 环境中 — 然后在代码审查的过程中展示相关的测试报告. 通过这个实时的代码审查回馈能很容易的把控代码质量. 下图中,你会看到Neutron的外部测试平台加入的numberVerified +1 and one Verified -1 标签 :
测试平台引入的Verified +1 and -1 标签
每添加一个新的标签就会产生一条comments. 点击注释就会链接到测试平台上的相关测试:
Comments 对应着一次测试平台的review
开发人员可以通过访问相应的链接去排查造成测试平台失败的相关补丁问题.
好处有如下几点:
及时获得反馈
测试平台能提早发现相关补丁提交后可能造成的失败,这能缩短问题解决时间
更好的代码覆盖率
通过模拟测试插件和驱动程序来减少对真实测试环境的依赖。以此为开发人员提供更多的时间专注于业务代码的质量
持续提高质量标准
通过相关用例来测试部分或者全部的驱动程序API以保证与OpenStack的兼容性. 如果你和OpenStack的开发人员聊过,就会知道他们面对如何选择存储或网络供应商或是后台管理模式去兼容将要部署的 OpenStack问题时,这一优势会多么明显!
何必再去思考如何选择测试平台的问题? 已经大把OpenStack项目和供应商探讨过集成测试平台到上游的OpenStack持续集成平台的需求了.Neutron开发社区已经走在前面 ahead of the game,大约快一打的供应商已经在Neutron代码审查中加入了测试的链接.
Cinder项目在讨论 discussions 强制推行一有代码提交就测试驱动的正确性策略。 同样的,Nova 社区也讨论了 discussed 监控源码库的相关策略. 也许这对于有些团队来说不是什么新鲜事, 带希望本文能给新接触 OpenStack的供应商们提供更快融入的帮助
能够和OpenStack持续集成平台协同的测试平台组件如下 :
Jenkins CI
运行相关项目测试任务的服务器
Zuul
组织运行jenkins任务机制的系统
Jenkins Job Builder (JJB)
简化Jenkins任务配置文件的创建维护工作
Devstack-Gate and Nodepool 脚本
从源码库构建OpenStack 环境的脚本
下面我会说明如何使用脚本和Puppet实现上述测试平台的组件功能. 当然还有其他的方法实现相同的功能。
可以根据文档手工安装相关组件. 但我不建议这么做,手动安装有利有弊:
一旦有地方出错,所有工作全部需要返工。如果之前做了什么配置修改,现在全凭记忆来恢复。
无法方便的建立新的测试平台示例.如果要实现就得全部从新配置
好的办法就是使用配置管理平台, 比如 Puppet, Chef, Ansible or SaltStack 来管理组件的部署, 同时使用Git管理配置库. 本文将 通过Bash脚本和Puppet modules实现在多个host或是虚拟机上构建测试平台。相关代码在 source repository on GitHub. 如果你不想用 Puppet或是想用其他的工具, 也没啥问题. 从刚才的源码库中也能得到不少启发 (以后我还会写一些OpenStack 外部测试项目的脚本).
开始安装之前有几点需要注意.按照下述步骤操作应该没什么问题
为了能够发布测试平台的评审备注到 openstack.org, 需要先从 OpenStack Infra 团队注册一个账户. 详细如下 this link for instructions
简单来说需要向 OpenStack Infra mailing list 发送一份邮件,里面包含下述内容:
邮件地址作为系统账户(必须是唯一的Gerrit账户)
账户名缩写会显示在代码评审里
(可选) 账户详细描述
(可选但推荐) 联系方式 (IRC handle, 邮箱地址或是其它间接联系邮箱) 方便上游基础团队联系
访问Gerrit的SSH键值组公匙 . 注意SSH 中不要多出新代码行
还没有Gerrit服务账户的的SSH键值组? 可以创建一个:
ssh-keygen -t rsa -b 1024 -N ' -f gerrit_key
上面命令会生成一个兼职组: 被命名为gerrit_keyandgerrit_key.pub的文件. 将gerrit_key.pub中的内容通过邮件发送到 OpenStack Infra mailing list. 保留上述两个东西方便下面使用。
开始安装测试平台后Puppet modules会保存一系列系统的配置文件,包括Gerrit服务账户的SSH私匙。保存这些文件最理想的东西就是Git配置库了, 任何的变动都会被保存下来就想保存源码那样。
我开了一个账户 source repository on GitHub 作为示例. 和以往不同的是,我建议使用git clone代码到本地库使用,而不要使用fork的模式:
git clone git@github.com:jaypipes/os-ext-testing-data ~/mydatarepo cd mydatarepo rm -rf .git git init . git add . git commit -a -m "My new data repository"
现在就得到了一个本地的配置库来保存相关的配置文件,随便放在哪里都没问题 — 也许是 GitHub,甚至其它地方的Git服务器上.
现在要把上一步创建的访问Gerri 服务账户的键值组也放到仓库里。
如果用ssh-keygen命令创建了新的键值组. 也需要将gerrit_key文件拷贝到仓库里.
如果既没有创建新的键值组 (用的原来的) 或者名字不是 gerrit_key, 那就拷贝该文件到仓库再打开 vars.sh, 修改下述代码:
export UPSTREAM_GERRIT_SSH_KEY_PATH=gerrit_key
将gerrit_key 改成对应的SSH私匙名.
下面打开创库里的filevars.sh (假定你还没打开), 修改下面代码:
export UPSTREAM_GERRIT_USER=jaypipes-testing
把jaypipes-testing改成你的Gerrit账户名.
打开 etc/jenkins_jobs/config/projects.yaml . 修改下面代码:
vendor: myvendor
把myvendor改成对应的组织名
在数据仓中我有公有/私有的SSH键值对 (叫做jenkins_key[.pub]. 因为已经把私匙放过去了现在其实也没啥用,就当个例子吧。如果想建个新的,这样操作:
cd $DATA_DIRECTORY ssh-keygen -t rsa -b 1024 -N ' -f jenkins_key git commit -a -m "Changed jenkins key to a new private one"
好的,现在已经处理好了数据仓库的配置可以开始安装Jenkins master服务器了. 但记住先保存一下相关的更改放到配置库里:
git add . git commit -a -m "Added Gerrit SSH key and username" git push本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
2KB项目(www.2kb.com,源码交易平台),提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务