带你解读苏研openstack持续集成实践

持续集成

持续集成(Continuous Integration，简称CI)是指软件开发过程中个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。

持续集成核心价值

持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。

苏研Openstack持续集成背景简介

在未搭建CI环境之前，openstack研发组代码质量基本都由代码评审人员review，但是人工review无法验证最新的代码是否能完成环境部署，涉及的功能点是否能测试通过，并且无法保证某个模块的修改对其它模块是否会产生影响。

因此我们决定引入openstack社区CI环境，但是社区的CI环境是根据source code通过devstack完成openstack单节点环境部署，不满足苏研的需求。经过和研发同事的讨论决定模拟生产环境的部署方式，将source code打包成rpm包放入yum repo，通过苏研自动化部署工具完成一套openstack集群环境部署。

苏研Openstack持续集成流程

组件工作流程

Gerrit

Gerrit主要负责代码的管理

Zuul

Zuul通过捕获Gerrit事件，找到对应的pipeline进行后续处理，而pipeline中定义了需要执行哪些Jenkins任务，这些都是在Zuul的配置文件layout.yaml中定义的，如下为一个check pipeline的片段：

从中我们可以看到check这个pipeline由gerrit的patchset-created/change-restored或comment-added(如：recheck)触发，成功后会返回verified：1消息给gerrit，失败返回verified：-1。

以上是check pipeline of cinder project需要执行的任务。

引入Zuul而不是直接使用Gerrit触发Jenkins的原因是：Jenkins job每次只能执行一个任务，如果一个测试需要执行1小时，每天只能执行24次测试，只能对24个修改做出验证，通过引入Zuul使Jenkins并发测试成为可能。

Zuul同时还可以很好的处理具有复杂依赖关系的多个patch，它也能监控正在执行的任务。

Gearman

在原来的实现中，Zuul完成"事件-pipeline-任务"的匹配后，就可以调用Jenkins执行具体的任务开始实际的测试了。

Jenkins用的是master/slave架构，一台master管理所有slave节点，但是在Jenkins的slave节点增加到一定数量后(大约100台)，Jenkins的master节点就会出现问题而成为瓶颈。

同时master节点是单点部署，无法完成HA，为了扩展Jenkins而引入了Gearman。

加入Gearman后，Zuul不再与Jenkins直接交互，而是提交执行任务的请求给Gearman服务器，由Gearman服务器完成任务的分发(因为苏研openstack项目每天代码提交量不是很大，jenkins只部署了一台)。

测试节点通过注册到Gearman服务器，使得Gearman获知其可用，并被分配任务。

Jenkins Master节点通过Gearman的插件连接到Gearman服务器并获得任务。

以下是通过gearman命令查询jenkins job可以使用的slave节点

nodepool

可用于CI环境中虚拟机资源的弹性管理，可以提高测试环境中虚拟机的使用效率：需要测试的时候创建虚拟机，测试完成后删除虚拟机，目前nodepool管理的虚拟机都是通过对接的openstack环境来维护。

苏研CI测试运行方式

根据openstack研发组实际的情况，现在CI测试运行方式分为以下2种：

Check

Check用于验证每个对Gerrit提交的patch，它是对提交的patch单独进行测试。

例如：A修改了nova某一行代码，部署环境时nova项目的rpm包来自于A的源码打包，而其他项目的rpm包来自于CI自己维护的yum repo。

Post

对merge的代码进行打包，并合入到CI自己维护的yum repo。

环境部署

对于单元测试可能不需要实际的Openstack环境去执行，而对于集成测试则需要一整套的Openstack组件。

对于这些测试Jenkins任务会根据苏研的自动化部署工具搭建一套完整的Openstack集群环境：

3个控制节点，2个计算节点， nova/neutron/cinder/glance/rabbitmq/mysql等等服务都是采用高可用方案，neutron采用openvswitch+vxlan模式，glance和cinder对接的是预先安装好的ceph集群。

部署所需的机器全部来自nodepool创建的虚拟机。

执行测试

1.Style测试

严格的pep8要求检查

2.单元测试、代码覆盖率统计

3.功能测试

实际执行的测试用例也是在Jenkins的任务中定义，通过调用Tempest去实现。

Tempest是一整套Openstack集成测试框架，它的实现基于python的unittest2测试框架和nose测试框架，Tempest对Openstack终端发起一系列API请求，并且对终端的响应进行验证。Tempest通过config文件来描述整个测试环境，包括compute API端点，Keystone server以及Glance server安装的镜像的UUID等信息。

测试的主要模块有如下几部分：

api主要测试OpenStack API部分的功能

scenario主要根据一些复杂场景进行测试

整个CI过程浏览

开发者提交了一个patch

Zuul状态监控

CI执行过程中日志

自动匹配jira工单

测试结果输出

Gerrit上自动添加测试结果

Hygieia仪表盘

通过Hygieia我们能实时看到jira工单的状态，对应jenkins job每天执行情况，以及单元测试结果和代码覆盖率统计结果。

总结

搭建一套CI环境需要考虑的问题有很多，以下列举了几个重要的问题：

问题

1.CI整个过程中日志收集，CI整个流程完成后资源回收

2.部署失败或者测试失败等等异常情况处理

3.搭建自己的pip源(苏研openstack代码基于kilo版本开发，因为该版本社区已经不维护了，导致CI过程中需要的某些python包官网已经没有了)

4.维护自己的tempest项目(如：社区测试时虚拟机都是采用本地虚拟机，而苏研现在大多采用卷虚拟机)

5.nodepool对接的openstack环境改造/性能调优/运维

END