In 91

前言
在我的Blog上，已經介紹了許多與團隊開發、軟體品質測量、測試等相關工具，就如同一顆一顆的龍珠，散落在整個開發團隊的各個角落。傳說中把這些龍珠集中到CI上，就能召喚出神龍，並對神龍許下維持系統品質的願望。

這篇要介紹的，就是這一系列最後一塊拼圖：持續整合(Continuous integration, CI)。CI是一種概念，也是驅動所有系統品質工具的引擎。

有了CI，不懂技術的管理者，可以光看報表就知道系統的健康狀況。
有了CI，團隊開發時可以及早發現，在整合上是否有所問題。
有了CI，每個developer早點嗅出程式與系統的壞味道。
有了CI，可以讓整個團隊成員有共同的基底、共同的標準、共同協同合作的平台。
有了CI，可以貫穿整個系統開發生命週期，為了品質所花的任何一份力氣，都不會白費而有所累積。

CI是一層品質的防護網，這層防護網是將其他每個維持品質的工具組織起來，整合起來，不斷不斷的持續整合，並即時產生回饋給所有成員。

玩過一次CI，你就會愛上它。用了它，你就會不能沒有它。CI可以寫一整本書，這篇文章只針對一些概念作簡介。

抽象概念
CI的抽象概念，用一張圖就可以表示：

(圖片來源：Continuous Integration: Improving Software Quality and Reducing Risk)

CI就像鍵盤上的enter鍵這麼自然，在每一次的變更，CI server都幫我們整合所有相關的服務，並將結果回饋給整個團隊，就像隨時隨地都有一個醫生在幫系統作全身健康檢查。

檢查項目包括了：

1. 建置source code（也就是Auto Build）
2. 執行測試（各種自動化測試）
3. 執行程式碼分析（包括靜態與動態的程式碼分析）
4. 自動部署（強調單鍵部署、單鍵還原，或是不用按按鍵，且應能區分dev環境、qa環境與prod環境）
5. 資料庫整合（初始化資料、還原資料、更新資料庫Schema等等...）

並用不同的方式，回饋給整個團隊。如：

1. 各種檢查工具產生的分析結果，轉換成圖表、網頁、存入資料庫。
2. 將上述結果通知團隊各個成員，並可觀察趨勢，可與上一次分析結果比較。
3. 將多個專案以透明化且數據化的方式，呈現系統品質，找出專案管理、系統設計、瑕疵追蹤等等重要的趨勢與現象，及早採取改善措施。

核心概念就是一句話：『Build software at every change』。

CI的架構圖
如下圖：

(圖片來源：Continuous Integration: Improving Software Quality and Reducing Risk)

在整個CI中，最重要的，也是第一步，就是Version Control Repository，通常稱為版本庫。（版本庫的相關議題可以參考：[軟體工程]版本控管的重要概念）軟體開發可以沒有CI，不能沒有版本庫！By the way，這張圖上只是以SubVersion當作範例。

版本庫，是整個開發團隊的基底，也是唯一的標準。只有在版本庫上面的source code，可以拿來討論、比較、說明，不論是開發、測試、部署，都要以版本庫上的為準。

在我自己的認定中，我認為CI是整個架構與觀念的呈現，CI server只是個集散地與引擎。

CI server在其中CI中扮演的角色，只有三個：

1. 定時檢查版本庫是否有更新。
2. 透過Build Tool(Build Script)，驅動各項品質相關工具（包括建置、測試、分析、部署），產生分析結果。
3. 將分析結果回饋給團隊。

A day in the life of CI

1. 坐到座位上，打開電腦，看到CI最新的建置成功結果。
2. 看到了相關的測試、分析結果。
3. 接著請接到版本控管的相關步驟：
   1. 從版本庫取得最新版本的程式，一定要可以建置成功
   2. 將要修改的程式簽出（檔案鎖定式的VCS）
   3. 修改完程式
   4. 從版本庫更新最新版的程式，若有conflict則merge
4. Private Build，將版本庫上最新的source code（包括Unit Test）建置並執行單元測試，並通過其他Checkin policy規範的rule，checkin最新的程式到版本庫上。
5. 一段時間後，CI server檢查到版本庫上有更新，則更新最新版的source code，執行Build Script，產生建置、測試、分析與部署的相關結果。
6. 所有成員（或依結果等級決定哪些成員該收到）收到相關的email。

CI feature

1. Automated：自動化，不需人工介入。
2. Build：包括建置、測試、分析、部署甚至產生相關文件（例如根據最新source code產生API document）
3. Continuous: CI一旦啟動，就持續活著。
4. Continuous integration: 至少每天(Daily build)整合各項服務，儘早發現defect。

Base on CI的開發團隊feature

1. 頻繁簽入，至少每天會checkin一版。
2. 不會從版本庫上get下來不能跑的程式，任何新加入的成員只要從版本庫上get下來就可以build。
3. 不會checkin不合規定的code。
4. 一旦發生因為同時簽入造成的建置失敗問題(包括測試失敗)，每個成員都會知道，並用最短的速度修復。
5. 自動測試的門檻降低。
6. 品質指標門檻與測試結果都必須通過。
7. 養成良好的簽入、簽出、private build的習慣。

CI的目的

1. 降低風險。
2. 減少人工手動的繁複程序。
3. 可隨時產生一版可部署的版本。
4. 增加系統透明度。
5. 建立團隊信心。

CI工具的介紹

1. TFS
2. Hudson
3. TeamCity
4. CruiseControl
5. CruiseControl.NET

摘要比較：

1. TFS，要錢，Total Solution，與其他工具比是最完整貫穿整個ALM的工具。從需求分析開始，系統分析、Work item checking、版本庫、程式碼分析、測試、產生分析報表、建置、部署、bug tracking，都包含在裡面。（這麼完整的功能，就不難想像為什麼要收費）
    
2. Hudson，免費，產生的圖表介面相當好懂且平易近人，與多種語言平台相容性高，社群有開發不少外掛供使用。
   [註]沒記錯的話，Hudson好像也被Oracle買走了，所以現在大部分都是改用Jenkins。
    
3. TeamCity，免費，簡單、快速建立，與JetBrains工具整合度高。
    
4. CC與CC.NET，免費、陽春、單純。

以上的比較，又是open source與total solution的比較，就不再多說了。
其他相關用的到的Tool，請參考Reference裡面第3個reference：DZone Refcardz: Continuous Integration Servers and Tools

結論
再次強調，CI是這整個系列的核心引擎，以版本庫為基底，是整個系統在開發生命週期中，各個團隊共同的平台，整合了不只是服務，更整合了團隊。高透明化與數據化的分析報告，更是專案管理不可或缺的基底。

一個系統開發過程，沒有CI，說要有多高的品質都是唬爛的，由此可見CI之於系統品質有多重的代表性。

Reference

1. Continuous Integration: Improving Software Quality and Reducing Risk
2. Continuous Integration in .NET
3. DZone Refcardz: Continuous Integration Servers and Tools
4. DZone Refcardz: Continuous Integration-Patterns and Anti-patterns
5. 軟體構築美學

第一個reference比較完整（本篇文章的圖片來自於此reference），第二個reference比較實戰。第三個與第四個都是DZone上的Cheet Sheet，很像彩版雜誌，適合拿來做簡報。

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/