BuildBot

什么是Buildbot

Buildbot是一个持续集成和自动化测试框架，我在毕业刚进VMware不久的一个和以色列人合作的项目中接触到Buildbot，当时我真的恨死它了。。。经常随意的提交了一些代码后，Buildbot就开始勤勤恳恳的把所有的代码下载下来然后跑各种测试，跑完后出现错误还会自动发E-mail给我，和我的上级！！！特别是当时和以色列人合作，好几次下班前提交了代码后我就回家了（好吧，我没耐心等那么多测试跑完啊，总是要跑半个多小时，而且那时候做事很急躁），然后Break Build了。等我第二天开开心心来到公司，看到一堆以色列人询问的邮件（因为时差，我们下班了他们才开始上班）。当时真的脸比猴屁股还红。。。

现在当我自己出来做事时，才真的重新爱上了它。自动化测试和持续集成真是太重要了，时过境迁，我变成了那个挥着Buildbot的小皮鞭的恶人了。。

Buildbot能做什么？

一个常见的场景是用BuildBot绑定到你所使用的VCS，比如Git仓库。然后当有人提交了Code change时，会触发BuildBot去拉下最新的code，然后Compile, Build，再跑你定义的一系列tests。最酷的是BuildBot自带了一个HTML的Web Report功能，其中的Waterfall会以瀑布流的形式向你展示所有的任务，如果有错误发生可以直接查看相关的各种信息，非常直观好用，谁是背后的凶手一目了然。。。

Buildbot基本结构

BuildBot的常用架构是一个Master和一堆Slave，Master负责对接VCS，然后管理调度各个Slave各司其职，收集Slave传回来的数据并且整理成报告。Slave负责按照Master发过来的命令跑各种任务，并将环境信息，结果，log文件等收集起来报告给Master。

• master
  master就是Buildbot的核心，我们使用Buildbot所需要做的各种工作也是在Master上进行。
  Buildbot的使用方式就是在Master上编辑master.cfg文件，这其实是一个Python文件。使用者在里面定义对接的VCS，Schedule和Build的各种条件以及具体的Build任务，结果的收集报告方式等。
• slave
  当slave连接到master后就会不断跟master进行通信。当有任务时，master会将命令逐个发送给slave执行。

一个Buildbot例子

现在我们来搭一个最简单的Buildbot实例，我手头用的操作系统是ubuntu12.04, python3.5。
首先，用virtualenv做了一个环境（不打算用virtualenv的人可以直接跳过这些步骤)

mkdir -p tmp/buildbotcd tmp/buildbotvirtualenv --no-site-packages sandboxsource sandbox/bin/activate

然后我们安装buildbot:

easy_install sqlalchemy==0.7.10easy_install buildbot

安装成功后，我们先创建master，并且就使用默认的master.cfg文件

buildbot create-master mastermv master/master.cfg.sample master/master.cfg

这时候你会看到当前目录里多了一个master文件夹。接下来我们创建slave

easy_install buildbot-slavebuildslave create-slave slave localhost:9989 example-slave pass

现在当前目录里又多了一个slave文件夹，最后我们启动master和slave

buildbot start masterbuildslave start slave

接下来你就可以在http://localhost:8010/看到Buildbot页面了，点击页面上的waterfall，或者访问http://localhost:8010/waterfall就可以看到瀑布流界面。

Buildbot详细说明

虽然刚刚跑通了一个例子（很有可能大部分人还没有跑通。。。），我们还是云里雾里。到底发生了什么？
这里的关键就是master.cfg文件，Buildbot的使用其实就是编辑master.cfg文件。它里面其实是python代码，跑完这个文件会得到BuildmasterConfig对象，就是这个对象最后会指导master完成各种任务。这个文件的一开头就会新建这个对象，然后不断往里面添加各种属性。

c = BuildmasterConfig = {}

接下来我们了解下这个对象涉及到的比较重要的类和他们的作用。

change

change是Buildbot用来跟踪VCS，获取代码变动信息的类。Buildbot针对常见的VCS提供了很多子类供使用调用。比如定期从Git仓库检查代码状况的GitPoller，举个栗子:

c['change_source'] = []c['change_source'].append(changes.GitPoller(        'https://url.git',        workdir='', branch='master',        pollinterval=300))

这段代码就是添加了一个每300秒去检测一下url.git是否有改动的changes。

scheduler

注意，并不是有了change就一定会触发Buildbot去做任务，也不是没有change时Buildbot就不会做任何事。Buildbot的运行其实是scheduler来决定的。Buildbot同样提供了很多种scheduler，比如SingleBranchScheduler是用来在收到changes发生时触发任务的，ForceScheduler是用来供使用人员通过Web页面点击按钮强制触发任务的，Periodic是用来固定时间频率触发任务的，同样举个栗子:

c['schedulers'].append(schedulers.SingleBranchScheduler(                            name="all",                            change_filter=util.ChangeFilter(branch='master'),                            treeStableTimer=None,                            builderNames=["runtests"]))c['schedulers'].append(schedulers.ForceScheduler(                            name="force",                            builderNames=["runtests"]))

这段代码的作用就是添加了两个scheduler，分别在发现master分支有code changes时和收到强制触发命令时触发名为"runtests"的builder，这就引出下一个概念builder。

builder

builders就是负责具体指挥执行Buildbot任务的单位，builder里绑定了它将会使唤的slave和它需要执行的一系列命令。当builder被scheduler触发时，它就会通过tcp去通知响应的slave，督促它们开始做事。下面是master.cfg中注册builder的代码。

c['builders'].append(      util.BuilderConfig(name="runtests",      slavenames=["exchange"],      factory=factory))

这个builder将会指挥名为“exchange”的slave，然后执行通过factory生成的步骤。那么factory又是什么？

factory

factory就是告诉builder需要指挥slave做什么的类，我们很大一部分开发量就是在写factory，这里面是我们使用Buildbot的核心业务逻辑所在。

factory通过addStep的方式来添加执行命令，如下面的例子：

factory.addStep(steps.Git(        repourl="https://url.git"        , mode='full'        , method='clobber'        , descriptionDone='code checkout'))factory.addStep(steps.ShellCommand(        command=['npm', 'install']        , descriptionDone="npm install"))

这个例子生成的factory就会告诉对应builder指挥的slave，你先用Git拉下url.git仓库，然后调用命令npm install。
Buildbot提供了大量的命令，详细请参考链接 。

slaves

这里还有一个环节没打通，slave是怎么连接上master的？
要做到这一点，首先我们需要在master.cfg里配置slaves:

c['slaves'] = [buildslave.BuildSlave("exchange", "exchange")]

这里我们配置了一个名字叫exchange的slave，然后它的密码也是exchange。这样如果有exchange来连接master，说自己叫"exchange"，然后密码也对上的时候，master就会认了这个slave（认领slave还需要密码呀。。。)。
那么slave怎么连接master?首先，在master.cfg里我们配置master的监听端口:

c['protocols'] = {'pb': {'port': 9989}}

然后各位还记得我们在新建slave时调用的命令么？

buildslave create-slave slave localhost:9989 example-slave pass

明白了么？这个slave启动后就会去连接localhost:9989，同时它会告诉master自己名字叫"example-slave"，密码是"pass"。恩，这个slave如果连我们上述设置的master，master是不会要它的。因为我们没注册这么一个slave。。。

status

最后还有一个概念是status，也就是master如何输出当前报告。默认的master.cfg里配置了一个WebStatus，所以我们才会看到http://localhost:8010会有一个Web页面。

c['status'].append(html.WebStatus(http_port=8010, authz=authz_cfg))