多数公司不会仅有一个项目，当你为一个项目引入持续集成实践后，其他项目就会接踵而来。这时你会重新考量BuildBot，考虑如何让BuildBot可以服务于多个项目。 如果你有足够的主机资源和人力资源，那为每个项目单独搭建一套CI环境是再好不过的了，每个项目都有专人维护CI环境，各个项目的配置互不干扰。不过对于一些公司来说，这显然有些浪费，BuildBot Master的资源消耗是不大的，我们完全可以使用一套BuildBot Master来服务于多个项目，至少BuildBot是可以支持这样做的。 ...
在“使用BuildBot搭建持续集成环境”一文中我曾经说到：公司使用的mail服务器只支持SSL连接，而BuildBot似乎对SSL连接的支持有些问题，导致构建结果mail无法发送“。BuildBot实际上使用的是Twisted的mail库来发送邮件的，我下载了Twisted的一些mail发送的例子程序，并使用我的公司mail账户配置，但依旧发送失败。看来这个问题与Twisted的实现有关了。 这个问题已经折腾我许久了，难道非得让我去debug Twisted库？还好，今天我想到了另外一种方法：使用stunnel。原理是这样的：通过stunnel将非SSL连接转换为到公司mail服务器的SSL连接，通过stunnel建立的这条转化通道，mail发送的问题就应该可以解决了。想法归想法，实际上能否达到我的目标，还得通过试验验证。 首先我们需要在BuildBot的master服务器上安装stunnel。 ...
部门的持续集成一直做的不太好，我们开发部这边甚至一直没能做起来，这其中有各种原因：工具、意识、执行力、沟通等等。将持续集成引入到我们的开发过程中也一直是我的一个目标。去年末启动的一个项目让我感到时机变得成熟了。 新项目的代码是完全重写的，这样的机会甚是难得。因为大多数情况下大家都是在维护现有系统：做些添添补补、修正Bug以及优化之类的事情。项目初期，我特别向大家强调了要严格遵守统一代码风格并将astyle代码格式化工具介绍给大家，手把手地教大家如何利用类似LCUT这样的单元测试框架编写单元测试，讲解什么是Mock测试。前些时间我又将代码风格检查 脚本加入到工程的构建过程中，并将代码风格检查作为最终构建目标的关键依赖，强制大家编写出统一风格的代码。 ...
我所在的项目一直以C语言作为主要开发语言，与做Java以及其他新兴语言的人不同，组内的同事似乎对新鲜的东西不是那么感兴趣，也没有主动去研究新鲜事物的意愿和意识。我深为此闹心，看到外面世界中那么多美妙的工具，再也不能坐以待毙了。我一直都是有很多想法的，但是迫于自身精力有限，自己无法全身投入，以前都是交予别人去做的，但是收到的效果都不是很好。认识到这点后，我决定自己动手，丰衣足食。 ...