buildbot三：配置

单元测试，是每一个优秀的程序员都必须做的事情，写完代码不做测试，是不专业的行为，但是测试也是有成本的，你写了100个单元测试的脚本，那么当你写完并测试通过第101个，你怎么保证前100个也都是可以测试通过的呢？

要知道，从你写第一个单元测试脚本到你写101个，这中间很多代码都改变了，不只是你一个人在维护一个项目，其他人的代码改动也许已经使得你之前的单元测试脚本无法通过测试，也就是说项目里已经存在bug，只是眼下还很隐蔽，没有被发现。

将之前的100个单元测试脚本都运行一遍是很耗费时间的，如果能有一个框架，自动的来完成这些操作就好了。

现在很流行使用git，平时开发，会拉一个分支，这个分支开发结束后，就会合并到master上，OK，就是在这个时候，有必要将项目过去积累的所有单元测试都测试一遍，来保证，新的分支在合并后没有影响到之前的功能。

于是，持续集成和自动化测试框架出现了。

一、Buildbot-worker配置：

Buildbot-worker基本不需要配置，其目录下存储的是配置信息、日志以及在本地构建的仓库。

buildbot.tac存储有创建Worker时的信息，包括name，master地址等，此外还有一些默认的信息，如端口等。

info目录下有2个文件：admin和host，它们会显示在web端的worker信息栏中，至于它们的作用，看名字就知道了。

如果你已经在该worker上构建过项目，则会发现一个名字和相关builder相同的目录，里面就是下载到本地的仓库。

二、Buildbot-master配置示例一：

BuildMaster的配置在文件master.cfg中，整个配置文件就是一个map，配置文件对其的命名为c。

1.配置Worker：只需要找到c['workers']，在内部构造Worker即可，示例如下：

c['workers'] = [
    #worker.Worker("NAME", "PASSWD")
    worker.Worker("Debian-i386", "123456", properties={'os':'debian', 'arch':'i386'}),
    worker.Worker("Debian-amd64", "123456", properties={'os':'debian', 'arch':'amd64'}),
    worker.Worker("FreeBSD-i386", "123456", properties={'os':'freebsd', 'arch':'i386'}),
    worker.Worker("FreeBSD-amd64", "123456", properties={'os':'freebsd', 'arch':'amd64'})
]

这里的NAME和PASSWD，必须与创建Buildbot-worker时填写的一致，properties可以有选择地填写。

完成这一步，就意味着整个框架内部已经有几个对应的Worker了，然后我们需要为这些Worker编组，分配给对应的Builder，记住之前所说的，一般一个平台对应一个Builder。

2.change_source配置：

change_source就是来配置变更源的，buildbot会监视这个变更源，一旦这里的代码出现了变化，那么就会发布构建代码并进行测试的任务，而woker在收到任务后就可以进行程序构建和测试了，这样，无需开发人员介入，测试就这样完成了，想想真是太方便了。

配置示例：

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

这里有3个要关注的地方

（1）git://github.com/kwsy/myexcel.git 我给的例子是我自己的项目，你要换成你自己的

（2）branch 要指定监听的分支，我这里监听mster，这样，每一次master上的代码有变化时，buildbot都会知道

（3）pollinterval 我设置成10，表示每隔10秒，buildbot就会去检查项目的master是否有变化

3.schedulers：

这块是配置调度器的，当变更源发生变化时，buildbot将根据这里的配置来决定如何去进行集成和测试

调度有三种方式

（1） SingleBranchScheduler 当变更源发生变化时，执行触发任务。即用于特定分支的构建，也就是说当发现仓库变动时，只有分支匹配才会执行构建。

（2） ForceScheduler 接受开发人员通过web界面触发执行任务。即用于在Worker页面上添加一个按钮，使用户可以手动进行构建，这在测试时很有用。

（3） Periodic 以固定时间频率触发执行任务

c['schedulers'] = []
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"]))

示例二：

run_all = ["run-linux-32", "run-linux-64", "run-freebsd-32", "run-freebsd-64"]
c['schedulers'] = [
    schedulers.SingleBranchScheduler(name="all", 
change_filter=util.ChangeFilter(branch='master'),
        treeStableTime=None, builderNames=run_all),
    schedulers.ForceScheduler(name="force", 
builderNames=run_all, buttonName="Build")
]

treeStableTime表示在仓库变动事件触发后，若在指定时间内没有出现新的变动，则执行构建，否则重置计时器。buttonName则表示显示在Worker页面的按钮的名字。

4 builders：

这里是用来配置指定任务的builder的地方

找到c['builders']，在其内部配置Builder的信息：

c['builders'] = [
    util.BuilderConfig(name="run-linux-32", workernames=["Debian-i386"], factory=factory),
    util.BuilderConfig(name="run-linux-64", workernames=["Debian-amd64"], factory=factory),
    util.BuilderConfig(name="run-freebsd-32", workernames=["FreeBSD-i386"], factory=factory),
    util.BuilderConfig(name="run-freebsd-64", workernames=["FreeBSD-amd64"], factory=factory)
]

这里的factory表示具体的构建步骤，具体配置下文阐述，由于这里在所有平台上执行相同的操作，因此使用同一个factory即可。至此，我们就已经将Worker和Builder关联了，剩下的则是关联Scheduler和Builder，以使其能够在恰当时机向Builder发送构建请求。

5.Build-step：

接下来，我们需要做的就是定制构建过程，也就是Build-step，找到之前的那个factory，它是一个工厂，也就是说在每次构建中，均会创建一个Build实例，我们要做的就是向这个工厂不断添加中间步骤(addStep)。

这里的用例比较简单，详细步骤如下：

git pull
cmake
make
bin/TestMain

因此这里只需要借助内置的ShellCommand类即可，大致如下：

factory = util.BuildFactory()
factory.addStep(steps.Git(repourl="xxxxxxxx", mode="incremental"))
factory.addStep(steps.ShellCommand(command=['cmake', '.']))
factory.addStep(steps.ShellCommand(command=['make']))
factory.addStep(steps.ShellCommand(command=['bin/TestMain']))

注意command数组表示执行的命令及其参数，可别填错了。

builder、build-step示例二：

factory = util.BuildFactory()
# check out the source
factory.addStep(steps.Git(repourl='git://github.com/kwsy/myexcel.git', mode='incremental'))
# run the tests (note that this will require that 'trial' is installed)
factory.addStep(steps.ShellCommand(command=["trial", "exceldemo/test_excel.py"],
                                   env={"PYTHONPATH": "."}))

c['builders'] = []
c['builders'].append(
    util.BuilderConfig(name="runtests",
      workernames=["example-worker"],
      factory=factory))

factory.addStep，是用来添加执行步骤的，要想进行自动化测试，就得明确的告诉buildbot，去哪里进行测试，注意看repourl ，测试前，worker已经将git代码获取到本地。exceldemo/test_excel.py 是我用unitest 写的一个单元测试脚本，这行代码相当于在进行 trial exceldemo/test_excel.py 这个操作

创建worker的时候，example-worker，所以，这里builders加入这个worker，这个woker将会执行factory里添加的两个操作

6.services

这里可以配置一系列的服务，下面给出的是一个发送邮件的服务，自动化构建测试完成后，它可以发送邮件到指定的邮箱当中

mn = reporters.MailNotifier(fromaddr="xigongda200608@163.com",
                            sendToInterestedUsers=False,
                            extraRecipients=["这里配置你希望接收集成测试报告的email"],
                            relayhost="smtp.163.com", smtpPort=25,
                            smtpUser="xigongda200608@163.com",
                            smtpPassword="password")
c['services'] = [mn]

7.更新配置文件：

buildbot reconfig master

参考：http://www.zhangdongshengtech.com/article-detials/218

posted on 2019-06-28 17:38 myworldworld 阅读(555) 评论(0) 收藏举报

刷新页面返回顶部

myworldworld