使用 Buildot 实现持续集成

　　持续集成(CI)是发扬以下原则个软件Software开发流程:

　　维护单源存储库

　　自动化构建过程

　　实现自测试构建

　　每个人每天都有贡献

　　每份贡献都应用于在个集成机上构建主线

　　加快构建过程

　　在个相同生产环境中执行测试

　　使任何人都可以简单获取最新可执行文件

　　每个人都可以看到当前状况

　　自动化部署

　　经 Martin Fowler 大力普及CI 基本理念就是持续测试并构建每个分支和将分支代码合并后软件Software这可以从总体上提高代码库健康状况还可以增加和团队(Team)成员交流并有机会获取对代码整体质量反馈人们通常使用这个周期来生成代码覆盖报告和其他统计信息

　　Buildbot 类似于其他 CI 系统有助于自动化这个检查、构建和测试流程Buildbot slaves 通常运行于区别平台比如 Win32、Solaris、Intelx64 等当个构建(build)中断时Buildbot 可以发送个电子邮件通知它追踪所有运行中构建这样开发人员就可以鸟瞰整个流程最后人们常常利用自动化周期构建既定时间内软件Software质量度量标准本文结尾将谈及该度量标准以及在个 CI 系统内运行它们原因

　　Buildbot 介绍

　　在我们深入探讨 Buildbot 的前先看下其架构如图 1 所示在构建流程顶部主要有 3个层首先是个版本控制层它从个版本控制系统钩入通知其次是个构建层它从构建主服务器那里获取通信并返回构建结果最后是个通知层用于在构建失败时发送电子邮件或个 IRC 消息或让个 web 页面显示构建累积结果

图 1. Buildbot 架构概览


　　查看原图(大图)

　　Buildbot 架构中心特性的是对基于 Python Twisted 库依赖性用于处理主服务器(master)和伺服机(slave)的间异步通信这个基于回调架构支持个很简单、但健壮主/伺服反馈圈

　　如果您尚未听说过 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 主服务器快速运转起来

　　5 分钟内设置 Buildbot

　　我在 Ubuntu 8.10 上执行了这几步不过它们应该在大部分 Linux 系统上都适用:

　　下载 ez_up.py:
wget http://peak.telecommunity.com/dist/ez_up.py

　　安装 easy_:
sudo python ez_up.py

　　使用 apt-get 安装 Python Twisted 包
sudo apt-get python-Twisted

　　遵循这个 collective.buildbot “秘诀”:
sudo easy_ collective.buildbot

　　此时许多东西开始涌出 shell有大堆包被下载且得到自动安装完成这些步骤的后就可以开始创建 Buildbot 了！如果安装过程进行得很顺利在 shell 提示符处输入:

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

　　现在设置已经快完成了但在完成的前我要提几个在首次配置 Buildbot 时您容易出错地方在您 my.project/master.cfg 文件中应该可以看到以下内容:

清单 1. master.cfg 内容

[buildout]　
master-parts　=　
　　master　
　　passing.project　
#　uncomment　this　to　enable　polling　
　　poller　
　
[master]　
recipe　=　collective.buildbot:master　
project-name　=　passing.project　project　
　
#　allow　to　force　build　with　the　web　erface　
allow-force　=　true　
　
#　ernal　port　
port　=　9051　
　
#　http　port　
wport　=　9081　
　
#　buildbot　url.　change　this　　you　use　a　virtualhost　
url　=　http://localhost:9081/　
　
#　　files　
public-html　=　${buildout:directory}/public_html　
　
slaves　=　
　　localhost　NaOaPSWb　
　
[passing.project]　
recipe　=　collective.buildbot:project　
slave-names　=　localhost　
vcs　=　hg　
repositories　=　/home/ngt/myhgrepo　
　
#　notications　
mail-host　=　localhost　
email-notication-sender　=　buildbot@cortese　
email-notication-recipient　=　
　　[email protected]　
　
#　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.cfg　
　
　
test-sequence　=　
　　noests　
#　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/ngt/myhgrepo　
#user　=　h4x0r　
#password　=　passwd　
poll-erval　=　120　

　　最初检查最重要内容是确保有合适源控制存储库开始将 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/ngt/my.project　
Installing　uptools............done.　
[output　suppressed　for　space]　

　　该命令结束的后您就完成了 Buildbot 安装现在就可以使用它了运行以下 shell 命令启动 Buildbot 守护进程:

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

　　如果您在浏览器中输入在主 .cfg 文件中设置 URL默认情况下为 http://localhost:9081/您会看到全新 Buildbot当然它现在可能还没有多少功能如果您为它提供个构建脚本和个测试运行它会很乐意检查、构建并自动测试您代码当然您稍后应当浏览些配置选项但最难部分已经完成了

　　生成代码度量报告

　　“测试迷” 中个最新智能开发是要利用持续集成周期来生成有关源代码度量其中种最流行思路方法是运行带既定选项 noest 测试收集器如果您有个名为 “foo” 项目您通常会运行:

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

　　这会生成个 HTML 报告显示未涉及所有代码行以及类似于清单 3 stdout 输出:

清单 3. noest 输出

nglep%　noests　--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.004s　
　
OK　

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

　　每次修改代码后都运行这个报告为开发人员和管理人员提供有关代码变化元数据这是展示为何同时运行度量标准个绝佳例子 CI 对个项目有好处

　　另个提供代码元数据度量工具是 PyMetrics McCabe 评定早在20 世纪 70 年代Thomas McCabe 就提出个简单、但独创性代码观察结论:段代码越复杂它中断可能性就越大这虽然看起来很明显但遗憾是很多开发人员似乎看不到其中联系使用 PyMetrics 命令行工具您可以确定每个分支数

　　通常您希望将编写每个思路方法或分支数保持在 10 以下在人脑中保留 7 或 8 份内容很难类似大于 50 段代码基本上是无法测试/无法维护

　　我就亲眼看到过 140 多段代码代码很差它确实验证了 McCabe 理论如果您可以在开发前期捕获和标记这个复杂、脆弱代码那么即使所有测试都通过它也不会出现在生产环境中

　　结束语

　　持续集成主要优势是能够通过软件Software自动化构建以及测试和软件Software度量标准(可选)精简品质保证周期每次更改源代码并为项目生命期提供即时反馈和报告时都会触发构建当 CI 得到正确配置时它实际上就集成到代码生成过程中如同亲自参和编写代码样



　　Buildbot 并非用于 CI 测试惟工具您也可以了解下 Hudson 和 Bitten它们都支持使用 Python 插件进行定制即使 Hudson 是用 Python 编写参阅以下参考资料详细了解这些系统相关内容



　　本文举例源代码或素材下载

延伸阅读