使用buildbot實現持續集成（轉載）

轉載自：http://www.oschina.net/p/buildbot

 

使用 Buildot 實現持續集成

使用基於 Python 的工具實現持續集成的理論與實踐

牛仔式編碼的日子在大多數組織中早已不復存在，由一種優質軟件建立新潮所取代。持續集成（CI）測試是敏捷的編程方法實踐中一個相當重要的部分，可以實現高品質軟件。經過探索 Buildbot 來學習 CI 測試的理論和實踐，Buildbot 是用 Python 編寫的一個開源 CI 系統。

 

持續集成（CI）是發揚如下原則的一個軟件開發流程：

維護單源存儲庫

自動化構建過程

實現自測試構建

每一個人天天都有貢獻

每一份貢獻都應用於在一個集成機上構建主線

加快構建過程

在一個相同的生產環境中執行測試

使任何人均可以簡單獲取最新的可執行文件

每一個人均可以看到當前情況

自動化部署

經 Martin Fowler 大力普及，CI 的基本理念就是持續測試並構建每一個分支程序和將分支代碼合併後的軟件。這能夠從整體上提升代碼庫的健康情況。還能夠增長與團隊成員的交流，並有機會獲取對代碼總體質量的反饋。人們一般使用這個週期來生成代碼覆蓋報告和其餘統計信息。

Buildbot 相似於其餘 CI 系統，有助於自動化這個檢查、構建和測試流程。Buildbot slaves 一般運行於不一樣的平臺，好比 Win3二、Solaris、Intelx64 等。當一個構建（build）中斷時，Buildbot 能夠發送一個電子郵件通知，它追蹤全部運行中的構建，這樣開發人員就能夠鳥瞰整個流程。最後，人們經常利用自動化週期構建既定時間內軟件質量的度量標準。本文結尾將談及該度量標準以及在一個 CI 系統內運行它們的緣由。

Buildbot 簡介

在咱們深刻探討 Buildbot 以前，先看一下其架構。如圖 1 所示，在構建流程的頂部主要有三個層。首先是一個版本控制層，它從一個版本控制系統鉤入通知。其次是一個構建層，它從構建主服務器那裏獲取通訊，並返回構建結果。最後是一個通知層，用於在構建失敗時發送電子郵件或一個 IRC 消息，或讓一個 web 頁面顯示構建的累積結果。

圖 1. Buildbot 架構概覽

Buildbot 架構的中心特性之一是對基於 Python 的 Twisted 庫的依賴性，用於處理主服務器（master）和伺服機（slave）之間的異步通訊。這個基於回調的架構支持一個很簡單、但健壯的主/伺服反饋圈。在本文後面的 參考資料 部分能夠找到有關 Twisted 的更多信息。

若是您還沒有據說過 Buildbot，在 Google 上搜索一下就會找到大量與大小開源項目相關的主服務器和伺服機。關於伺服機，我在前面簡單地說起了一下，它本義上是一個由主 Buildbot 服務器控制的伺服機器。通常來說，一個伺服機是多個運行不一樣測試平臺的伺服機之一。這是 Buildbot 服務器中一個很重要的概念。例如，您可能在一個開源項目的郵件列表上，聽到有人說，「有人自願充當 Windows 伺服機的虛擬機嗎？」

Python 語言項目自己使用大量 Buildbot 伺服機，在儘量多的平臺上持續構建和測試最新版的 Python。圖 2 顯示了運行 Python 主幹的許多伺服機以及測試。隨着虛擬化技術的發展，如今能夠經常要求開發社區成員託管一個 Buildbot 伺服機，或僅僅運行模擬不一樣硬件配置的幾個虛擬機。

圖 2. Python Buildbot；參見 放大圖

另外一個備受矚目的 Buildbot 用戶是 Google Chrome 瀏覽器項目。圖 3 顯示了一個高度定製的 Buildbot，它極大地加強了 Buildbot 用戶界面的外觀。幸運的是，Google 將這些加強的開放代碼提供給 Buildbot，從下面的 參考資料 部分，您能夠獲取源代碼並構建這個定製版本。

圖 3. Google Chrome 加強的 Buildbot；參見 放大圖

構建這個配置不在本文討論範圍內，可是我建議您本身看一下。如今咱們看一下如何使一個 Buildbot 主服務器快速運轉起來。

 

---

 

 

5 分鐘內設置 Buildbot

 

我在 Ubuntu 8.10 上執行了這幾步，不過它們應該在大部分 Linux 系統上都適用：

 

1. 下載 ez_setup.py： wget http://peak.telecommunity.com/dist/ez_setup.py
2. 安裝 easy_install： sudo python ez_setup.py
3. 使用 apt-get 安裝 Python Twisted 包 sudo apt-get install python-Twisted
4. 遵循這個 collective.buildbot 「祕訣」： sudo easy_install collective.buildbot

 

此時，許多東西開始涌出 shell，由於有一大堆包被下載且獲得自動安裝。完成這些步驟以後，就能夠開始建立 Buildbot 了！若是安裝過程進行得很順利，在 shell 提示符處輸入：

 

$ paster create -t buildbot my.project $ cd my.project

 

如今設置已經快完成了，但在完成以前，我要提幾個在首次配置 Buildbot 時您容易出錯的地方。在您的 my.project/master.cfg 文件中，應該能夠看到如下內容：

 

清單 1. master.cfg 內容

[buildout]
master-parts =
    master
    passing.project
# uncomment this to enable polling
    poller

[master]
recipe = collective.buildbot:master
project-name = passing.project project

# allow to force build with the web interface
allow-force = true

# internal port
port = 9051

# http port
wport = 9081

# buildbot url. change this if you use a virtualhost
url = http://localhost:9081/

# static files
public-html = ${buildout:directory}/public_html

slaves =
    localhost NaOaPSWb

[passing.project]
recipe = collective.buildbot:project
slave-names = localhost
vcs = hg
repositories = /home/ngift/myhgrepo

# notifications
mail-host = localhost
email-notification-sender = buildbot@cortese
email-notification-recipient =
    super@example.com

# run test each hour
periodic-scheduler=60

# cron build
cron-scheduler = 0 8 * * *


# You can change the sequences to build / test your app
# default options should work for most buildout based projects
build-sequence =
#    /usr/bin/python2.5 bootstrap.py -c project.cfg
#    /usr/bin/python2.5 bin/buildout -c project.cfg


test-sequence =
    nosetests
# zope.testing require exit with status
#    bin/test --exit-with-status

[poller]
recipe = collective.buildbot:poller
# don't forget to check this
# since it's generated from the paster template it may be a wrong url
repositories = /home/ngift/myhgrepo
#user = h4x0r
#password = passwd
poll-interval = 120

最初檢查最重要的內容是確保有合適的源控制存儲庫，一開始將 build-sequence 留空，當代碼遷出您爲它提供的存儲庫時，您的 test-sequence（在個人例子中是 「nose」）會經過測試。若是您有其餘問題，請查閱 collective.buildbot 資源指南（參閱 參考資料 對該指南的連接）。

設置好配置文件以後，只需運行下面兩個命令：

$ python bootstrap.py $ ./bin/buildout

在運行 buildout 命令時，您會看到如下輸出：

清單 2. buildout 命令的輸出

{673} > ./bin/buildout
Unused options for buildout: 'master-parts'.
Installing master.
New python executable in /home/ngift/my.project
Installing setuptools............done.
[output suppressed for space]

該命令結束以後，您就完成了 Buildbot 的安裝，如今就可使用它了。運行如下 shell 命令啓動 Buildbot 守護進程：

$ ./bin/master start $ ./bin/yourhostname start

若是您在瀏覽器中輸入在主 .cfg 文件中設置的 URL，默認狀況下爲 http://localhost:9081/，您會看到全新的 Buildbot。固然，它如今可能尚未多少功能。若是您爲它提供一個構建腳本和一個測試運行程序，它會很樂意檢查、構建並自動測試您的代碼。固然，您稍後應當瀏覽一些配置選項，但最難的部分已經完成了。

 

---

生成代碼度量報告

「測試迷」 中一個最新的智能開發，是要利用持續集成周期來生成有關源代碼的度量。其中一種最流行的方法是運行帶既定選項的 nosetest 測試收集器。若是您有一個名爲 「foo」 的項目，您一般會運行：

nosetests --with-coverage --cover-package=example --cover-html \ --cover-html-dir=example_report.html test_example.py

這會生成一個 HTML 報告，顯示未涉及的全部代碼行，以及相似於清單 3 的 stdout 的輸出：

清單 3. nosetest 輸出

nglep% nosetests --with-coverage --cover-package=example
      --cover-html-dir=example_report.html test_example.py
.
Name      Stmts   Exec  Cover   Missing
---------------------------------------
example       2      2   100%
----------------------------------------------------------------------
Ran 1 test in 0.004s

OK

您能夠從 下載 部分下載 example.py 和 test_example.py。

每次修改代碼後都運行這個報告，爲開發人員和管理人員提供有關代碼變化的元數據。這是展現爲什麼同時運行度量標準的一個絕佳例子，由於 CI 對一個項目有好處。

另外一個提供代碼元數據的度量工具是 PyMetrics 的 McCabe 評定。早在20 世紀 70 年代，Thomas McCabe 就提出一個簡單、但首創性的代碼觀察結論：一段代碼越複雜，它中斷的可能性就越大。這雖然看起來很明顯，但遺憾的是，不少開發人員彷佛看不到其中的聯繫。使用 PyMetrics 的命令行工具，您能夠肯定每一個函數的分支數。

一般，您但願將編寫的每一個方法或函數的分支數保持在 10 如下，由於在人腦中保留 7 或 8 分內容很難。相似的，大於 50 段的代碼基本上是沒法測試/沒法維護的。

我就親眼看到過 140 多段的代碼，代碼不好，它確實驗證了 McCabe 的理論。若是您能夠在開發前期捕獲和標記這個複雜、脆弱的代碼，那麼即便全部測試都經過，它也不會出如今生產環境中。

---

結束語

持續集成的主要優點是，可以經過軟件的自動化構建以及測試和軟件度量標準（可選）精簡品質保證週期。每次更改源代碼併爲項目生命期提供即時反饋和報告時，都會觸發構建。當 CI 獲得正確配置時，它實際上就集成到代碼生成過程當中，如同親自參與編寫代碼同樣。

Buildbot 並不是用於 CI 測試的唯一工具。您也能夠了解一下 Hudson 和 Bitten。它們都支持使用 Python 插件進行定製，即便 Hudson 是用 Python 編寫的。參閱如下的參考資料，詳細瞭解這些系統相關內容。