昨天是周五，按照工作计划，上午和组内同事做个人阶段性目标沟通。在与一位曾经在国外公司里做过项目的同事沟通时，他给我讲了这么一个故事：某一年的圣诞节前夕(圣诞节在西方人眼里是地位最高的节日了吧)他所在的那家公司的经理预感到圣诞节那天他们公司的网站的访问量激增的可能性会很大，为了保证网站在那圣诞节那天能"挺住"，他要求手下的人对网站进行一次压力测试，并决定让手下用jmeter来做这件事情。手下人没有异议，由于没有用过jmeter，遂大家都忙碌起来，预研的、准备测试环境的等等。一切就绪后，正准备开始测试了，这时那位经理突然召集手下人说jmeter不能满足他们的压力测试要求，大家都惊愕之，并马上提出了反驳，因为jmeter工具是这位领导提出要使用的，现在又不用了，圣诞节已经迫在眉睫，更换压力测试工具肯定不能完成这个任务了。这位经理无奈妥协，结果是：通过jmeter压力测试后优化的网站顺利了通过了”圣诞节的考验“，不过大家都觉得这个过程很别扭。

上面的那位经理显然是犯错误了，我看到的起码有二：第一，没有经过对jmeter细致的评估，就断言要使用jmeter做为压力测试工具；第二，其领导意志的不坚定，险些使任务失败，并最终造成了公司成员的不满情绪，影响了整个团队，得不偿失。

这个故事也让我触动很大。记得在上一个项目的准备布局阶段，我当时很想在项目组内推行自动化页面测试，提高开发人员和测试人员的测试效率，到目前为止我也觉得当初我的想法是没有错的，但是问题就在于执行过程出了问题。我对web页面开发是外行，WEB页面开发过程会遇到哪些问题，我基本没有太多概念。当时部门内部正巧有一个服务于外国公司的项目使用了Watir-一款用Ruby实现的轻量级开源Web 自动化测试框架，很袖珍，上手简单。我就安排了一位同事专门花时间去研究了一下如何使用这个工具，并在组内做了一个Share。大家对这个工具提出了一些自己的意见和建议，并基本上认同了它。由于是试点，所以先安排放到测试组做自动化页面回归测试，由专门的测试人员负责编写测试脚本。就这样完成两轮测试后，收到一份文档-关于Watir在自动化回归测试过程的问题报告，里面列出了诸多问题，比如：自动测试过程中如遇到弹出对话框的情况，自动化过程被中断，需人为干预；测试对数据依赖很大，当数据量很大，需要多页显示时，没有找到很好的办法；页面元素变动较为频繁，用例脚本需不断更新，工作量较大；Watir只支持IE，对其他浏览器支持不好；Watir录制功能不甚完善等等。这些问题是我始料未及的，恰逢那个时候，我又发现了一个更为强大的页面自动化测试工具-Selenium，我个人也就渐渐的对Watir失去了早先的热情，Watir在我的不坚定的意志下没有收获很好的结果。现在看来，如果当时我持续关注、持续推进Watir的使用，积极解决发现的问题，也许Watir就会成为大家日常不可缺少的一个工具而存活下来，显然我没有这么做，我想和上面的故事一样，或多或少这也给组内的同事带来了一些负面的影响。

与此类似的是部门曾经多次考虑过使用C++来重新设计和实现我们的产品，众所周知C++开发效率高，性能也不逊于C，如果真的改成了C++，我们的思维也可以和这个世界接轨了(很多人认为：太多的新思想似乎和古老的C搭不上边)，大家认可，关键是领导也认可并鼓励一些有能力的开发人员抽时间研究学习C++，但是每每总是不了了之，领导始终没有坚定的意志做这次变革，开发人员也逐渐消磨的热情，回归到了C的世界。

打破既有规则，拥抱新事物，似乎一直就是一件很困难的事，而领导意志在一个组织内部目前来看还是起着决定性的作用的，否则再好的东西也会变成局部的个人兴趣，没有用武之地。如果一个领导坚定的推行大家都不认同的新事物(很可能是领导的个人喜好或者上级的命令)，那么这样带来的后果将更加严重。

所以作为领导的，确需三思而后行啊，用此文自勉共勉吧。

我所在的项目一直以C语言作为主要开发语言，与做Java以及其他新兴语言的人不同，组内的同事似乎对新鲜的东西不是那么感兴趣，也没有主动去研究新鲜事物的意愿和意识。我深为此闹心，看到外面世界中那么多美妙的工具，再也不能坐以待毙了。我一直都是有很多想法的，但是迫于自身精力有限，自己无法全身投入，以前都是交予别人去做的，但是收到的效果都不是很好。认识到这点后，我决定自己动手，丰衣足食。

从心底一直对公司的CMMI流程有所抵触，眼看着外面世界中的Agile Development等轻量级开发过程日益壮大，但自己每天还不得不按照各种繁复的流程去做，真有一种"身在曹营心在汉"的感觉。但是在一个CMMI流程"森严"的公司，又如何才能让大家接受Agile的思想呢？我想让大家看到新实践的与以往不同的成效，大家自然也就能够接受了。在Infoq上，有人也给出了建议：“切莫开口提大名词(例如SCRUM或者XP)。建议以CMMI x级的"自我改进"做旗帜，找到组织中存在浪费的环节，引入最佳实践来消除浪费，没有必要把敏捷挂在嘴边 ”。而持续集成也是文章中建议的首选实践，与我的想法不谋而合。

持续集成，以前不是没有做过，在部门的一个项目组中曾经尝试过，自己编写脚本，完成定时更新代码、构建的任务，后因项目紧张，似乎没有收到良好效果。我也曾经在项目组内推进过做Java的同事进行持续集成的实践，并安排一个同事搭建了CruiseControl的服务器，但后来似乎不了了之，也怪我没有在后期给予充分的重视和压力。有过这些教训后，我时常也在想？推进一个持续集成的实践就这么难么？这回我亲自来做，从C开发人员入手。

持续集成是需要良好的工具支持的，业内最知名的持续集成工具莫过于CruiseControl了，CruiseControl在Java开发领域占据着No.1的地位，而且其设计思想也影响着后续的持续集成工具的开发。但是一想到Java，我第一感觉就是复杂，CruiseControl会不会也像配置一个Web服务器一样那样复杂呢？另外CruiseControl使用Maven + Ant + cvs/subversion的组合，我曾经研究过Ant, Maven，大量的xml配置让我感到很头疼，另外是否与C/C++良好配合也是疑问。这样一来，我就没有继续走CruiseControl这条路，我尝试寻找一种配置简单能快速上手，核心功能也不逊于CruiseControl的工具，Thoughtworks的CruiseControl.rb走入我的视野。

一直关注Thoughtworks，因为以前部门的两位大牛级别的同事都在那任职，另外Thoughtworks推出的产品也的确让我很感兴趣，以前就曾研究过Mingle，只不过Mingle是收费的，而且目前性能还有待提高。CruiseControl.rb(以下称为CC.rb)是Thoughtworks的一款开源作品，其主页上的一小段话很是对我的胃口："continuous integration isn't rocket science. we keep it simple."。简单，正是我所期望的。

目前CC.rb的最新版本是1.3.0，下载后就是一个压缩包：cruisecontrolrb-1.3.0.tgz。解压后，在你的当前目录下会出现一个cruisecontrolrb-1.3.0的目录。CC.rb的依赖非常之少，你只需要在你的集成服务器上安装上ruby和svn客户端即可，注意:ruby和svn的可执行程序的路径需要添加到你的环境变量的PATH中，否则CC.rb将无法找到ruby和svn。目前CC.rb只是支持Svn，其他版本管理工具尚未得到支持，毕竟CC.rb还年轻，开发时间较少，情有可原。

现在CC.rb已经安装完毕了，没错！CC.rb是用ruby实现的，ruby是脚本类语言，无需编译。你现在就可以进入cruisecontrolrb-1.3.0目录下，执行"cruise –version"(在Unix主机上，你需要先将cruise文件chmod一次，否则cruise将无可执行权限)，你会看到：
CruiseControl.rb, version 1.3.0
Copyright (C) 2007 ThoughtWorks

现在你可以添加和配置你的project了。这里要先说一下，CC.rb默认将用户的project数据放在$(HOME)/.cruise/下面，如果你是在Windows平台上，project数据会被默认放在C:\Documents and Settings\USER_NAME\.cruise下面。添加一个proj很简单，你只要提供足够的信息即可：进入到cruisecontrolrb-1.3.0目录下，执行命令：
cruise add PROJ_NAME –url SVN_URL –username USER_NAME –password PASS_WORD，如果你的svn库有权限管理，你需要提供user和passwd。举例: cruise add test_proj –url svn://192.168.0.2:3999/trunk/test_proj –username tony –password tony

这样你就在$(HOME)/.cruise/projects的下面建立了一个test_proj的工程，如果你提供的信息是正确的，CC.rb会在初始建立工程的时候，将你的svn库中的代码checkout出来一份最新的，放在$(HOME)/.cruise/projects/test_proj/work下面。

完成上一步后，$(HOME)/.cruise目录下面有几个配置文件是我们需要重点关注的：
$(HOME)/.cruise
 - config/site_config.rb
 - projects/test_proj/cruise_config.rb

$(HOME)/.cruise/config下的site_config.rb文件是一个全局性的配置文件，无论你在一份CC.rb下建立几个proj，这些proj都会共享该配置，该配置每次修改后都需要重启CC.rb才能生效；该文件中有两个最主要的配置：
1) 邮件服务器配置
如果你想将每次build的结果通过mail的形式发送给相关干系人的话，你就需要配置你的mail server相关信息。
ActionMailer::Base.smtp_settings = {
   :address =>        "xx.xx.xx.xx",
   :port =>           25,   #一般服务器默认smtp端口都是25
   :domain =>         "YOUR_DOMAIN.com",
   :authentication => :plain,
   :user_name =>      "YOUR_USER_NAME",
   :password =>       "YOUR_PASSWD"
 }
2) Dashboard URL
Configuration.dashboard_url = 'http://ip : port'； Dashboard URL将被加入到发给干系人的mail中，这样相关干系人收到mail后可以直接点击该url登录到CC.rb的Dashboard查看相关内容。CC.rb的配置文件也同样适用ruby语言编写的，ruby语言语法较为简单，相信大家都看得懂。

$(HOME)/.cruise/projects/test_proj下的cruise_config.rb文件则是一个Project-specific的local配置文件，它是动态更新的，你的更新在下一次build时是即时生效的。该配置文件中的内容都很重要和实用：
1) project.email_notifier.emails = ['email1@your.site'] 该配置用于添加干系人邮件，这样每次build后，CC.rb都会读取该配置，发送mail给该email list的人；
2) project.email_notifier.from = 'email2@your.site'，该配置将指定notify mail中的发件人，你可以因项目的不同而配置不同的mail。
3)  project.rake_task = 'custom'，似乎该配置只有当你使用rake这个工具时才需要配置，如果你使用诸如ant,make等工具的话，该配置还需保留原先的被注释状态；
4) project.build_command = 'build_my_app.sh'，该配置给予你自定义build脚本的机会，也正是这样，你才可以将CC.rb与Ant, Make等工具集成在一起使用。如：project.build_command = 'make'。注意CC.rb执行build_command的working dir是$(HOME)/.cruise/projects/test_proj/work下面，如果你的build_my_app.sh没有放在work下面，而是在$(HOME)/.cruise/projects/test_proj下面的话，你这块就要配置成：project.build_command = '../build_my_app.sh'; project.build_command与 project.rake_task不能一起使用。
5) project.scheduler.polling_interval = 5.minutes ，CC.rb定期去检测svn是否有new revision，这个配置就是用来指定检测周期的，如果你不配置，那默认是30s。

如果你以上都配置完毕了，你现在就可以启动CC.rb了。启动方法：进入到cruisecontrolrb-1.3.0目录下，执行"cruise start -p port"。CC.rb会启动自带一个轻量级web server – WEBrick ，对于我这个对web server不熟悉的人还是很方便的，我只需要告诉CC.rb端口即可。CC.rb启动后，你可以在浏览器输入http://ip:port，CC.rb的简洁的页面就会显示出来，你会在页面上看到你刚才建立的工程test_proj，点击右上方的"build now"按钮，你就开始了一次build的过程。无论成功还是失败，你都应该收到一封mail，关于此次build的详情可以点击mail中的链接。如果失败了，你可以在页面上的"build log"中看到此次build的详细日志，以帮助你分析失败原因。

CC.rb是如何判断build过程成功还是失败了呢？我们以project.build_command = 'xx'的配置为例，其实CC.rb是通过判断xx这个builder的返回值来决定build过程是否成功的。当xx这个builder返回0，说明build成功；否则build失败；我们不妨测试一下：在$(HOME)/.cruise/projects/test_proj/work下面写一个小程序：
/* test.c */
int main() {
 exit(0);
}
gcc -o test test.c

配置project.build_command = 'test'，点击"build now"，收到mail，提示build success；如果你将exit(0)改成exit(1)，那么一封failed的mail就会发到你的邮箱里。

C/C++没有很好的单元测试工具，一般C/C++单元测试工具都会将单元测试用例编译链接成为一个可执行文件，然后执行，以判断是否通过。到这里你是否想到了如何将C/C++的单元测试与CC.rb集成到一起的方法呢？对，我们通过脚本也好，或者干脆自己编写一个单元测试框架，通过程序返回值告知CC.rb新提交的代码是否通过了单元测试的考验。

以上是第一次使用体验CC.rb时记录下的内容，其实CC.rb就是这么简单！