一、介紹
1. buildbot是一個開源的基於python的持續集成系統，它能夠以下三種方式觸發相應的自動構建和測試運行，從而迅速的發現問題所在，同時指出造成這個錯誤的開發人員，當然我們還可以通過頁面直觀的了解到當前所有和master綁定的任務以及各種測試狀態。
1) 監控代碼管理庫的變化從而觸發構建測試任務
2) 通過配置從而定時觸發構建測試任務
3) 通過配置從而允許強制觸發構建測試任務
2. 因為它有很多比較好的特點：
1) 跨平台：可以運行在各種平台上，實現不同平台上的測試
2) 可以處理各種語言編寫的程序,例如C，Java，Python
3) 環境要求低並且配置簡單：僅僅需要Python，和網絡庫Twisted
4) 結果的交付方式多，例如Email，webpage，IRC或者其他協議工具
5) 通過子類繼承並重寫父類從而靈活的配置
6) 很好的實現了分布式部署和集成工作
所以目前有很多大公司都在使用這個系統，比如
1) chrome : https://chromium-build.appspot.com/p/chromium/console
2) webkit : http://build.webkit.org/waterfall
二、系統基本原理
1.系統整體架構
buildbot主要由一個buildbot-master和一個或者多個buildbot-slave兩部分通過網絡拓撲結構中的星型結構連接而成，如圖：
注意：由於歷史原因，很多情況下，我們都直接稱buildmaster為buildbot，而buildslave稱呼不變。
下面我們通過上面這幅圖來詳細了解下各部分的作用吧。
1) Repository ：代碼管理庫，用於團隊開發的代碼管理和版本控制，目前流行的有svn，cvs，git……
2) Buildmaster：主要負責分派並且告訴slave什么時候進行測試，怎樣進行測試，進行什么樣的測試，可以說是一個決策中心，而這個決策中心的核心在於master.cfg這個配置文件，它其實是一個用python語法來寫的配置文件（配置文件后期會進行講解）。
3) Buildslave : 負責根據buildmaster下發的Command命令執行測試，同時將執行狀態和結果返回給buildmaster
4) Notifiers ：當BuildMaster接收到BuildSlave的執行結果后觸發Notifiers，根據配置的方式將結果交付。
2.BuildSlave、BuildMaster、Repository間的通訊
1) BuildSlave通常運行在一台或者多台不同的獨立的機器中，這些機器可以有不一樣的系統，具體根據你的興趣和需求而定。然后這些BuildSlave機器都是通過TCP連接到BuildMaster機器的公共端口進行通訊的。當然這些機器和buildmaster或者Repository之間不一定必須直接相連，中間可以有一些簡單的防火牆機器，只要不妨礙builslave和buildmaster、Repository之間的通訊即可。
2) 他們三者間的TCP連接，都是由BuildSlave主動發起的
3) 所有的命令都只能由BuildMaster下發到BuildSlave，而且不管是BuildMaster下發的命令，還是BuildSlave上傳的結果都是通過TCP連接進行傳輸的
4) BuildMaster並不提供源代碼，因此BuildSlave需要源代碼的時候必須能夠連接到Repository 進行相應操作。
2.BuildMaster的架構
Buildmaster由以下四大部分組成，如圖，假設我們的Repository是VC Repository:
下面我們來簡單介紹下上面的每個部分的用途，這些在master.cfg中都能夠進行配置的：
1) ChangeSources：Scheduler的觸發源，每當VC Repository發生了變動，就會創建一個Change對象提交給各個Scheduler
2) Schedulers : 決定什么時候進行構建和測試任務，該Scheduler將會收集ChangeSources提交過來的Changes到BuildRequests中，當BuilderSlave可用時，就將這些changes排隊成Queue交付給Builders
3) Builder ：決定如何執行構建和測試任務,每一個Build只運行在一部機器中
4) SlaveBuilder : 多個SlaveBuilder組成一個BuildSlave。
5) Status plugins：用於交付構建結果的插件
從圖中我們還可以看出(注意BuildSlave和SlaveBuild是不一樣的哦)，
1) 每一個Builder是由一些列與他的構建任務相關的BuilderSlave組成的。這些BuilderSlave的地位是平等的，這么做的原因只是為了負載均衡
2) Builder將會在與它相關聯的BuilderSlave中創建一到多個SlaveBilder，這些SlaveBuilder是獨立運行在不一樣的文件夾中。
3) 多個Builder可以共享一個BuildSlave。
3.Buildbot的控制流程
從2.BuildMaster的架構章節中的那幅圖中，我們還可以看出BuildBot的整個控制流程。
1) 有這么一個開發人員，提交了一些改動了的代碼到Repository 中，然后builbot中的相關腳本監控到了就通過Email或者網絡連接將這些改變信息發送給了buildmaster，信息中包括了誰導致了這些變動，哪些文件被修改了，包含這些改變的版本以及一些其他的注釋。
2) buildmaster分配這些改變到不同的Scheduler，一些相應有配置的改變將會觸發tree-stable-timer開始計算，同時該改變被添加到一個新的Build中，當tree-stable-timer到了有效期，該Build將會被添加到一個Builder中並且運行在一個BuildSlave中，當然這個Builder中的所有Build構建運行測試任務用的都是同一版本的源代碼。
3) 這些Build又是由一系列的步驟Step構成的。每個Step都會包含一條甚至多條將會在BuildSlave機器中運行的命令。一般情況下，第一個Step都是從Repository中導出源代碼。接下來的一般都是進行編譯或者單元測試的。在執行過程中，所有的Setp都會將它們自身執行命令的結果以及狀態返回給buildmaster。
4) 當這些Build運行的時候，它們會將相應的如"Build Started", "Step Started", "Build Finished"這些命令打印到所有的狀態終端中。比如我們常見的waterfall。
5) 當一個 MailNotifier 狀態終端被激活的時候，一個build完成之后都會發送一封email通知相應的開發人員。當然我們也可以配置當且僅當運行失敗的時候才通知相應的開發人員。
4.狀態交付架構
BuildMaster維持着一個核心的Status對象，這個核心的Status對象連接着很多Status plugin，通過這個核心對象，我們可以獲取到每一層的所有構建狀態對象，如圖：
因此，每一個Status plugin都有一個引用指向圖中最頂層的那個核心Status對象，從而可以獲取到每一個Builder、build，Step甚至日志文件的信息。除此之外，當有新的Build創建時，Status還可以通過核心Status對象去監聽新的Build。