Tony Bai

本博客已搬家至tonybai.com，后续该博客将停止更新，望各位朋友了解。

再重申一下新博客的Feed地址为：feed.tonybai.com，欢迎订阅。

凡bigwhite.blogbus.com以及下属子页面的访问请求都将会被重定向到tonybai.com，欢迎用tonybai.com的博客搜索页面找到你所需要的文章。

鉴于大巴博客设置中的Feedsky输出RSS不甚稳定，并且出于固定博客的Feed的需要，特将本博客的Feed地址改为: http://feed.tonybai.com ，烦请已经订阅本博客的朋友们重新订阅新的Feed地址；尚未订阅本博客的新朋友们请用新Feed地址订阅。

BTW，原Feed地址将在一段时间后关闭。

我们的后端C应用都是支持跨平台的，至少目前在Linux和Solaris上运行是没有问题的，这样一来我们在配置持续集成环境时就要考虑如何实现在代码Commit后触发多平台并行(同时)集成这个需求。

之前使用Buildbot时是通过为一个Scheduler配置多个Builder满足这个需求的。但现在要换成Jenkins，我们如何来实现呢？昨天在折腾Jenkins时我把问题想简单了，今天细致查看了一下Build Log后才发现之前的配置并未真正实现多平台并行集成。

最初的Jenkins配置大致是这样的：我在Jenkins上添加了两个节点(Slave Node)，分别为x86-linux-ci-slave和x86-solaris-ci-slave，并且为这两个节点设置了一个相同的标签"foo-ci-slaves"。之后我创建了一个新Job - "foo-multiplatform-ci"，选择的是"构建一个自由风格的软件项目(Build a free-style software project)"。为了使得该Job执行并行集成，我选择了"Restrict where this project can be run"，在"Label Expression"中填上了"foo-ci-slaves"，其他配置这里就不赘述了。

按照我最初的理解，这样配置后点击"立即构建"，两个Slave Node上就会同时进行相关的集成。但Build Log告诉我事实并非我想象的那样：Jenkins只是在一个Slave Node上执行了Job。那使用Jenkins如何来实现前面所说的多平台并行集成呢？查来查去，我发现原来是我在创建Job时选错了配置，我应该选择"构建一个多配置项目(Build multiconfiguration project)"。

与free-style project相比，multiconfiguration project的配置页面中不见了"Restrict where this project can be run"配置选项，但却多出了一个"Configuration Matrix"配置区域。在该区域中，我们可以选择Slaves，在Node/Label中，我们可以看到当前Jenkins中配置的所有Label和Nodes。选择一个Label是无法满足我们的要求的，那样Jenkins只会从Label中的若干个节点中选择一个来执行集成。所以我选择Nodes，将x86-linux-ci-slave和x86-solaris-ci-slave都选上，保存后我们就会在"foo-multiplatform-ci" Job的主页面上看到两个configuration: x86-linux-ci-slave和x86-solaris-ci-slave。点击"立即构建"，这两个configuration对应的小球标志就会同时闪动，这说明"foo-multiplatform-ci"正在两个Slave Node上并行运行呢，这才是我想要的结果。

支持多平台并行集成只是Multiconfiguration Project的一个用途之一，《Jenkins: The Definitive Guide》一书对此有更为细致的讲解，你可以结合自定义Axis(坐标轴)以及parameterized Build实现更为复杂的构建需求。但目前我尚未遇到类似需求，所以这里也不敢乱说^_^。

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)"功能，对于我来说，这个功能在调试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等类型配置文件相比，其灵活性过之尤甚，特别是在配置文件中嵌入一些代码就可以改变配置行为，并且脚本语言提供的丰富且强大的数据结构可以充分满足你对配置文件数据组织的需求。

buildc在发布0.1.0版时并没有做好安装脚本，当时的建议是直接下载0.1.0的源码包或svn export/checkout源码包，并手工将buildc目录位置加入到用户的PATH环境变量中。近期buildc计划正式投入到项目中使用，为了方便大家安装以及以后的统一升级维护，我花了些时间给buildc加上了setup脚本。

Python有标准的程序分发方案，不过我对这些了解不多。buildc本身很简单，我觉得没有必要把安装做得很复杂，所以就自己动手编写了一个setup.py，不到100行，用于安装buildc。

Python的标准安装脚本也叫setup.py，我这里也借鉴了这个名字。有了setup.py，buildc的安装就简单多了：
* 下载buildc Release包(当前最新是buildc-0.1.1)
* 解压发布包，在发布包路径下，执行setup.py install [--prefix=YOUR_INSTALL_PATH]

setup.py默认将buildc安装到/usr/share/buildc下面，并在/usr/bin下建立一个到/usr/share/buildc/buildc脚本的符号链接(symbol link)，当然这种安装是需要root权限的，但一旦安装好，host上的所有用户就都可以使用buildc了，日后统一升级buildc也十分方便；如果你不想在默认路径下安装，可以通过--prefix=XXX指定你自己的安装路径，这种情景下，setup.py不会建立什么符号链接，需要你手动将你的安装路径加入到你的PATH环境变量中，以便后续使用。

卸载buildc也十分方便，执行一条"setup.py uninstall [--prefix=YOUR_INSTALL_PATH]即可。

setup.py的安装原理很简单，就是利用shutil包的copytree将buildc目录复制到指定目录下。shutil的copytree在Python 2.6以后版本中支持ignore参数，可以有选择的将buildc目录下的文件和目录复制到目标目录，比如.pyc文件或.svn目录本不应该出现在目标目录下，我们就可以通过ignore参数指定一个ignore_patterns来过滤掉这些文件或目录：

shutil.copytree(package_root, install_root, ignore = shutil.ignore_patterns('*.pyc', '.svn'))

但在Python 2.6版本之前，ignore参数是不被支持的，所以这里也留下缺憾，那就是如果你使用svn checkout方式下载源码包，安装的时候.svn等目录也会被安装到目标目录下，看起来别扭，但不影响您对buildc的使用。

虽然部门一直在做C应用 ，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。

去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。

总的来说，摆在我们面前的有三个主要问题：
1、安装包的组织方式不规范，不统一；
2、安装包的制作方式不规范，不统一；
3、安装包的部署方法不规范，不统一；

好了，下面我们就来针对上述问题逐一说说改进思路（注意以下内容并非普适）。

一、安装包组织方式
在Linux 平台上应用的标准安装包是rpm或deb，但这种安装包形式似乎不太适合我们这种C后台应用。我对rpm或deb安装包了解的不多，但印象中这类安装包的安装一般为完全安装，但我们的应用升级版本时多数为增量安装或局部替换，因此做成rpm或deb虽然看起来专业一些，但实际操作起来并不灵活，因此自定义的安装包组织方式似乎更符合我们的需求。

下面是一个安装包的组织结构样例：
INSTALL_PACKAGE/
      - install.sh
      - README
      - app/
           - foo-1.0.1*
      - env/
           - conf/
           - log/
           - bin/
           ...
      - deps/
           - libs/
              - bar/
           - tools/
      - scripts/
           - deps_check.sh
           - ...
      - others/

其中:
app目录下存放的是可执行文件;
env目录下存放的是可执行程序运行时所需要的目录结构，包括配置文件等;
deps目录下存放的是可执行程序运行时所依赖的第三方库以及一些工具;
scripts目录下存放的是安装包安装过程中所需要的辅助脚本;
others目录下可以存放无法在上述目录下存放的其他数据;
install.sh是总控安装脚本，可以用于在目标主机上安装app、完整安装运行时环境、安装依赖libs或工具，执行scripts下面的必要脚本。

这样的一种安装包格式比较灵活，我们可以根据需要通过install.sh安装可执行文件或某个配置文件或其他数据文件。将INSTALL_PACKAGE目录打包(.tag.gz or .zip)就得到了我们的安装包。

安装包命名是要符合一定规范的，也便于进行配置管理。一个典型的安装包命名规范：程序名-版本号-平台-操作系统-编译模式.tar.gz[.zip]，例如：
foo-1.8.3-x86-linux-64bit.tar.gz
bar-2.9.3-x86-solaris-32bit.tar.gz
zoo-1.3.2-sparc-solaris-64bit.zip

二、安装包的制作方式
以往的安装包都是直接基于项目源码库构建 出来的，很多运行时目录、配置文件以及辅助脚本也都与源代码存放在一起，这样一来让源码库看起来很臃肿，二来一份源码控制无法对应部署到多个不同客户现场的安装包，也就是说不同客户生产环境下的配置、数据等都是不同的，但源码库只有一个，我只能保存一份配置，因此在生成不同安装包是似乎要临时修改，且无法将这些修改做版本管理。

我的一个想法就是将安装包涉及到的相关文件和目录从源码库中剥离出来，针对每个项目源码，我都会建立若干个安装包工程，安装包则是这些工程(project)的产物，且可以针对不同客户做有针对性的安装包修改和版本管理。记得Microsoft的Visual Studio就有单独的安装包制作工程模板，这里也算借鉴Visual Studio中安装包工程的思想了^_^。

下面是一个安装包工程的示例：
foo_INSTALL_Proj/
      - Makefile
      - distributions/
         - foo-2.9.3-x86-linux-64bit.tar.gz
      - src/
         - install.sh
         - README
         - app/
         - env/
           - conf/
           - log/
           - fifo/
           - bin/
           ...
         - deps/
           - libs/
           - tools/
         - scripts/
           - deps_check.sh

         - others/
其中src下面的内容就是上面提到的安装包的组织，通过安装包工程我们就可以灵活控制安装包中的每一个元素，而对源码没有任何影响。

三、安装包的安装模式
有了前面两个问题解决作为铺垫，这个问题就很好办了。我们的应用大致有两种安装模式：本地安装和远程安装，实际上也是一回事。本地安装就是手工将安装包放在某个目标主机上，然后解压，并利用安装包中的install.sh来安装需要的文件；而远程安装多半是用远程控制工具将安装包上传到目标主机（可能是多台），并通过远程命令在远程主机上执行本地安装。

这里想到的一个改进就是在目标环境中部署应用前，首先执行一次部署约束检查，检查目标环境是否满足新应用部署和运行的约束条件。这在以前的部署步骤中是没有的，约束检测脚本可随安装包携带，比如放在scripts目录下。

总之，规范化的安装包组织形式、制作方式以及部署方式不仅是一种专业化的表现，它与一些自动化工具的结合还会促进团队或组织整体效率的提升 。

对于我这个上班族来说，这假期真的不能太长，否则就适得其反了：不但不会得到很好的休息，反而感觉更累了。也许很多朋友和我有同样的感受^_^。这不，这个春节在家待得就比较"闹心"，特别是后几天，想上班的冲动那叫一个此起彼伏啊，终于今天如愿了^_^。

今天是壬辰龙年春节后的第一个工作日。如以往一样，办公室里比较冷清，很多同事还尚未结束休假。这可真是做整年谋划的黄金时间啊，我是这么想的，也是这么做的。

2012元旦后我就一直在考量，考量的内容除了个人目标外。还有团队目标和组织目标，以往考虑个人的居多，现在逐渐开始考虑团队和组织了，也算是一个进步吧。下面分别列一下目标清单。

一、个人目标
1、将Blog进行到底
2011年写了80余篇blog，今年力争百篇blog，在家庭琐事繁多、工作日益繁忙的今天，这个目标很鸡血啊！

2、全年至少精读50本书
"书中自有黄金屋"(颜如玉就算了^_^)，不读书总感觉空虚。经过2011年一年读书习惯的养成，特别是购买了电子书阅读器Bambook后，我对实现这一目标很是自信。另外我目前的纸质"存书"(买来后尚未读)也是很多的，今年也打算好好的"扫扫"。

3、学习一到两门新语言
"每年学习一门新编程语言"- 《The Pragmatic Programmer》一书的教诲不敢忘却，今年计划尝试一下Clojure，Lisp的又一种dialet，结合了强大的JVM，可以使用已有的丰富的Java类库，个人感觉Clojure似乎比Common Lisp更有前途；Lua，在云风的blog中经常提到的一门嵌入式动态脚本语言，前不久刚发布了5.2版本，我也打算了解一下。

4、深入使用Common Lisp和Python
去年学习了Common Lisp，但感觉还不够深入，今年打算再加深一下；至于Python，我已经在实际开发中运用了，但也只能算初级运用，今年也打算继续深入学习和使用一下，至少在buildc重构时以及为c_style_check.py添加新feature时可以用到。

5、继续为开源做点力所能及的事儿
在相继开源了lcut、cbehave和buildc等小工具后，今年尚未有很明确的新目标。最基本的计划是对buildc进行重构，并为c_style_check.py增加新feature以满足我们团队内部的需要。

6、坚持每天至少回答一个Stackoverflow上的问题
这个既可以锻炼一下自己的English Comprehension和Writing水平，同时也可以为这个知名的IT Community的知识管理作出一点贡献，顺便也给自己增加点人气数值。

7、养成几个好习惯
春节前读过刘未鹏的《暗时间》，受益匪浅啊。感觉自己在很多方面与书中提到的“先进行为和思维方式”还差得远，所以结合这本书中提到的内容，我计划在如下方面培养自己的好习惯：
- 做好读书笔记，留住闪念，提高读书效果
- 继续提高关注力，加强潜意识效率
- 减少中断式的任务查询，加强积极的任务安排和计划（改善时间管理）
- 尝试按"主题"读书，提高读书效率
- 加强新知识的总结
- 加强事前准备工作
- 注重"元知识"的学习和积累(所谓元知识，就是能够产生或推导出知识的知识)

8、理顺管理知识体系
做了几年的技术管理，团队的规模也是日益庞大，但总是感觉自己在技术管理这方面还很初级，知识脉络还不清晰。今年打算多反思一下这几年在项目产品开发、团队管理等方面的得与失，让管理能力真正成为自己的一种核心竞争力。

二、团队目标
2012年我给产品研发团队确定的关键词是"收获"。经过2011年的铺垫，今年该是"收获"的一年了。不过收获前，我们依旧是要付出辛勤和汗水的，我心里很是清楚这一点。围绕着这一点，我确定了今年团队的几个行动原则：

1、以终为始
开年伊始我们就要十分明确：我们的最终目标是什么？我们要成为一个什么样的团队？我们要开发出什么样的产品？我们产品上线后能给客户带来什么样的价值？只有明确后，我们再围绕着这些制定全年的计划和目标，基本上还是很靠谱的。

2、创业精神
这四个字是今年年底公司大BOSS在一封内部Mail中提到的 - 公司刚刚走过20年，又迈上了新征程，需要大家具备创业的精神来支撑公司未来的发展。想到"创业"，我的第一反应是：辛苦。所以给团队定下此原则也是有深层含义的，那就是在人力资源有限的情况下，完成目标是要付出很大辛苦的。这的对于大BOSS提出的"创业精神"的解读也许有些狭隘了，但这的确符合我们团队今年所面对的情况。

3、追求高效 
高效是一直我所倡导的团队文化之一。关于提高效率，我的观点是个体能力提升与组织基础服务并进。在今年我对团队的期望依旧如此。我们要考虑的是围绕着这一原则，我们该做些啥。

4、过程与结果双赢 
《暗时间》中刘未鹏提到"看中过程，而不是单次的结果，因为再好的过程也有可能失利，但从长远来看，好的过程总体上必须导致好的结果"。对此观点，我很是赞同。因为我一直所追求的也是"过程"与"结果"的双赢，只有这样才能推进个人、团队乃至组织的持续成长，若只有结果，也许只是收获一时的成长，但能否持续成长就要看造化了。

关于团队的具体目标，这里就不好说了。

三、组织目标
这里只说我能看到的且可以付出努力去争取的。

1、资源整合与合理调配
随着产品和项目的调整，现有的内部资源分配亟需调整，无论是人力资源还是硬件资源，特别是硬件资源，可使用现有新技术做出合理调配，让每台服务器都能物尽其用，减少因硬件资源不足而导致的进度延迟的情况。

2、尝试降低或消除部门间"壁垒"，积极促进部门间的沟通交流
做这件事的目的同样是为了消除浪费，整合资源，形成合力，制度化的部门间沟通平台的建立是大有裨益的。

3、人员招聘选拔
部门在人员招聘选拔上尚不够规范和系统，略显粗放和随便，这样除了会导致成本浪费之外，还可能导致所招之人根本无法达到预期，即所谓“招错人”现象的发生。这方面亟待加强，至少要做到“严进”二字。

以上就是我谋划的2012，目标的确有些鸡血！但我相信只要持续努力，持续去做，一步一个脚印，其结果肯定是好的。

2012，是农历龙年，也是中华民族的本命年。龙，是我们民族的图腾，大家对龙都是有着特殊的情感的，比如壬辰年的生辰龙票就特别抢手。

龙年了，果果也长大了，越来越像女孩儿了，呵呵（因头发短，常被人误认为是男孩儿），下面是果果近期的一些写真^_^，请您欣赏：

这种玩具难不倒我

瞧，我的眼神犀利不！

妈妈给我买的眼镜，知性不？

数一数，墙上有几朵花？

过年了，我的新衣服喜庆不？

好了，最后在龙年的大年初一，我代表的我的宝贝女儿果果给您拜年了。祝大家龙年新春快乐，阖家幸福，身体健康，万事如意。

构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何，构建都是这些应用开发过程中必不可少的一步。

伴随着C语言的普及，C语言应用的构建工具也逐渐发展起来，随着Project构建复杂性的增加，大致可分为四个阶段(个人观点)：
* 命令行构建
对于简单应用来说，其源文件数量一般较少，且可能都放在一个同目录下，构建这样的工程的最简单的方法就是直接在命令行上输入编译命令(诸如gcc -o foo foo.c bar.c)。这种方式在C诞生早期的简单应用或对于刚刚C入门朋友来说是最常见的。

* make工具
随着Project复杂程度的增加，使用命令行编译构建的难度日益加大，大家开始使用make工具。make工具的实质是帮助项目管理依赖关系。C应用构建的最终目标一般都是一个可执行文件，该文件一般是由所有源文件的目标文件以及依赖的第三方库链接后生成的，也就是说该文件依赖项目源文件的目标文件以及第三方库。我们可以将这种依赖关系用make工具指定的专用语法描述出来，形成Makefile文件。后续我们如果要构建该Project，只需敲入make即可。make工具会自动分析Makefile中的依赖关系，并执行依赖关系对应的命令，并最终完成构建。

* autotools
虽然make工具很好地解决了复杂Project的构建问题，但make本身的学习曲线也是很陡峭的，也就是说要为一个复杂的C应用编写Makefile脚本并非易事，特别是复杂Project中那更为复杂的依赖关系，可以让任一一个程序员望而却步。大家都看到了这一点，因此就有了autotools工具集的诞生。autotools工具集由autoconf、autoheader、automake和libtool等工具组成，其主要目标就是简化项目Makefile的编写。使用autotools，我们可以为C应用的Project自动生成Makefile，这显然是一个很大的进步，对于复杂的Project尤甚。

* 新兴的通用构建工具
虽然autotools的出现解决了一些C应用构建难的问题，但autotools自身使用起来也是略显复杂的。特别是它由若干工具组成，并需要这些工具一起配合才能完成一个Project的Makefile的编写和生成，学习这些工具本身也要耗费很多时间。随着一些脚本语言的流行，一些新兴的通用构建工具逐渐出现在大家的视线中，诸如Scons、rake等。这些新工具吸取了make等门槛较高、不易用的教训，利用脚本语言特有的性质打造出了更加简单易用的构建脚本，现在很多C应用都开始使用这些工具简化构建脚本编写了。

究竟是使用哪种构建工具，这还是取决于项目所处的"环境"，包括项目的复杂性，人员的平均技能水准等等。但有了构建工具还不足矣，我们再来看看关于C语言应用构建还有哪些应该关注的地方。

一、规范化项目源码组织
项目的源码组织是应该先于构建脚本实现的，因此良好的项目源码组织也有助于构建脚本的编写，同时也有利于组织内部的标准化和复用。但C应用的源码组织的确没有统一的标准，也没有最好可言，也许只有适不适合。下面就是我们所使用的一个典型的C应用(非公共库)源码组织示例：

Foo_proj/
    - Makefile
    - sub_proj1/
        - Make.rules(由buildc生成)
        - Makefile
        - include/
        - module1/
            - xx.c
            - Makefile
            - tests/
                - xx_test.c
                - Makefile
        - module2/
            ... ...
    - sub_proj2
        - Make.rules(由buildc生成)
        - Makefile
        - include/
        - module1/
            - xx.c
            - Makefile
            - tests/
                - xx_test.c
                - Makefile
 ... ...

针对这个示例有几个注意事项要说明一下：
a)
以前在很多Project中，都会包含一个顶层的(toplevel)Make.rules，这样的设计考虑无非是希望项目下的其他sub_proj可以复用该Make.rules，这看起来似乎方便了。但实际这样做是在各个子项目间建立了一层构建耦合关系：很多子项目都有个性化的构建需求，这样一来可能会频繁对该顶层Make.rules进行修改；或是当无法修改顶层Make.rules时子项目还是会在自己下面增加一个子Make.rules以满足构建的个性化需求。我们莫不如去掉顶层Make.rules，而在各个子项目中添加自己的Make.rules。特别是在有了buildc工具以后，每个子项目下的Make.rules都是自动生成的，这样不但不会增加太多的额外工作量，还从根本上去除了子项目间的一种耦合，完全可满足sub_proj的个性化的构建需求。

b) 顶层的Makefile依旧保留，一般作为一键构建整个项目时之用。顶层的Makefile实际来看就是将各个sub_proj串接起来，再说白些，就是遍历的调用各个sub_proj下的Makefile。

c) 针对每个module的单元测试代码与被测试的module代码存放在一起(比如放在module下面的tests目录下)，这样使得被测对象与测试代码物理上接近，易于源码的测试，同时逻辑上看也很紧凑。

二、构建执行的简单和高效
构建是一个频繁的日常开发活动，简单和高效是IT开发者对"构建"活动的两个基本要求。所谓"简单"就是尽量不让或少让我动手，懒惰的程序员们最多只是希望敲入一个命令就可以完成项目的所有构建，这就是我们所说的"一键化"。一键化从另一个角度来说也是一种"高效"，但"高效"更重要的含义则是指尽量缩短构建的时间。要想做到这点，一是需要一个清晰明了的构建脚本实现，把项目内部的各种依赖关系打理清楚，只作必要依赖，减少不必要的重复构建；第二则是选择一款高性能的构建工具，目前来看make本身的性能还是很棒的，一般来说还是强于scons这样以动态脚本语言实现的工具的，特别是再加上并行编译和分布式编译后，构建时间将大大缩短。

三、第三方依赖包的管理
在开源软件大行其道的今天，很多商业项目都或多或少的用到一些开源包，即使没有用到开源包，组织内部也可能存在项目间相互依赖的情况，比如：业务部门的应用很可能依赖基础研发部门提供的通用库，这样就出现了一个第三方依赖的管理的问题，这也是我们在进行构建设计过程中所不可忽视的一个重要方面。

关于第三方依赖包的管理，至少我是见识过如下几种方式：

* 将第三方依赖包的源码导入到你的项目，伴随项目一并构建
这样做的好处之一就是完整：大家在构建项目时无需东找西寻，依赖的代码就在项目库中。好处之二是便于一键构建，依赖包的源码就在项目中，可以任你"宰割"；第三则是便于在不同平台上移植，因为直接存储了源码，在每个平台都是依据所在的平台构建对应的版本。

不足之处：这样做会导致项目代码库庞大，构建时间漫长；另外也不便于第三方依赖包的更新升级。一旦第三方依赖包有bugfix或新feature，你可能需要手动的同步代码。一旦依赖的第三方包有很多的话，这可是一笔不小的工作量；最后每个项目都单独存储一份第三方依赖包会导致大量重复，重复可并不是一个好味道。

* 将第三方依赖包构建后的二进制文件放入项目代码库
这样做的好处在于提高了构建效率，节省了第三方依赖库自身的构建时间。但这样做的不足之处依然很多，直接存储源码方式的大多数不足都被该方式继承了下来，除此之外，这种方式还会导致在不同平台上构建难度的增加(不同平台上的包的二进制文件是不同的)。

* 对第三方依赖包进行集中单独管理
将各个项目所使用的第三方依赖库做统一集中管理，而不是放在每个项目中，并且只存储构建后的二进制文件而非源码。组织形式示例见下面：

3rds/
      - libevent/
           - 2.0.10/
              - README
              - source_code_package
              - sparc_32_solaris/
    - include/
    - lib/
              - sparc_64_solaris/
              - x86_64_solaris/
              - x86_64_linux/
           ... ...
      - netsnmp/
      ... ...

这种"分门别类"的第三方依赖包集中管理方式既有利于加速构建过程(直接用二进制，省下源码编译)，同时也便于依赖包的统一升级和管理(专人负责，通过版本号区分)。这种第三方依赖包的管理方式也是使用buildc构建辅助工具的前提。这种方式也是有缺点的，那就是需要有专人负责对该公共库进行管理，包括新版二进制包的制作与上传。

至于在具体项目中究竟采用哪种方式还需要根据project的具体情况作出权衡，如果你依赖的第三方包较小且很少，那方式一很适合，redis就是这么做的；如果你不要支持多平台，那么第二种方式也可行；对于组织而言，似乎第三种方式是规范、统一和一致的，这也是我推荐的方式。

四、适于与第三方工具集成
持续集成是公认的优秀实践，市面上有很多优秀的ci工具。持续集成的第一步就是构建，因此一个好的工程构建是应该能与ci工具很好结合在一起的，也就是说要充分考虑构建脚本与ci工具的结合。

一般来说持续集成工具判断成败与否的根据就是你委托ci工具执行的脚本的返回值。对于C应用构建过程来说，一般是make的返回值。0即成功，其他均为失败。对于单元测试用例的执行过程而言，也同样是此道理。C的单元测试集实际上就是一个个可执行程序，每个程序的返回值都是需要认真考量的，不能随意。如果你使用类似lcut这样的框架工具，你就完全可以通过框架工具来帮你完成用例执行返回值的设定。

良好的项目构建设计是项目迈向成功的重要一步。在日常开发工作中我们不仅仅要关注软件开发过程中的"前段"，比如需求、设计和编码；对"后段"的一些活动，诸如构建、测试和部署也要给予足够的关注。以上所讲仅是经验之谈，谈不上绝对正确，因为关于C应用构建的资料相对较少，也没有统一的标准，这里权当抛砖引玉了。

每至年关，回首一年工作中的成长，便有一种充实和幸福的感觉。

2011年我在工作中的成长可概括为如下几点：

1、建立并围绕原则为中心开展工作
现在想来，以前的工作有些盲从，心中没有原则，自然也就没有主线，也许这与当初的职位角色有关。2011年职位提升了，思维方式也有所了转变。我花了更多的时间对当前的工作进行考量，而且考量的过程不是过去那种仅仅从项目组或产品线的角度，而是尽量上升到组织的角度，并针对当前工作建立起一系列原则，这些原则成为了我在工作中决策的基本出发点。以这些原则为基础，安排自己与他人的工作就有了着力点，一切显得十分自然合理。

2、学会着眼大局
逐渐学会和适应了从组织层面去思考问题，以追求组织的"可持续发展"为原则；做长远考虑，不局限于眼前得失，懂得奉献；积极尝试打破部门间壁垒，积极主动地投入到工作中去，先予后得，充分发挥兄弟部门的力量，促成任务的完成。

3、更加注重行动
以前的我由于忙于一线事务，很多改进都停留在了想法提出的层面上。但今年在积极地对产品线的组织结构进行调整后，我个人有了更多的时间思考改进，更多的精力投入到改进的实施上去，并且取得了良好的效果。知识库建立 、利用虚拟化改善开发效率、提议的制度化 、效率提升思路的转变 等都是在此前提下得到大步推进的。

个人感觉这三点已经逐渐固化到我行事的思维方式中去了，这让我真真切切地体会到了自己这一年来的成长。

这周五我做了一件"恶事" - 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的，但却真实地让我给碰到了。

我以前只是有招人的经验，但从未做过"开人"的事情，这是第一次，心里总有些不忍。原计划由这名同事的直接Leader与他谈这件事情，但这名女leader更是抹不开面子，索性我就直接上阵了。过程还算顺利，这名同事表面上也没有太多意见，但我心里清楚：他肯定很郁闷，这个周末估计会很失落。我们也不想这样的事情发生，但之所以做出这个决定也是因为这名同事"所作所为"实在是太不给力了。

这名同事进入我们产品线大约有一年半时间，他并非是我们招入的，而是由领导从其他项目组安排过来的(恰逢那时我们缺人)。最初安排他做开发侧的技术支持角色，负责产品的升级支持以及生产环境问题的解决，算是隶属开发运维团队。但一段时间后他似乎没有得到运维团队内部的信任，给他派的活儿都是很边缘的，生产环境遇到大的问题基本都绕过他而直接找到原开发人员解决，形成这一局面的原因无非有二：一是他无法独立地及时解决生产环境中的问题；二是在自己无法解决的情况下，也没能很好地协调他人将问题解决。长此以往大家索性就不找他了。团队内部不能养闲人，我们还是给了他机会 - 尝试让他做些开发团队的工作，把他直接安排到上面提到的那位女Leader的项目组里面。经过了大半年，他给出的成绩单却是：失去了所有团队对他的信任，大家把他彻底孤立了起来。团队并非一开始就失去对他的信任，而是不断给他机会，给他的工作都是相对比较简单的，时间上也相对宽松。但即使这样，他也是不断延误进度，提交上来的东西也是频频出错，耽误了自己不说，还耽误了其他团队的整体进度，大家逐渐开始对他都不耐烦了，我这里也不断收到大家对他的抱怨，局面就是这样形成的。年中面谈时，还曾明确给他指出了不足，并就改进绩效计划达成一致，但他依旧没有达到我们的预期。木桶理论告诉我们：在一个团队里，决定这个团队战斗力强弱的不是那个能力最强、表现最好的人，而恰恰是那个能力最弱、表现最差的落后者。于是我们从全局考虑，从团队的整体考虑，我们做出了上面那个无奈的决定。

我做了一下换位思考，如果我是这名同事，到底是什么原因让我走到了这步田地呢？下面我就来帮他分析分析。

首先，我想这位同事没有走好融入团队的第一步棋 - 赢取团队的初始信任
对于一个刚刚进入团队的新人（无论是有工作经验的还是刚毕业的新人），赢取团队的初始信任都是最最重要的。下好这第一步棋其实并不难，把你的直接上司分配给你的第一个任务做好即可。当然如果要赢得超出预期的信任，那就得做的完美一些。在这个阶段，你最好能专心投入，甚至“牺牲”一些个人时间（对于程序员来说，这很容易理解^_^），快速地熟悉新环境、行业领域业务知识、产品以及团队风格。一旦你的第一个任务达到或超过了大家的预期，团队对你的信任也就建立了起来，后面的事情就变得自然而然了；而一旦你搞砸了第一个任务，那就相当于从团队成员那本来就积蓄不多的情感账户中取款，那后续走势如何就要看这个团队的耐心了，他们到底会给你多少次犯错的机会呢！

其次，能力不足且没有努力做出改进
赢得信任需要有资本，这最起码资本就是个人从事这个行业工作的能力。绝大多数行业中处于能力平均水平的人维持一份稳定的工作都不难。但问题就在于如果这个人没能认识到自己能力的不足，或是即使认识到能力不足，但也不努力改进，那这个人就危险了。我的这位同事身上显然就发生了这个问题，这一年多以来他的能力或技能只能说是原地踏步，在IT这个行业里，大家都知道这意味着什么。

最后，态度！
俗话说："世上无难事，只怕有心人"。这句话从侧面反映的是一种做事的态度，而我的这位同事被诟病最多的就是做事的态度上。我从多方面反馈了解到，他似乎就没有把分配给他的任务当成自己的事来做，总是囫囵吞枣，不断犯错，不断被指出，之后依旧不断重复犯错，似乎一点改进的意识都没有。如果把工作视为可敷衍了事的事情，那后果可想而知。

也许还有一种更为深层次的原因，我也不敢肯定，那就是他也许根本对程序员这个行当不感兴趣。缺少动力，行将就木，做一天和尚撞一天钟，因此有了糟糕的表现。如果真是这样的话，那就是严重地对自己不负责任了！说得严重些叫浪费生命，也许他换个行当就能出类拔萃呢。

在组织层面如何为避免此类事情发生呢？也许只能严把入口。但说起来容易做起来难，仅仅通过几次面试，很难全面地去认识一个人。刘未鹏不是写过一篇文章叫"怎样花两年时间去面试一个人"吗，显然也印证了这一点。

最后还是要对这位同事说一声：你还年轻，这仅仅是一时的挫折，绝不应该就此消沉，反思一下，找到一条更适合自己的路，好好的走下去。