多数公司不会仅有一个项目，当你为一个项目引入持续集成实践后，其他项目就会接踵而来。这时你会重新考量BuildBot，考虑如何让BuildBot可以服务于多个项目。

如果你有足够的主机资源和人力资源，那为每个项目单独搭建一套CI环境是再好不过的了，每个项目都有专人维护CI环境，各个项目的配置互不干扰。不过对于一些公司来说，这显然有些浪费，BuildBot Master的资源消耗是不大的，我们完全可以使用一套BuildBot Master来服务于多个项目，至少BuildBot是可以支持这样做的。

CI环境中，我们首要关注的就是源码库。多个项目可能各自使用单独的源码库，也可能共享一个源码库并通过目录隔离和识别。无论怎样，我们都可以通过BuildBot Master的配置来满足我们的要求。

如果说多个项目共享一个源码库或是一个项目下的多个子系统放在一个源码库中，这时我们在配置change_source时指定一个变更监测器即可，这个监测器的监测范围从源码库的根路径开始。以Subversion源码库为例，我们可以这样来配置：

c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=change_path_split)]

我们通过change_path_split来拆分变更文件的路径，假设SVN库结构是这样的：
svn://10.0.0.1:3000
       – foo_proj
           – trunk
               – main/main.c
           – branches
           – tags
       – bar_proj
           – trunk
               – main/main.c
           – branches
           – tags

我们可以这样来实现change_path_split：

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

不同项目下的文件变更，会导致change_path_split返回不同的值，而change_path_split返回值会被用于匹配不同的Scheduler：

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

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

上面各个Scheduler的branch属性会与change_path_split返回值元组中的第一个元素匹配，这样foo-ci-plan便是foo_proj的scheduler，而bar-ci-plan则是bar_proj的scheduler。这样某个项目路径下的文件变更只会触发对应的scheduler开始工作，不会出现误触发。

如果多个项目或一个项目的多个模块使用不同的源码库，同理，我们可以为c['change_source']赋予多个SVNPoller，例如：
c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=change_path_split)，

                      SVNPoller("svn://10.0.0.1:4000",
                                svnuser='tony',
                                svnpasswd='tony',
                                pollinterval=60,
                                split_file=another_change_path_split)]

与Scheduler的匹配方式也与上述描述一致，这里就不重复说明了。

不同项目的干系人多不相同，那么集成的结果是如何准确地反馈给项目各自对应的干系人呢？以Mail反馈通知为例，我在BuildBot手册中找到了两种方式，一种方式是通过设置Scheduler的owner属性，然后指定MailNotifier的sendToInterestedUsers=True，意图让BuildBot将Mail通知发到owner list中的每个邮件地址，但经测试后发现，这种方式似乎不好用，不知道是否是BuildBot对该功能的实现上存在问题。

另外一种方式则是配置多个MailNotifier。每个MailNotifier中指定对应builder的名称列表，并通过extraRecipients指定这些Builder对应的项目的干系人Mail地址列表，例如：

c['status'].append(mail.MailNotifier(fromaddr="foo-buildbot@buildbot.net",
                                     extraRecipients=["foo1@buildbot.net", "foo2@buildbot.net"],
                                     builders=['foo-x86-solaris-builder', 'foo-redhat-builder'],
                                     useTls=False,
                                     sendToInterestedUsers=False,
                                     relayhost="smtp.buildbot.net",
                                     smtpUser='tony',
                                     smtpPassword='tony',
                                     smtpPort=25))

c['status'].append(mail.MailNotifier(fromaddr="bar-buildbot@buildbot.net",
                                     extraRecipients=["bar1@buildbot.net", "bar2@buildbot.net"],
                                     builders=['bar-x86-solaris-builder', 'bar-redhat-builder'],
                                     useTls=False,
                                     sendToInterestedUsers=False,
                                     relayhost="smtp.buildbot.net",
                                     smtpUser='tony',
                                     smtpPassword='tony',
                                     smtpPort=25))

这样foo的builders构建的结果将发到foo1和foo2；而bar的builders构建结果将反馈到bar1和bar2。

多个项目共享一套BuildBot Master有利有弊，其不足之处可能有如下几点：
1、项目过多时，可能存在潜在的性能问题
2、Master的配置被多个项目共享，存在潜在的Conflict问题；
3、另外master.cfg可能size过大，也不利于阅读和维护。

最近观察到这样一种情况，项目组内的两位比较资深同事似乎都习惯于这样来编码：他们可能会花上两、三周时间将一个模块的成百上千行代码一气呵成的编写完，然后再去与其他人编写的代码集成在一起编译，测试，最终提交。这种情况让我有些惊讶，因为我觉得一个良好的编码节奏不应该是这样的，原因有三：

.这样的节奏不利于问题的早发现早解决

 我们都知道问题发现越早，其解决成本越小。如果只是一味地编写代码，甚至连一次编译都不做，又怎么可能尽早发现自己代码中的问题？怎么可能提早发现其他人的提交对你的模块可能带来的影响呢？这样下去的最终结果很可能是大量的返工或某个隐藏很深的问题，需要花费你较大力气去解决。

.这样的节奏还可能会导致激情疲劳

 激情也会产生疲劳。想必很多朋友都有过类似的经历：一旦长时间投入在一件事情上，如若没有阶段性的成果或者中途遇到一些挫折，那激情也会疲劳，甚至是丧失。程序员都是很有激情的！你一定见过那些整天以方便食品度日，为了某个功能奋战N天N宿的蓬头垢面的程序员们。他们埋头于键盘与屏幕间，将用智慧加工后的字符输入到计算机中。但程序员也是人，如果一直这么下去，没有阶段性反馈，渐渐地，他们的效率就会降低，思维就会僵化，最终导致结果远不如预期。

.这样的节奏不利于自身信心的建立

 在这样只有编码，没有编译，没有必要单元测试的情况下，你如何确保代码质量是没问题的呢？你是否敢于站出来对着大家说我编写的代码是牢不可摧的。显然你不能，因为你没有收到任何关于代码质量评估的反馈。甚至于你的代码是否可以正确地通过编译器的检查都未曾而知，你又哪里有对代码的那份自信呢？

好了，说了这么多原因，那什么样的节奏算是良好的节奏呢？用一句话概括就是“小步快跑，迭代进行，循序渐进”。其主旨在于划大为小、快速完成、快速反馈（通过构建、单元测试）、快速调整，依此循环往复。划大为小是基础，也是一种任务分解的能力；快速完成和反馈能让你及早发现问题，包括自身的以及与他人集成过程中的；快速调整意为迅速应对发现的问题，及时变更设计、重构代码，直至满足。这样每轮下来，你会发现已经完成的任务都是相对健壮的，这种健壮同时也会给你一种正面的反馈，让你保持继续的激情和动力，同时也会给你带来充足的信心。这样一轮一轮下去，你就会持续不断地得到正反馈，这会促使你最终得到一个相对比较健壮的成果物，你的信心也会因此得到倍增。

如果你和我的同事采用了同样的编码节奏，那你不妨尝试调整一下^_^。