Buildbot是产品线C应用项目中采用的唯一持续集成工具，一直以来用得还不错。但前些日子部门负责过程改善的同事找到我，说今年部门计划统一各个项目组所使用的Continuous Integration工具，Buildbot有些小众，没有入大家的法眼，部门期望使用的是Jenkins(即原来的Hudson)。既然组织有统一规划，那我自然积极支持。但首先要做的就是评估Jenkins是否能满足我们的需求，并且看看从Buildbot迁移到Jenkins的难度及工作量有多少。这不，今天下午就一直在折腾Jenkins。

一、安装Jenkins
Jenkins(前身Hudson)很流行，在各大主流操作系统平台上都有很好的支持，其安装甚是方便，特别是在各主流的Linux发行版平台上，均可使用OS自带的应用包管理工具进行自动安装；当然你也可以直接在官方下载war包。我采用的就是第二种方式，旨在获得更高的Jenkins版本，不过让我失望的是在Ubuntu 9.04(Java version: 1.6.0_20)上，最新的1.451和1.450版本均启动失败，这也是我之前不太喜欢使用Java实现的工具的一个原因之一 – 总是容易出现莫名其妙的异常，而且较难找到原因，也很难fix，除非自己重新构建war包。在这方面像Python等动态脚本语言就有先天优势，一旦出现问题，我可以直接在源码中定位和修改。

1.441版本的Jenkins让我看到了希望，至少启动是没有问题的。启动是通过下面命令行完成的：
java -jar jenkins.war –logfile=~/.jenkins/jenkins.log –daemon –httpPort=9333

如果你是使用包管理工具自动安装的Jenkins，那么Jenkins将被作为服务安装到指定位置(比如：/etc/default/jenkins)，并且在/etc/init.d下面创建了jenkins的init脚本。这样当主机重启后，Jenkins会被自动拉起。但如果你和我一样是手工下载的war包，那你就需要自己来保证Jenkins服务一直可用了。这里的一个简单的方法就是编写一个Jenkins运行的监控脚本，如果发现Jenkins未启动，就启动它，Jenkins_monitor.sh示例如下：

#! /bin/bash

result=`ps -ef|sed '/grep/d'|grep jenkins.war`

if [[ x$result == x ]];
then
        cd '/home/tonybai/proj/jenkins' && java -jar jenkins.war –logfile=/home/tonybai/.jenkins/jenkins.log –daemon –httpPort=9333
else
        echo "jenkins is alive!"
fi

最后将Jenkins_monitor.sh加到crontab中即可：
$> crontab -l
# m h  dom mon dow   command
* * * * * bash /home/tonybai/proj/script/jenkins_monitor.sh

二、配置Jenkins
Jenkins的配置是完全通过Web页面完成的，这点全面超越了Buildbot。关于Jenkins如何配置，网上的资料可谓是汗牛充栋，这里就不再重复了，这里只说说配置过程中遇到的一些问题以及解决方法。

我们的产品需要进行多平台上并行持续集成，也就是说当trunk上有代码commit后，Jenkins应该发现代码变更，并同时通知多个不同Slave平台进行集成。之前的Buildbot是通过手工在不同平台上部署Buildslave满足这一需求的，Jenkins也是支持Master/Slave模式的，但Jenkins比Buildbot更加平易近人的地方在于Slave节点无需手工到主机上安装，只需通过在Web页面上添加Slave Node即可（实际上Jenkins在Slave Node上启动了一个Java程序"slave.jar"）。

在配置Slave node时，我遇到了第一个问题：一个x86 Solaris平台的Slave node配置完后始终无法Online，而之前配置相同的一个x86 linux Slave节点却可以顺利Online。

直到查看Log后，我才弄清楚真正的缘由。下面是Jenkins Master通过ssh连接Slave Node的Log节选：

SSH connection reports a garbage before a command execution.
Check your .bashrc, .profile, and so on to make sure it is quiet.
The received junk text is as follows:
######################
  Application Server
    On Solaris 10
######################

hudson.AbortException
        at hudson.plugins.sshslaves.SSHLauncher.verifyNoHeaderJunk(SSHLauncher.java:364)
        … …
[02/14/12 14:03:23] [SSH] Connection closed.

原来问题出在我在Slave Node节点的.bashrc中增加的那段个性化签名。Jenkins无法识别这段签名，从而抛出异常，导致Connect失败。注释掉这段签名后就可以看到Slave Node的状态为Online了。

另外一个问题是有关Mail的配置的。公司的Mail Server年前做了一次升级，将安全连接方式由原先的SSL改为了STARTTLS，而Jenkins只支持SSL。没有mail通知的CI Server显然是不合格的。为此，我再次想起了当时Buildbot的Mail发送解决方案- 使用Stunnel。原先的Stunnel配置因公司Mail Server升级而失效了，所以需要对Stunnel做一些配置调整：

这个配置调整着实花了我一些时间，也走了一些弯路，最后在反复阅读Stunnel配置手册后，才发现让Stunnel在Client Mode下支持STARTTLS，只需要做一项配置修改，即增加"protocol = smtp"这一行，示例如下：
/* /etc/stunnel/stunnel.conf */

client = yes
… …

[smtp]
accept  = host_ip : listen_port
connect = mailserver_ip : mailserver_port
protocol = smtp

这样Jenkins就可以用普通smtp连接方式(非SSL)通过stunnel与公司Mail Server进行数据交互了。

三、创建Job并执行集成
有了Node(没有也行，在Master上也可以执行集成)，我们就可以创建Job进行集成了。Jenkins Job的创建和配置也比较简单，这里同样不赘述了。我们的项目有了buildc这样的工具作为铺垫后，其构建脚本就变得相当简单了。在Job的execute shell中填写几行命令即可：

buildc config-make
make check-style
make compile-tests
make run-tests
make

对于setup工程来说，由于buildc的存在，我们也可以通过执行buildc pack build完成构建，甚至是上传安装包到指定位置。所以在折腾Jenkins的同时，我也在考虑是否可以利用Jenkins搭建一套安装包制作和发布系统呢！

四、其他
Jenkins还有一点要优于Buildbot，那就是Jenkins拥有Buildbot所没有的"立即构建(Build Now)"功能(经提醒，buildbot也支持force build功能，只不过需要在master配置中这样来配置：c['status'].append(html.WebStatus(http_port=8011, allowForce=True)))，对于我来说，这个功能在调试CI脚本时尤其有用。另外，市面上有关Jenkins的书籍并不多，《Jenkins: The Definitive Guide》算是目前市面上讲解Jenkins最为系统和全面的一本了，目前它也在我的"在读"列表中。

从目前的实验结果来看，Jenkins替代Buildbot是完全可行的，而且迁移难度和工作量也没有太多。由于接触Jenkins时间尚短，其强大的功能还需待日后进一步挖掘。

在"也谈C应用安装包制作与部署"一文中，我提到了为每一个源码工程建立单独的安装包制作工程(setup project)的想法，这两天我就一直在折腾这件事儿^_^。

最初我并没有想去搞一个通用的安装包制作工具，只是为一个现有的源码工程建立了一个试验性质的安装包工程，并实现了其构建脚本(build.py)。但之后考虑到各个项目都要建立一个对应的安装包工程，安装包工程的构建脚本build.py势必会沦落成被copy来copy去的下场，这显然不是一个很好的解决问题的办法。那是否需要再单独设计和实现一个安装包制作工具呢？工具多了，大家用起来肯定会很烦，不能自找没趣^_^。要知道为程序员编写工具可是一件很困难、很头疼，需要你很谨慎的事情。现在我们已经有了源码工程构建工具buildc，我前几天还为buildc添加了安装脚本，并用之改造了一个真实的工程，并给大家做了讲解，可以说大家对buildc算是接受了。

那把安装包制作功能集成到buildc中呢？一个大胆的想法油然而生。这样做似乎扩展了原buildc的设计意图：不仅可以做源码工程的构建辅助工具，还可以用于辅助生成安装包制作工程并制作安装包，并且这样做也最大限度迎合了组织内部大家的需求，避免了日后被狠狠地拍板砖^_^。

之前的试验安装包工程的构建脚本已经实现，现在只需将其功能移植到buildc中即可。在"也谈C应用安装包制作与部署"一文中我提到了一个示例安装包工程的组织方式，其实这里的buildc所实现的安装包制作功能也是以这个安装包工程的组织方式作为前提的，不过这里又略做了些改动，示例如下：

setup_project/
      – setup.cfg
      – distributions/
         – cn-foo-2.14.0.0-x86-linux-64bit.tar.gz
      – src/
         – setup.py*
         – README
         – app/
         – env/
           – conf/
           – log/
           – bin/
           …
         – deps/
           – libs/
           – tools/
         – scripts/
           – deps_check.sh

         – others/

也就是说，buildc生成的C应用安装包工程目录组织方式就是这样的；反过来说只有这个模样的安装包工程才能使用buildc进行安装包构建。我为buildc添加了一个Command "pack"用于安装包工程相关操作，这个命令的使用方式如下：

一、安装包工程的创建
在任意路径下执行buildc pack create –project=YOUR_SETUP_PROJECT_NAME，你即可在当前目录下看到一个empty安装包工程：

$> buildc pack create –project=foo_setup
Setup project [foo_setup] create OK!
$> cd foo_setup
$> ls
distributions/  setup.cfg  src/
$> cd src; ls
$> app/  deps/  env/  others/  README  scripts/  setup.py*

二、配置安装包工程
在生成的安装包工程下面有一个配置文件setup.cfg，在使用buildc进行安装包构建之前，务必先进行该文件的配置，其内容示例如下：

distribution = {
  "packname"    : "cn-foo",
  "version"     : "2.14.0.1",
}

source = {
  "trunk"          : "svn://10.10.15.56:4444/cn/trunk/foo",
  "binary_prefix"  : "cn-foo"
}

其中：
distribution['packname'] – 最终安装包的名字前缀
distribution['version'] – 最终安装包的版本号

source['trunk'] – 该安装包工程所对应的源码工程的svn url
source['binary_prefix'] – 源码工程构建后所生成的二进制可执行文件的名字前缀

三、构建安装包
在已经配置好的安装包工程中，使用buildc pack build命令即可以进行安装包的制作，例如：

$> buildc pack build
Clean [.build] OK!
Clean [.package] OK!
Clean [./src/app] OK!
Clean [./distributions] OK!
Package distribution clean OK!
Create dir [.build] OK!
Export [svn://10.10.15.56:4444/cn/trunk/foo] OK!
Cd /home/tonybai/proj/foo_setup/.build/foo
Config Make.rules OK!
Make Ok!
Copy binary file to [/home/tonybai/proj/foo_setup/src/app] Ok!
Cd /home/tonybai/proj/foo_setup
Del [.build] OK!
Build source [svn://10.10.15.56:4444/cn/trunk/foo] OK!
Create dir [.package] OK!
Cd /home/tonybai/proj/foo_setup/.package
Generate cn-foo-2.14.0.1-x86-linux-64bit.tar OK!
Zip cn-foo-2.14.0.1-x86-linux-64bit.tar OK!
Cd /home/tonybai/proj/foo_setup
Del [.package] OK!
Make target [cn-foo-2.14.0.1-x86-linux-64bit.tar.gz] OK!

构建成功后，你会在distributions目录下看到最终的安装包。如果在buildc命令行中没有指定–tag=YOUR_SOURCE_TAG，buildc会使用setup.cfg中source['trunk']中的配置检出trunk代码并构建；如果指定了SOURCE TAG，那么buildc就会使用tag中提供的source svn url检出代码并构建，例如下面的命令将检出foo-2.14.0.2标签的代码并构建可执行程序：

$> bulidc pack build –tag=svn://10.10.15.56:4444/cn/tags/foo-2.14.0.2

四、清理安装包工程
在工程目录下，使用buildc pack clean命令可以对安装包工程进行清理：

$> buildc pack clean
Clean [.build] OK!
Clean [.package] OK!
Clean [./src/app] OK!
Clean [./distributions] OK!
Package distribution clean OK!

五、上传安装包文件
在制作完安装包后，我们一般会将其上传到一个指定的发布服务器上去。buildc提供了上传安装包的功能。使用buildc pack upload –host=HOST –user=USERNAME –passwd=PASSWD –dir=REMOTEDIR –port=FTP_PORT命令我们可以将构建完毕的安装包文件上传到远程服务器上面，例如：

$> buildc pack upload –host=10.10.1.191 –user=tony –passwd=tony –dir=dist
Cd distributions
Upload [cn-foo-2.14.0.0-x86-linux-64bit.tar.gz] OK!

BTW，在编写和使用buildc的过程中，我真实地体会到了用脚本语言源文件作为配置文件的强大，与典型的.ini或.xml等类型配置文件相比，其灵活性过之尤甚，特别是在配置文件中嵌入一些代码就可以改变配置行为，并且脚本语言提供的丰富且强大的数据结构可以充分满足你对配置文件数据组织的需求。