buildbot_与Buildbot持续集成

buildbot

持续集成（CI）是一种软件开发过程，可促进以下原则：

维护单一来源存储库
自动化构建
使您的构建自测
每个人每天都承诺
每次提交都应在集成计算机上构建主线
保持快速构建
在生产环境的克隆中进行测试
使任何人都能轻松获得最新的可执行文件
每个人都可以看到发生了什么
自动化部署

CI是Martin Fowler广泛推广的，其基本思想是在每个分支以及将代码合并到主干中时不断地测试和构建您的软件。这导致代码库的运行状况总体上得到提高。它还可能导致与团队成员的交流增加，并有机会获得有关代码整体质量的反馈。人们经常使用此循环来生成代码覆盖率报告和其他统计信息。

像其他CI系统一样，Buildbot有助于自动执行此结帐，构建，测试周期。 Buildbot 从站通常运行在不同的平台上，例如Win32，Solaris，Intelx64等。Buildbot可以在构建中断时发送电子邮件通知，并且它可以跟踪所有正在运行的构建，因此开发人员可以鸟瞰整个过程。最后，人们经常进入自动周期以在任何给定时间生成有关其软件质量的指标。本文的结尾谈到了指标以及在CI系统中运行它们的合理性。

Buildbot简介

在深入了解Buildbot之前，让我们看一下体系结构。如图1所示，在构建过程的顶部基本上有三层。有一个版本控制层，它挂接到来自版本控制系统的通知中。有一个构建层，它接受来自构建主机的通信并返回构建结果。最后，有一个通知层，通常将其配置为在构建失败时发送电子邮件或IRC消息，或使网页随时间推移显示收集的构建结果。

图1. Buildbot架构概述

Buildbot体系结构的其他主要功能之一是依靠基于Python的Twisted库来处理主从服务器之间的异步通信。这种基于回调的体系结构允许一个非常简单但健壮的主/从反馈循环。在本文后面的“ 相关主题”部分中找到有关Twisted的更多详细信息。

如果您还没有听说Buildbot，那么一些Google搜索将揭示与大型和小型开源项目相关的大量主从。从属设备（我之前已简要提及）实际上是由Buildbot主服务器控制的从属计算机。通常，从站是每个运行不同测试平台的许多从站之一。这是Buildbot服务器世界中的重要概念。例如，您可能在一个开源项目的邮件列表中，并且听到有人说：“有人愿意为Windows从属自愿提供虚拟机吗？”

Python语言项目本身使用大量Buildbot从站，以在尽可能多的平台上连续构建和测试Python的最新版本。图2显示了运行这些Python主干的这些从属构建的各种机器以及测试。随着虚拟化技术的最新发展，现在很常见的是，要求您的开发社区的成员托管Buildbot从属服务器，或者简单地运行多个模拟不同硬件配置的虚拟机。

图2. Python Buildbot

Buildbot的另一个引人注目的用户是Google Chrome浏览器项目。图3显示了高度定制的Buildbot版本，该版本显着增强了Buildbot用户界面的外观。幸运的是，Google将这些增强功能开源到Buildbot，并且可以从下面的“ 相关主题”部分中获取源代码并构建此自定义版本。

图3. Google Chrome增强的Buildbot

构建此特定配置不在本文讨论范围之内，但是我建议您自己看看。现在，让我们快速运行Buildbot主服务器。

在五分钟内设置Buildbot

我在Ubuntu 8.10上运行了以下步骤，但它们应在大多数Linux发行版上都可以使用：

下载ez_setup.py：
wget http://peak.telecommunity.com/dist/ez_setup.py
安装easy_install：
sudo python ez_setup.py
使用apt-get安装Python Twisted软件包：
sudo apt-get install python-Twisted
请遵循以下collection.buildbot“配方”：
sudo easy_install collective.buildbot

此时，随着一堆软件包自动下载并安装，很多东西将开始涌出外壳。完成后，您就可以创建Buildbot了！如果安装正确，请在shell提示符下键入：

$ paster create -t buildbot my.project $ cd my.project

确实，您已经快完成了，但是在完成之前，让我指出几个可能会在您首次配置Buildbot时使您绊倒的陷阱。在my.project / master.cfg文件中，您应该看到类似以下内容：

清单1. master.cfg的内容

[buildout]
master-parts =masterpassing.project
# uncomment this to enable pollingpoller[master]
recipe = collective.buildbot:master
project-name = passing.project project# allow to force build with the web interface
allow-force = true# internal port
port = 9051# http port
wport = 9081# buildbot url. change this if you use a virtualhost
url = http://localhost:9081/# static files
public-html = ${buildout:directory}/public_htmlslaves =localhost NaOaPSWb[passing.project]
recipe = collective.buildbot:project
slave-names = localhost
vcs = hg
repositories = /home/ngift/myhgrepo# notifications
mail-host = localhost
email-notification-sender = buildbot@cortese
email-notification-recipient =super@example.com# run test each hour
periodic-scheduler=60# cron build
cron-scheduler = 0 8 * * *# You can change the sequences to build / test your app
# default options should work for most buildout based projects
build-sequence =
#    /usr/bin/python2.5 bootstrap.py -c project.cfg
#    /usr/bin/python2.5 bin/buildout -c project.cfgtest-sequence =nosetests
# zope.testing require exit with status
#    bin/test --exit-with-status[poller]
recipe = collective.buildbot:poller
# don't forget to check this
# since it's generated from the paster template it may be a wrong url
repositories = /home/ngift/myhgrepo
#user = h4x0r
#password = passwd
poll-interval = 120

最初要检查的最重要的事情是您具有正确的源代码控制存储库，首先将build-sequence留build-sequence空白，并且在代码签出后， test-sequence （在我的情况下为“ nose”）将通过测试您给它的存储库。看看在collective.buildbot的资源指南，如果您有任何其他问题（请参阅相关信息中的链接）。

设置好配置文件后，您只需运行以下两个命令：

$ python bootstrap.py $ ./bin/buildout

当运行buildout命令时，您将获得很多类似以下的输出：

清单2. buildout命令的输出

{673} > ./bin/buildout
Unused options for buildout: 'master-parts'.
Installing master.
New python executable in /home/ngift/my.project
Installing setuptools............done.
[output suppressed for space]

该命令完成后，您就完成了Buildbot的安装，并准备好启动了。通过从外壳运行以下命令来启动两个Buildbot守护程序：

$ ./bin/master start $ ./bin/yourhostname start

然后，如果将浏览器指向在master.cfg文件中设置的URL（默认情况下为http：// localhost：9081 /），则会看到新的Buildbot。当然，它可能不会做很多事情。如果您给它一个构建脚本和一个测试运行器，它将很乐意签出您的代码，构建代码，然后自动对其进行测试。当然，您以后应该浏览一些配置选项，但是辛苦的工作基本上已经完成。

生成代码指标报告

“测试书呆子”中最近的一项智力发展是利用连续集成周期来生成有关源代码的度量。最受欢迎的技术之一是运行带有coverage选项的鼻子测试测试收集器。如果您有一个名为“ foo”的项目，则通常将运行：

nosetests --with-coverage --cover-package=example --cover-html \ --cover-html-dir=example_report.html test_example.py

这将生成一个HTML报告，该报告显示所有未涵盖的代码行，以及对stdout的输出，如下所示：

清单3.鼻子测试的输出

nglep% nosetests --with-coverage --cover-package=example--cover-html-dir=example_report.html test_example.py
.
Name      Stmts   Exec  Cover   Missing
---------------------------------------
example       2      2   100%
----------------------------------------------------------------------
Ran 1 test in 0.004sOK

您可以从“ 下载”部分下载example.py和test_example.py。

每次修订代码时运行此报告，将为开发人员和经理提供有关代码中实际发生的情况的元数据。这是为什么与CI同时运行指标对项目有利的一个完美示例。

提供有关您的代码元数据的另一个度量工具是PyMetrics的McCabe评级。早在1970年代，Thomas McCabe就对代码提出了一个简单而巧妙的观察方法：一段代码越复杂，破坏代码的频率就越高。尽管这看起来似乎很明显，但不幸的是，许多开发人员似乎看不到这种联系。通过使用PyMetrics命令行工具，您可以确定每个函数的分支总数。

通常，您要为每个编写的方法或函数将分支数保持在少于10个，因为很难在人脑中随时在上下文中保留七个或八个以上的事物。作为参考，得分高于50的代码基本上是无法测试/无法维护的。

我个人认为代码在生产中的得分高达140，而且代码相当糟糕，因此它确实验证了McCabe的理论。如果您可以在开发过程的早期阶段捕获并标记这个复杂，易碎的代码，那么即使所有测试都通过了，它也不会潜入产品中。

结论

持续集成的主要好处是能够通过自动构建软件，测试以及可选的软件指标来简化质量保证周期。这些构建会在每次更改源时触发，并提供即时反馈以及项目生命周期的报告。正确配置CI后，它实际上已集成到编写代码的过程中，就像编写代码本身一样。

Buildbot不是市面上唯一用于CI测试的游戏。您也可以看看哈德森和比滕。尽管Hudson是用Python编写的，但每一个都允许使用Python中的插件进行自定义。有关这些系统的更多信息，请参考下面的资源。

翻译自: https://www.ibm.com/developerworks/opensource/library/l-buildbot/index.html

buildbot