http://blog.csdn.net/ostrichmyself/archive/2010/05/03/5551616.aspx
去年的公司從上至下全力推行持續集成, 各大部門, 各小部門, 個項目組, 強推持續集成, 彙報工作的第一句話: “你們的持續集成報表在哪? 發給我了嗎?”, 經過cruisecontrol集成過後的ICP-CI 成爲一道亮麗的風景。 各個部門委派代表參加公司的持續集成, 最後的我們部門的景觀是:三個小部門公用了一個持續集成環境, 持續集成的部署者只有一個, 小部門很多人還沒有弄清楚持續集成是什麼的情況下, 將代碼統統交給部署者進行CI——不管是已經完成的項目, 還是正在進行的項目, 都傾巢而出.最後, 領導對持續集成關心程度降低, 唯一的CI部署者的退出, 整個部門的持續集成徹底完蛋。
1. 持續集成的目的是提高代碼質量. 但僅僅是手段, 沒有重視代碼質量的高素質團隊, 持續集成最終會成爲花架子.
2. 持續繼承關注的指標需要有重點. 首推的是代碼重複的問題, 其次是單元測試, 後續的指標如圈複雜度, 代碼風格, CCT之類的, 應該緩行.
3. 持續集成, 是由團隊成員掌控, 不應該交給第三方, 團隊成員應該比領導更關注持續集成. 這樣纔可進行下去.
目前自己在團隊中推行持續集成, 並將實踐的進展逐步公佈, 經過和團隊的討論, 持續集成的流程如下:
1. 形如Cruisecontrol的思路, Ant腳本是管理持續集成的不二方法
2. 項目組屬於平臺性質的項目組, 項目繁多, 並且每個項目都涉及十來個插件工程, 各插件工程相對獨立. 解耦合是關鍵, 每個工程配備獨立的xml腳本, 在項目的維度上, 配備一個全局的xml, 定製各個需要的工程的xml.
3. 先compile, 後junit, 然後simian. 若無必要, 其它的不再作爲持續集成的指標
4. 綜合cuisecontrol的其它配置工具, 如發送報表, 發送郵件, svn等功能, 持續優化持續集成環境. 個人覺得, 一個好的計劃, 永遠是原型+ 持續優化. 就好比蓋房子, 先搭房子的框架, 最後纔是裝修. 框架即原型, 裝修即優化. 始終要有一個堅定的認識: 過早優化是萬惡之源.
未完待續.
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/ostrichmyself/archive/2010/05/03/5551616.aspx