2007年7月1日 星期日

(2007.6月號-161期)_持續性整合開發導論(下)

持續性整合的實踐:選用合適的CI伺服器

持續性整合開發可不是有了專案建置工具與貫徹測試優先原則就沒事了。要記住現在不是單打獨鬥的時代,講求團隊合作,因此不論是公司內參與的開發人員或者外部協同合作的廠商,都會對開發的成果產生重大的影響,因此如何即時掌握專案整體的開發狀況就是另一項挑戰。


Continuous Integration Server又稱CI伺服器,就是用來管理協同開發的持續性整合工具,目前常見的有:

  • CruiseControlJava社群中老字號的CI工具,擁有完整的CI所需功能。

  • Continuum:為Maven的子專案,算是後起之秀,設定方便為其優點。


CruiseControl它於2001年發佈已經有五年多的歷史,在許多方面,CruiseControl 伺服器 已經成爲持續整合的同義詞,完善的對大多數版本控制伺服器的支援並方便進行擴充,安裝容易也是其優點,如果硬要說個缺點的話就是CruiseControl對於專案持續性整合是基於XML的設定,非常靈活而且彈性,但對不熟悉的人來說,有點困難,包含的Web的管理介面,對於專案的掌控來說非常方便。


Continuum2005年發佈是最新的CI 伺服器之一,支援AntMaven1Maven2Shell進行專案的建置,也支援了大多數的版本控制伺服器,同CruiseControl一樣也擁有Web管理介面,並且可直接在Web介面上進行CI伺服器的設定,相對於CruiseControl來說比較方便,但以靈活度與擴展性來說,就比較差了,且因為推出時間較短,某些功能還不齊全。


到此我們可知完整的持續性整合開發環境至少必須架設版本控制伺服器與持續性整合伺服器,參考圖 1所示,開發人員與協力廠商開發平台持續對版本控制伺服器提交修改完成的程式碼,而通常在提交前會先取得目前最新的原始碼進行測試,當確認不影響版本控制伺服器上的原始碼後才進行提交。持續性整合伺服器可設定特定時間,當發現原始碼已經發生變化時,執行取得原始碼動作,並進行編譯與測試,此時將可完整的知道目前開發專案的穩定狀態,可設定持續性整合伺服器當專案建置成功或失敗時通知相關人員即時進行問題排除。


通常在CI伺服器發生建置失敗的原因,除了一般的程式碼錯誤外,開發人員未提交所有程式碼檔案或未解決程式碼衝突就提交也是原因之一,前者是開發人員針對多個原始碼檔案進行了修改,但因經過了一段時間,已經不確定到底有那些檔案需要提交而造成的問題。後者是當程式碼在版本控制伺服器上同一個時間有多個開發人員進行了修改,後者提交時會提示發生了檔案衝突,而開發人員未解決重覆提交產生的問題。這些問題的發生事實上都是開發人員對版本控制觀念的認知不足所致。無論取得或提交原始碼時需對整個專案進行,才不會遺漏掉必須提交的檔案。版本衝突時相對於版本控制系統都會有一套解決衝突的流程,只要小心都能避免。



1 持續性整合開發環境


持續性整合的分析:產生可供評估的報表

開發過程中文件的產生是很重要的事,開發前期的系統分析、系統設計文件,開發中的原始碼進度與狀況追蹤報表,開發後期的元件使用手冊、系統操作手冊,無論是任何一份文件都是目前專案開發所需要的重要參考。但傳統軟體專案的開發多數文件的產生都是由人手工去撰寫的,若要在開發人員在開發過程中還必須挪出時間進行文件的撰寫,對於開發人員來說是非常痛苦的事。


更重要的是,開發過程中程式碼會變,所產出的文件當程式碼一改變可能沒多久就過時了。因此在業界有多數狀況都是專案開發前期非常認真的撰寫相關文件,開發中期發現文件內容跟不上程式碼的變化索性就暫時放一邊,打算等之後再統一寫,到了開發後期要不就是因為專案的Delay或失敗而成為一個沒有文件的專案,就是根本忘了到底新增了那些功能而成為一份殘缺不全的文件。


因此在多數的敏捷開發原則中就提出了,最好的文件就是原始碼,首先為了讓原始碼在日後維護容易,必須在撰寫程式碼時保持程式碼的可讀性,並且必須統一程式碼的風格,訂定統一的開發規範,在一定程度上降低對文件的依賴,另外透過在程式碼中順手加上的文件資訊也就是所謂的Java Doclet的註解型式,配合相關的Doclet工具,就可隨時產生符合當時狀況的Java Doc說明文件。


為了追蹤專案開發進度與協助程式碼進行分析與重構,在此列出常用的持續性整合開發程式碼分析工具:

  • CheckStyle:檢查程式碼撰寫風格是否符合規範。

  • PMD:靜態程式碼分析工具,可用於找出潛在錯誤程式。

  • JavaNCSS:協助在開發過程中檢查出程式碼的複雜度。

  • Cobertura:於執行期檢查執行與未執行程式的測試覆蓋率檢測工具。


CheckStyle是自動化程式碼風格檢查工具,在傳統的多人協同開發中,可以發現每位開發人員都有相異的程式碼風格,少數有經驗的開發人員在風格上都有一定程度的好習慣,但在程度參差不齊的參與者中,很難保證有一致的Code StyleCheckStyle工具設定了一份規則文件,於建置時期對程式碼進行檢查,將不符合規範的資訊列出,因此開發人員可透過這份資訊了解本身所撰寫的風格是否合乎需求,並進行改進。如此一來維護程式碼就變成一件容易的事,畢竟誰都不想維護一份有怪異風格的程式碼。參考圖 2所示的CheckStyle報表,提供了InfoWarning、與Error的訊息,並緊接著列出錯誤原因與行數。


PMD是一個Java原始碼分析工具,透過一系列的規則比較可以協助找出潛在的Bug,包含 16 個規則集合,涵蓋了所有 Java經常發生的問題,如不良的命名規則、無用而未移除的程式碼、藕合度分析、不良的異常使用…等。在此我們參考圖 3可看出,該PMD報告說明了有40個檔案找到了65個錯誤,並且列出了錯誤原因為import了未使用的類別,還有包含了一個空的Exception區塊。由此一來開發人員可移除無用的import而不會造成日後不使用相關jar檔後造成的編譯錯誤,處理Exception區塊以避免日後發生問題後無法得知究竟異常原因為何。當然除了PMD所內建的檢查機制都可以因專案的需求進行修改,並可自行撰寫新的規則。



JavaNCSS用於進行原始碼的複雜度分析,NCSSNon Commenting Source Statements也就是分析非註解的原始碼資訊,聽起來似乎沒什麼但實際上JavaNCSS首先幫我們列出了前30名程式碼行數最多的類別,其次列出了前30Method最多的類別,供開發人員分析是否包含了過多無用的程式碼或者該類別給予了太多的責任,由此進行重構的考量。另外最重要的部分列出了前30MethodNCSS資訊,通常當Method中的程式碼行數過長,相對的也代表了有較高的NCCNCC所指的是Cyclomatic Complexity Number意指為程式的複雜度,在MethodNCC愈高,事實上就愈不利於日後的維護,因此NCC的數值將是重構的重要依據。參考圖 4


Cobertura是西班牙語覆蓋的意思,這個工具可以協助在進行單元測試的過程中統計已測試過的類別與未測試過類別的資訊,參考圖 5中明顯可知,當測試覆蓋率到達100%時也就代表了該類別中所有功能都至少被完整執行過1次以上,而覆蓋率分為Line CoverageBranch Coverage代表著一般程式碼與有分支判斷的程式碼(例如:if elseswitch或迴圈等),當然分支愈多代表著該類別的複雜度愈高,撰寫高覆蓋率的測試程式碼就愈困難。在進行程式碼開發的過程中如何撰寫功能強大、程式複雜度低而高測試覆蓋率的系統是每位開發人員的理想,而透過工具的分析,可讓開發人員的理想更趨近於真實。


2 CheckStyle報表。

3 PMD報表。

4 JavaNCSS報表。

5 Cobertura報表


結論

持續性整合開發為專案帶來了高效率、可控管、靈活有彈性的開發方式,透過專案管理與建置工具的協助,能夠很輕鬆在專案編譯過程中產生所需的專案開發資訊與分析報表,這一切的一切都是自動化的。透過報表資訊的產出可以減少開發人員手工檢查的時間,帶來了更高的效率與生產力,透過持續性整合伺服器的快速回饋,可以即時掌握目前專案原始碼開發狀況,徹底解決了企業及大型專案協同開發的管理問題。記住所有專案的開發都會發生問題,但持續性整合開發能在專案進行過程中持續發現並盡速解決問題,在開發的每一步降低風險,要知道愈晚發生問題所衍生的維護成本會是早期發現的十倍甚至百倍。



作者介紹

盧建州 <jazz.lu0827@gmail.com>

有多年軟體開發經驗,注重軟體工程並善用Design Patterns。專研於JavaOpen Source解決方案、跨平台技術與其異質資訊系統整合。目前為自由工作者。

沒有留言: