目前分類:專案管理 (2)

瀏覽方式: 標題列表 簡短摘要

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

轉貼自 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 也需要有跟上面對應的工作。

 


文章標籤

藍色小惡魔 發表在 痞客邦 留言(5) 人氣()

雖然沒內容範例,不過還是可當作初步的參考資訊,原網站文章很單薄,預防網站關閉所以轉貼到小惡魔網站,如果有不妥請來信告知,將立即刪除內容。

一 策略規劃     

文章標籤

藍色小惡魔 發表在 痞客邦 留言(0) 人氣()