buildbot实战

Buildbot是一套基于python的的持续集成系统，可方便的进行自动化构建、部署、测试和发布。类似于Jenkins，但更轻量化且易于直接使用python进行扩展。Chrome社区就使用的buildbot作为其CI系统。
类似于Jenkins，buildbot在一个CI系统中扮演的更多是一个任务执行者的角色，其工作流程如下：

监控代码仓库
代码仓库有变化后，立即拉取代码
执行build、部署、测试及发布工作
反馈结果

我们对这样一个工具的一般要求为：

轻量级，安装、配置简单，本身耗费资源较少
高效率，较快的完成自动化任务
通用性强，在不同的操作系统，甚至与不同的代码系统兼容
易扩展、配置及管理，能较简单的配置自动化任务

Buildbot和Jenkins都能很好的满足我们这些要求。但相比Jenkins，buildbot更轻量级，部署配置更为简单。
Web界面也更简单美观一些。

架构

buildbot架构比较简单，主要分为三部分：

版本控制层
外部版本控制，通过插件或主动触发的方式触发buildbot执行任务。
任务执行层
master接收任务后，调度其slave执行任务，并获取到返回的结果
通知层
master获取结果后，可通过邮件、IRC等方式进行通知。

其中重要的主体是master和slave，其主要采用星形拓扑结构，一个集群中可以多个master、多个slave。master主要负责任务接收、调度并通知任务，slave负责具体的任务执行。各节点本身无状态，横向扩展性很好。

buildbot架构

安装

pip安装

建议使用pip安装，避免麻烦的依赖问题。
同时当前对python3版本支持不太好，建议使用python2.7版本：

yum install gcc python-devel 
yum install python-dateutil15 git expect
# master安装
pip install buildbot
# salve安装
pip install buildbot-slave

如果是python2.6的话，因为最新版本的Twisted需要python2.7，所以需要提前指定版本安装：

pip install Twisted==15.1.0

为充分利用资源，同一台机器可配置为多个master、slave：可使用不同用户或virtualenv，每个用户或virtualenv环境部署为一个节点。

pip install virtualenv

docker安装

最近看到buildbot官方给出了Dockerfile(但Dockerfile地址是错的，可以自行在github代码中查找)，可下载后自行构建镜像使用，运行后即可使用：

# Download Buildbot Dockerfile.
wget https://raw.githubusercontent.com/buildbot/buildbot/master/master/Dockerfile

# Build the Buildbot container (it will take a few minutes to download packages)
docker build -t buildbot - < Dockerfile

# Run buildbot
CONTAINER_ID=$(docker run -d -p 8010:8010 -p 22 buildbot)

然后打开http://localhost:8010即可。

创建及运行

master

# 创建
buildbot create-master master
# 配置文件
mv master/master.cfg.sample master/master.cfg
# 运行
buildbot start master
# 查看日志
tail -f master/twistd.log

buildbot会在当前目录下创建master名称的目录，以上为master。
看到最后显示BuildMaster is running即为启动成功，此时可通过http://localhost:8010访问，默认用户名密码都是pyflakes。

slave

创建slave时需要指定mater的地址，或者修改配置文件指定。

# 创建
buildslave create-slave slave1 localhost:9989 slave1 pass
# 运行
buildslave start slave
# 查看日志
tail -f slave/twistd.log

create-slave的参数分布是：slave目录、master、名字、密码。其中master默认都采用9989与slave通信。名字、密码必须与master的master.cfg中配置的一致：

c['slaves'] = [buildslave.BuildSlave("example-slave", "pass")]

预览

此时打开http://localhost:8010即可看到如下页面：
buildbot预览
其中Buildslaves页面可查看到我们新添加的example-slave，且状态为Idle。
而Waterfall页面可查看到当前的builder，目前只有runtest，点进去点击forcebuild即可进行测试build。成功后记录显示为绿色。

配置

Buildbot的配置文件为.cfg后缀的python脚本，使用python语法。如上文slave的定义就是一个python list的定义。

master配置

主要配置如下。

BUILDSLAVES
slave的定义，以list的形式呈现。需要主要名字和密码与slave一致。
其中protocols可定义与slave的通信方式，包括端口等。

CHANGESOURCES
指定需要监控的源代码地址。格式如下，其中可指定git地址、工作目录、分支、监控周期等。可定义多个，每个append进list即可。

c['change_source'] = []
c['change_source'].append(changes.GitPoller(
        'git://github.com/buildbot/pyflakes.git',
        workdir='gitpoller-workdir', branch='master',
        pollinterval=300))

SCHEDULERS
scheduler指定何时、如何触发执行builder，其中builder在BUILDERS中定义。下文定义了两个scheduler：

c['schedulers'] = []
# 定义每小时运行的scheduler
hourlyscheduler = Periodic(name = "hourly",
                           builderNames = ["simplebuild"],
                           periodicBuildTimer = 3600)
# 定义手动触发的scheduler
c['schedulers'].append(schedulers.ForceScheduler(
                            name="force",
                            builderNames=["master"]))

BUILDERS
builder定义具体执行的任务内容，由一系列的步骤组成。每个步骤定义在step中，factory包含一系列的step，builder通过指定factory等参数创建。可定义多个builder。
代码如下：

# 定义factory
factory = util.BuildFactory()
# 定义具体step
factory.addStep(steps.Git(repourl='git://github.com/buildbot/pyflakes.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "pyflakes"]))
# 创建builder
c['builders'] = []
# 指定名称、使用的slave、factory
c['builders'].append(
    util.BuilderConfig(name="master",
      slavenames=["master"],
      factory=factory))

STATUS TARGETS
此处定义buildbot对外通知build信息的方式。最基本的方式就是显示在页面中，因此此处同时定义了页面的认证方式，即登录使用的用户名、密码在此处修改。同时可定义IRC、邮件等通知方式。
PROJECT IDENTITY
此处主要为buildbot的基本信息，如title、超链接、url等。
DB URL
此处定义使用的数据库，默认使用sqlite，地址为本地文件路径。

配置slave

slave的定义主要在buildbot.tac文件中，可用于定义使用的master及slave基本信息。

启动及使用

基本命令

启动
master、slave的启动上文已提及，子命令为start，参数为路径。
停止、重启
stop和restart，其余同start
master重新加载配置
buildbot reconfig master即可重新加载配置。

使用方法

平时比较常用手动触发build，即forcebuild：web页面登录->Builders->选择builder->Force Build->在Waterfall查看打包结果及详细日志。
buildbot waterfall
注意：只有登录后才有build权限。

各页面介绍

Buildbot比较方便的一点是全部通过页面来进行操作。主要页面介绍如下：

Waterfall，以瀑布流的方式显示build任务，可点击任务查看详情、执行操作等
Grid/T-Grid，以对应的方式显示build任务
Console，还在开发中，当前主要显示revision信息
Builders，定义的所有builder
Recent Builds，最近的build
Buildslaves，定义的所有slave
Changesources，定义的所有代码仓库
JSON API，对外提供的JSON API文档

高级使用

多分支build

定义一个Changesource。
定义多个schedulers，分别对应不同分支。
定义多个factory，其中的step除branch不同外，其余step通用。通用的step可一次定义，多次使用。
builder分别指定分支和factory。

多项目build

新版本可使用此功能，但不太推荐。buildbot的一个master还是更多的擅长对一个项目的管理。
需要定义多个Changesource，然后在其它定义时通过project和repository参数指定项目。

错误检测

通过检查step的返回结果判断是否执行成功，规则同shell：0为成功，其它失败。
因此如果step中调用了自己的脚本，需要保证按上述规则返回结果。

添加参数

使用util.Property获得网页上指定的参数，可设置默认值：

factory.addStep(steps.ShellCommand(command=["bash", "autorpm.sh", util.Property('project', default='')]))

在build页面通过name/value指定，如：
buildbot指定参数

umask

实际使用中发现，buildslave所创建的文件，权限都为600或700。
这样会造成如cp到apache目录时，apache无法读取文件。
通过官方文档查看到slave启动时有umask选项：

–umask
This is a string (generally an octal representation of an integer) which will cause the buildslave process’ umask value to be set shortly after initialization.
The twistddaemonization utility forces the umask to 077 at startup (which means that all files created by the buildslave or its child processes will be unreadable by any user other than the buildslave account).
If you want build products to be readable by other accounts, you can add –umask=022 to tell the buildslave to fix the umask after twistd clobbers it.
If you want build products to be writable by other accounts too, use –umask=000, but this is likely to be a security problem.

通过修改slave目录下的buildbot.tac，修改：

umask = 022

然后重启slave解决此问题:

buildbot stop slave1
buildbot stop slave2

架构

安装