當紅炸子雞：Continuous Integration

CI 主要概念

1. 開發人員將程式碼拆分成小、易維護的片段。
2. 開發人員針對這些片段做測試（例如 Code Sniffering、Documentation、Unit Testing）。
3. 開發人員每天 Commit 程式到版本控管系統上。
4. 系統會自動每天在下班時，將程式從版本控管系統上 Update 下來，並經過所有相關測試與工作，產出 Nightly Build 與一份報表（例如 Code Coverage 與錯誤、警告的地方）。

CI 的好處

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

成功整合 CI 的衡量點

公司內衡量整合 CI 是否成功有以下幾點：

1. 是否使用一致的 Version Control ? （一律需要轉換到 SVN ）
2. 是否使用一致的 Tool ? （一律使用 Hudson）
3. 建立 Build 是否夠快速 ? （標準是 10 分鐘做完所有事情）

目前已經做的 CI

這邊較有趣的部份是在 Tool，Hudson 我得找時間了解，據說是個可以安裝很多 Build Plug-ins 的 Framework。目前我們 Team 還沒整合 Hudson，不過有些地方已經開始在做了，像是：

• 考量 build 的目錄架構。
• 規定 Coding Convention 將 Code 改寫持續用 PHP_CodeSniffer 來掃。
• 將 Function 加上 Documentation 用 Doxygen 產生文件。
• 撰寫 Unit Test Case，用 phpUnit 來跑。
• 抽 Interface 讓未來的 Scalability 增加。

持續還要做的會是整合 Hudson、自動化打包流程、前端的 JavaScript / CSS 也需要有跟上面對應的工作。

結語

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