iT邦幫忙

DAY 29
4

如何提升系統設計品質 - 技術與工具以.NET為例系列 第 29

[如何提升系統品質-Day29]基礎建設-持續整合(CI)

前面一整個系列所介紹到的工具,都如同一顆一顆的龍珠,散落在整個開發團隊的各個角落。傳說中把這些龍珠集中到CI上,就能召喚出神龍,並對神龍許下維持系統品質的願望。灑花

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

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

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

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

[如何提升系統品質]系列文章連結
抽象概念
CI的抽象概念,用一張圖就可以表示:

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的架構圖
如圖:

在整個CI中,最重要的,也是第一步,就是Version Control Repository,通常稱為版本庫。(版本庫的相關議題可以參考:[如何提升系統品質-Day15]基礎建設-版本控管的重要概念)軟體開發可以沒有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,免費,產生的圖表介面相當好懂且平易近人,與多種語言平台相容性高,社群有開發不少外掛供使用。

3.TeamCity,免費,簡單、快速建立,與JetBrains工具整合度高。

4.CC與CC.NET,免費、陽春、單純。

以上的比較,又是open source與total solution的比較,就不再多說了。

其他相關用的到的Tool,請參考引言第3個reference。

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

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

後記
基本上這篇文章除了自動部署的部分以外,其他相關的概念與工具介紹,在這一系列鐵人都介紹到了。(請稱呼我品質鐵人 哈哈)對自動部署有興趣的朋友,可以找一下另一個term: Continuous Delivery,將自動部署也加到CI驅動的另一塊模組,整個系統開發生命週期將更加流暢,讓每個團隊角色都可以更專心的做自己該做的事。


上一篇
[如何提升系統品質-Day28]Performance
下一篇
[如何提升系統品質-Day30]Code Review與總結
系列文
如何提升系統設計品質 - 技術與工具以.NET為例30

尚未有邦友留言

立即登入留言