若是你有足夠的主機資源和人力資源,那爲每一個項目單獨搭建一套CI環境是再好不過的了,每一個項目都有專人維護CI環境,各個項目的配置互不干擾。不過對於一些公司來講,這顯然有些浪費,BuildBot Master的資源消耗是不大的,咱們徹底能夠使用一套BuildBot Master來服務於多個項目,至少BuildBot是能夠支持這樣作的。html
CI環境中,咱們首要關注的就是源碼庫。多個項目可能各自使用單獨的源碼庫,也可能共享一個源碼庫並經過目錄隔離和識別。不管怎樣,咱們均可以經過BuildBot Master的配置來知足咱們的要求。app
若是說多個項目共享一個源碼庫或是一個項目下的多個子系統放在一個源碼庫中,這時咱們在配置change_source時指定一個變動監測器便可,這個監測器的監測範圍從源碼庫的根路徑開始。以Subversion源碼庫爲例,咱們能夠這樣來配置:svn
c['change_source'] = [SVNPoller("svn://10.0.0.1:3000",
svnuser='tony',
svnpasswd='tony',
pollinterval=60,
split_file=change_path_split)]post
咱們經過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 Noneui
不一樣項目下的文件變動,會致使change_path_split返回不一樣的值,而change_path_split返回值會被用於匹配不一樣的Scheduler:spa
c['schedulers'].append(Scheduler(name="foo-ci-plan",
branch='foo_proj/trunk',
treeStableTimer=5,
builderNames=["foo-redhat-builder", "foo-x86-solaris-builder"]).net
c['schedulers'].append(Scheduler(name="bar-ci-plan",
branch='bar_proj/trunk',
treeStableTimer=5,
builderNames=["bar-redhat-builder", "bar-x86-solaris-builder"])rest
上面各個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有利有弊,其不足之處可能有以下幾點:
一、項目過多時,可能存在潛在的性能問題
二、Master的配置被多個項目共享,存在潛在的Conflict問題;
三、另外master.cfg可能size過大,也不利於閱讀和維護。