部门的持续集成一直做的不太好，我们开发部这边甚至一直没能做起来，这其中有各种原因：工具、意识、执行力、沟通等等。将持续集成引入到我们的开发过程中也一直是我的一个目标。去年末启动的一个项目让我感到时机变得成熟了。

新项目的代码是完全重写的，这样的机会甚是难得。因为大多数情况下大家都是在维护现有系统：做些添添补补、修正Bug以及优化之类的事情。项目初期，我特别向大家强调了要严格遵守统一代码风格并将astyle代码格式化工具介绍给大家，手把手地教大家如何利用类似LCUT这样的单元测试框架编写单元测试，讲解什么是Mock测试。前些时间我又将代码风格检查
脚本加入到工程的构建过程中，并将代码风格检查作为最终构建目标的关键依赖，强制大家编写出统一风格的代码。

情况就是这样的情况，的确我们现在只做到了这些。不过有了这些基础，我就更有信心去做持续集成了。

今年年初部门统一部署了产品的多平台移植的开发任务，作为新项目，我们的成果物被要求天生就应具备适合在多个平台上运行的能力。这次产品平台移植仿佛一针催化剂加快了我在项目中实施持续集成的脚步。我希望搭建出这样一套系统：每当开发人员提交代码后，持续集成框架都能发现这些代码变动，并在多个不同平台的主机上分别Checkout出最新代码，Build，Check代码风格并运行单元测试集，最终将结果通知所有人。

我需要找到满足我这一需求的工具。记得若干年前我第一次研究持续集成时曾经研究过一款名为CruiseControl.rb的工具，不过很遗憾的是这款工具似乎早已不更新了。在Thoughtworks的官方站点上，其最后一次发布是在2年前了。另外CruiseControl.rb一个比较大的缺憾就是性能差些。另外如果想满足我在多个不同平台主机上同时运行构建以及测试的要求，似乎需要部署多套CruiseControl.rb。

在寻找工具的路上，我发现了BuildBot。这是一款由Python实现的开源持续集成工具。与CruiseControl.rb相比，其性能更好，其Master+Slaves的结构更易于扩展，并且可以很好地满足多平台版本构建的需求，大名鼎鼎的Google Chrome浏览器项目用的也是这款工具。另外我个人对Python的更加青睐也让我决定使用这款工具。

BuildBot的文档比较丰富和全面，这也使其安装过程比较简单。BuildBot由两部分组成，一部分是Master，用于监视代码库变动，控制各个Slave节点进行构建操作，并收集反馈结果以各种方式（Mail、Html等）展示给用户；另外一部分就是Slave了。每个Slave节点都承担着构建过程的具体工作：他们接收Master发过来的指令，并按指令一步一步完成构建工作，并将结果反馈给Master。

一个BuildBot持续集成环境就是由一个Master与一些Slaves组成的。其安装过程大致如下：
1、在装有Python（最好是Python 2.6.x版本）的Master主机上安装Buildbot master：下载BuildBot安装包（我用的是最新的BuildBot-0.8.3p1）。解包后，执行python setup.py build和python setup.py install安装BuildBot master包。注意install默认是需要root权限的。
2、安装BuildBot依赖包：下载最新的Twisted包（我用的是11.0.0）与zope.interface包（我用的是3.6.1），安装方法与BuildBot一致。
3、在装有Python（最好是Python 2.6.x版本）的各个Slave主机上安装BuildBot slave：下载Buildslave安装包、最新的Twisted包与zope.interface包，安装方法与BuildBot Master一致。
4、以上安装完成后，在Master host上执行buildbot，在各Slave host上运行buildslave，检查一下是否成功安装了。

安装Ok，我们就可以建立Master实例以及诸多Slave的实例了。先说说Master。在Master主机上某路径下，创建foo_ci_master目录，进入foo_ci_master目录下，执行："buildbot create-master ./"。执行后，在当前目录下会有master.cfg.sample文件。这是一个样板文件，我们将其改名为master.cfg后，打开master.cfg，开始进行master的配置。

Master的master.cfg是这套持续集成系统的核心。我们用一个简单的例子来说明这个配置。假设我们的持续集成环境由三台主机组成：Master Host（假设其ip为10.0.0.1）以及两台Slave Host，其中一台Slave Host上运行着RHEL 5.5，而另外一台Slave Host上则运行着PC Solaris 10。我们希望当有代码被提交到代码库中后，Master可及时发现这一变化，并且指挥两台Slave Host检出最新代码并且都能Build成功。

下面是master.cfg中的一些关键配置及说明(省略了一些默认配置)：

#
# master.cfg
#

c['slaves'] = [BuildSlave("x86-solaris-bot", "x86-solaris-bot-passwd"),
               BuildSlave("redhat-bot", "redhat-bot-passwd")]

这里告诉Master我们有两个Slave node，分别是x86-solaris-bot和redhat-bot，而这两个Slave登录Master的密码分别为x86-solaris-bot-passwd和redhat-bot-passwd。

我们使用subversion作为我们源码版本管理工具，所以我们采用SVNPoller来监测源码库的变化：

from buildbot.changes.svnpoller import SVNPoller
c['change_source'] = SVNPoller("svn://10.10.0.1:8888",
                                svnuser='YOUR_SVN_USER',
                                svnpasswd='YOUR_SVN_PASSWD',
                                pollinterval=30,
                                split_file=foo_split_file)

def foo_split_file(path):
        pieces = path.split('/')
        if pieces[0] == ‘foo’ and pieces[1] == 'trunk':
            return ('foo/trunk', '/'.join(pieces[2:]))
        else:
            return None

在SVNPoller的参数中split_file是比较难理解的一个。它是为下面的Scheduler提供服务的。split_file会将变更的源码文件的完整路径信息进行拆分，并返回一个(branch, relative_pathname)的元组。而Scheduler将尝试匹配元组中的branch以决定此次变更是否是自己所关心的。看下面配置代码：

c['schedulers'].append(Scheduler(name="foo-ci-plan",
                                 branch='foo/trunk',
                                 treeStableTimer=5,
                                 builderNames=["foo-redhat-builder", "foo-x86-solaris-builder"]))

显然这个Scheduler关心"foo/trunk"这个branch。一旦某源码文件归属于该分支（如svn://10.10.0.1:8888/foo/trunk/main/main.c），则该Scheduler会启动构建过程。其构建过程将通过两个builder完成，它们分别是foo-redhat-builder和foo-x86-solaris-builder。这样一来，我们就可以适当定义foo_split_file并设置多个Scheduler，以满足我们对不同branch的不同构建需要。

builder都是关联到某个builder factory的，而下面则是factory的配置：

foo_builder_factory = factory.BuildFactory()
foo_builder_factory.addStep(SVN(mode='update',
               baseURL='svn://10.10.0.1:8888/',
               defaultBranch='foo/trunk'))
foo_builder_factory.addStep(Compile(command=["make"]))

这个factory生产出来的builder会执行两个step：首先执行svn update，将svn://10.10.0.1:8888/foo/trunk更新到本地；然后执行make命令。

下面是builder的设置：

b1 = {'name': "foo-redhat-builder",
      'slavename': "redhat-bot",
      'builddir': "foo-redhat",
      'factory': foo_builder_factory,
      }

b2 = {'name': "foo-x86-solaris-builder",
      'slavename': "x86-solaris-bot",
      'builddir': "foo-x86-solaris",
      'factory': foo_builder_factory,
      }

c['builders'] = [b1, b2]

builder的设置看起来没那么难，一目了然。

BuildBot Slave的创建和配置就更加简单了。首先到那台运行着solaris系统的Slave host上，在适当目录下创建foo_ci_slave目录，进入该目录后，执行“buildslave create-slave –umask=022 ./ 10.0.0.1:9989 x86-solaris-bot x86-solaris-bot-passwd”命令，一个Slave就创建完了，实际上也配置完了，无需额外配置了。其配置文件就是foo_ci_slave下面的buildbot.tac文件。Rhel上的slave也是如此创建的。

启动Master。在Master host的foo_ci_master下面，执行buildbot start ./即可启动buildbot master，其当前日志会被输出到twistd.log中；如果要停止buildbot master，依旧是在该目录下，但执行buildbot stop ./。

启动slave。在Slave Host的foo_ci_slave下面，执行buildslave start ./即可启动buildbot slave，其当前日志会被输出到twistd.log中；如果要停止buildbot slave，依旧是在该目录下，但执行buildslave stop ./。

当Master和各个Slave都成功启动后，我们就可以来试试执行一次Build过程：修改foo/trunk下的某源码文件并提交。Master将会侦听到变更，便会启动两个Slave Host上的build过程。此次构建的结果在哪里可以看到呢？试试访问http://10.0.0.1:8010，页面上红色代表构建失败，绿色代表构建成功。

Buildbot还支持将构建结果通过Mail通知的机制，不过由于公司用的是ssl方式，我试验了许久都没能将mail发出来。不知道是不是Twisted的Mail包的实现有问题还是其他什么原因，后续会继续查证。

今天是Ubuntu 11.04版本(Natty Narwhal)发布的正日子！想必全世界的Ubuntu Fans们都会或多或少的兴奋上一阵儿。我接触Ubuntu这个Linux发行版较早，甚至可以追溯到Ubuntu 5.10。不过真正将Ubuntu作为我日常工作学习的第一操作系统还是在去年Ubuntu 10.04LTS版本发布之后。从那时起到现在整整有近一年时间了。这里我也来说说这一年来使用Ubuntu的感受。

初次使用Ubuntu的朋友可能都会被问到以下问题：

·你的Windows系统很奇怪啊，咋和我的不太一样呢？

·你用的是苹果操作系统吗？

·你为何不用Windows操作系统了呢？

·Ubuntu比Windows好在哪里呢？

实话实说，我接触Linux的初衷就是好奇。用惯了Windows，总想换个新鲜的环境。也许与我有类似想法的人会有不少。至于Windows和Ubuntu哪个更好？我倒是觉得没啥可比较的。两者诞生的背景不同、创造者集体认同的文化不同、设计思想的聚焦也不相同。非要将两者在个人电脑桌面领域分出一个高下未免有些狭隘。从全局来看，两者既是竞争对手，同时也可以相互补充。关键在于你的需求以及你对两个系统背后文化的认同。如果你只是使用过其中一种系统的话，那你就更没有发言权了。你没有深入地使用过Linux，你又怎么能体会到其背后的文化内涵呢！至于媒体上所宣传的Linux免费、病毒少以及比Windows安全等等特性，我觉得对于普通中国人来说，这些都不能构成实际的吸引力，却颇有些噱头的意思在里面，至少免费这一项在大陆是不成立的，具体原因你是懂的。

Linux是大势所趋，这里倒不是针对桌面领域，而是其全局竞争力，是指对整个IT产业的影响。前不久Linux也刚刚过完自己20周岁的生日。媒体一致认为Linux已经战胜了Windows，观点依旧片面，但不可否认的是Linux已经渗透到了整个行业的各个角落，这个是桌面老大Windows所无法比拟的。想像一下：全世界的有多少数据中心的节点上跑的是某个Linux发行版或自定制版的Linux版本，而又有多少个节点跑的是Microsoft的Windows Server呢？恐怕只有Microsoft自己的数据中心有吧。在嵌入式领域Linux更是独领风骚。

有些跑题了，我们言归正传，说Ubuntu的使用感受。如果说目前的Ubuntu在桌面领域已经超越了Windows，那肯定是谎话。实际上的情况是与桌面老大Windows相比，号称最流行的Linux桌面发行版的Ubuntu依旧有着很大差距。当然这些差距是可以理解的。毕竟Windows是在一个庞大的商业帝国下面由成千上万的精英花了十多年专职打造出来的，而Ubuntu则只是一个Linux发行版而已。按Eric S.Raymond的观点：前者是大教堂中的产物，后者则是集市中人们智慧的结晶。

在使用Ubuntu 10.04的过程中积累以下使用感受：

1、Ubuntu系统兼容性差

可以明确地告诉你：不是所有机器都可以成功安装Ubuntu的，有些时候你费了九牛二虎之力，也只能无奈的退回到以前的系统。虽然我自己没有遇到这种情况（我的机器乃是ThinkPad X60），但是耳闻目睹的失败案例倒有不少。

2、Ubuntu并没有想像中的那么稳定和可靠。 

我们在使用Windows时偶尔会遇到蓝屏，这样的场景我在Ubuntu下也时有发生。有些时候运行一些桌面应用也会导致桌面系统崩溃。

3、缺少厂商积极的驱动支持

很多Linux自带的驱动程序都不是相应设备厂商提供的，这样会导致设备性能无法发挥到最优。另外新设备的驱动无法及时提供会导致这些设备在Ubuntu下无法使用。

4、升级风险较大

这个我还是有亲身体会的。在10.04之后，我曾经多次升级过内核，从2.6.32-24到2.6.32-27再到2.6.32-30，每次升级后系统总会有些奇怪的问题发生：比如无线路由升级后频繁断连、窗口切换变得迟钝等等。虽然之前发布过10.10版本，但是我尚未敢尝试直接升级，因为社区里的很多人反映升级后系统无法启动或启动后出现各种故障或某些设备无法使用等情况。

5、残留的Bug不少

虽说Windows发行版也有诸多Bug，不过Ubuntu有一些严重的问题，比如休眠根本无法使用、启动应用程序的记录注销前会话功能无法取消等等。

6、优质桌面应用相对匮乏

现有的桌面应用的表现（性能、美观和易用性）尚无法与Windows上的一些知名应用相提并论。比如Ubuntu下的OpenOffice很是让人失望，让我不得不开始怀念起Ms Office。

到这里你也许会问：怎么都是糟糕的体验呢？那Ubuntu就没啥优点了吗？不是这样的。Ubuntu专有特性你可以参考Ubuntu官方的宣传文档。而我想说的是Ubuntu或Linux最大的优点就是其开放性以及其尚不完善的状态。开放性让你可以深入挖掘到Linux背后的任何一个细节并作出你的修改；另外正是由于其不完善，作为程序员的我们才有了用武之地，不是吗！

通过这一年来的使用，我发现Ubuntu真正进入大众生活还为时尚早，即使以后做到了，可能最终也无法达到Windows或Apple的Mac OS在个人电脑桌面领域所达到的高度。不过对于一名程序员来说，Ubuntu或任何一个其他Linux发行版却是极其适宜的，你可以按照你的想法掌控一切，不过前提是你要花费一些时间和精力去挖掘Ubuntu、挖掘Linux。

Ubuntu不是这个世界上唯一的Linux发行版。使用Ubuntu是自发的，放弃Ubuntu也是自发的。如果你不认同Ubuntu演进计划，你大可尝试一下其他发行版，比如Fedora、Arch、OpenSuse等。使用Ubuntu的人都是有一些Geek精神的，所以转到其他Linux发行版也不是什么新鲜事。