[筆記] CI：Continuous Integration 持續整合－藍色小惡魔

因為準備轉換跑道，在公司交接期間有點空閑的時間，整理一下積塵已久的筆記，發現這篇文章連結已經失效了，所以就將內容轉到公開的討論區，順便整理一下內容，以便繼續幫助有需要的人。

轉貼自 http://josephjiang.com/entry.php?id=251 的 Google 庫存頁面

今天 Chief Architecturer Raymie 來台演說最近公司持續在做的 Continuous Integration（簡稱 CI），整理一下上課筆記：

什麼是 Continuous Integration？

軟體開發常見的問題就是不同的開發人員不斷地增加 Code，但卻缺乏規範及完整測試，所以經過一段時間的累積程式往往變的難以辨認及維護、其他人也沒辦法接手；或者由於規模變大必須要對程式做翻新以因應需求。所以我們最常有的想法就是「打掉重練」，常常因此而浪費了許多的時間。

CI 主要概念：

1. 開發人員將程式碼拆分成小、易維護的片段；
2. 開發人員針對這些片段做測試（例如 Code Sniffering、Documentation、Unit Testing）;(小惡魔補充：可以的話UT最好也要自動化。)
3. 開發人員每天 Commit 程式到版本控管系統上；(小惡魔補充：這點一定務必要取得共識與認同後嚴格執行！養成習慣。)
4. 系統會自動每天在下班時，將程式從版本控管系統上 Update 下來，並經過所有相關測試與工作，產出 Nightly Build 與一份報表（例如 Code Coverage 與錯誤、警告的地方）。
CI 的好處。(小惡魔補充：這一定要搭配自動測試，這樣CI做起來功效才會大！)

藉由這樣的流程讓參與的開發人員可以從整體檢驗自己的程式，例如是否跟別人有相衝突，也可以在第一時間解決 Bug，不需要等到 QA 階段或上線後才發現。因此我們隨時都有一個前一天的環境來觀看錯誤、持續修正。
另外由於開發者需持續地符合規範、寫文件、做測試，即使哪天原本的人不在了，接手的人在工具一致、規範一致的情況下也可以馬上上手。而程式未來需要因應成長來改寫時也會相對簡單且變動小。

成功整合 CI 的衡量點

公司內衡量整合 CI 是否成功有以下幾點：
1. 是否使用一致的 VCS(Version Control System)？（我們團隊決議：一律需要轉換到 SVN ）
2. 是否使用一致的 Tool ? （我們團隊初期使用 Hudson，後來轉用Jenkins，最後集團由上向下推IBM Rational，但在我離職前未成功完成CI實現...）
3. 建立 Build 是否夠快速 ? （我們團隊標準是 10 分鐘做完所有事情）

目前已經做的 CI
(現在應該改為之前已完成的，因為後來被Rational攪局，就架構就沒繼續沿用和轉移，新平台也還在摸索，在小惡魔離職前未見成效...)

這邊較有趣的部份是在 Tool，Hudson 我得找時間了解，據說是個可以安裝很多 Build Plug-ins 的 Framework。目前我們 Team 還沒整合 Hudson，不過有些地方已經開始在做了，像是：
1. 考量 build 的目錄架構；
2. 規定 Coding Convention 將 Code 改寫持續用 PHP_CodeSniffer 來掃；
3. 將 Function 加上 Documentation 用 Doxygen 產生文件；
4. 撰寫 Unit Test Case，用 phpUnit 來跑；
5. 抽 Interface 讓未來的 Scalability 增加；
6. 持續還要做的會是整合 Hudson、自動化打包流程、前端的 JavaScript / CSS 也需要有跟上面對應的工作。

結語

我覺得很好玩，因為是在做對的事情，也比較像是軟體公司應該要有的方向。而 Raymie 也提到我們應該也把 CI 過程中產生的 Best Practice 分享給 Open Source Community。這個點子不錯，當大家的想法接近時，往往可以獲得更多的回饋。

原始 Continous Integration 的概念：http://martinfowler.com/articles/continuousIntegration.html

2016更新：以上是2010年的進度記錄，後來不但完成了，而且還以Hudson為基礎和建置的經驗，又成功將系統轉移使用Jenkins，由於此篇只是想把舊的心得筆記整理一下，而且執行的人是組員，小惡魔也只能講講最後的成果和心得，就是對我管理產品和專案開發有莫大的幫助，CI真的一定要搞，你的團隊和產品一定會越來越大，越早導入越輕鬆，等團隊大了就嘴雜，產品大了就處處牽制！