原始網頁http://www.dsc.com.tw/newspaper/45/45-1.htm 鼎新研發處研發工程師 潘明正/呂凱星/吳佳霖/吳麗雲   軟體專案每天不停地進行，代表著每天都會有程式碼的新增與修改，但整合卻可能是一段時間才進行，這意味著，許多整合性的錯誤此時才會浮現。錯誤發現的越晚，所需付出的代價越大，因此我們必須盡可能提高整合的頻率，讓潛在的錯誤即早現形。基於這樣的想法，我們展開了每日建構(Daily Build)的嘗試。    Daily Build     建構(Build)廣義係指包含撰寫程式碼、測試、整合程式碼、測試整合的程式碼一系列工作。其過程是每一個程式發展人員先針對部分單元撰寫程式碼（含編譯）及單元測試，再將此單元程式碼整合至共有的程式碼中並執行整合性的測試。而Daily Build即是每天進行這個建構的步驟。     在此，我們以eXtreme Programming的觀點來說明Daily Build存在的意義。    ‧看得到進度 Daily Build可以讓專案的進展具體呈現，對於軟體開發而言，如果可以將進度的差異控制在一天之內，那將會是相當理想的。    ‧降低整合的痛苦 五天整合一次所需要的成本，比起一天整合一次，不會只有五倍，可能是二十五倍之多。因此，一天進行一次整合的Daily Build，可以大大的降低未來整合的成本。    ‧頻繁的執行測試 Daily Build所進行的不僅僅是將程式碼整合，更要進行測試，透過單元測試與整合性測試來找出每天所新增或修改的程式，發生了哪些臭蟲，進而除掉臭蟲。    ‧降低開發者的部分壓力 通常越接近專案尾聲，所面臨的壓力也越大，除了開發進度外，亦有專案整合的不確定性：若整合的動作許久才進行一次，因為累積的變動甚多，整合成本往往難以精確估計。而在Daily Build機制輔助下，依據Swedish Engineering Industries專案經驗，開發者進行整合時的壓力可有效的減輕(如下圖所示)。    圖1. 軟體開發人員在專案中壓力程度比較( 資料來源：Swedish Engineering Industries 1999) 一般而言，成功的Daily Build必須以下四個步驟都完成： 所有最後的原始碼都通過版控軟體的檢測； 每一個檔案都重新編譯過； 產出的目標檔(Object Files)已Linked及Deployed做為執行之用（例如：放到Jars中）； 系統被啟動而且測試系列(Suite)已經測試過系統。 如果這些步驟已經執行，且沒有任何錯誤或者人為的干預，同時通過所有的測試，這表示我們已經有了一個成功的建構。 資訊業界已經有許多的公司與組織進行Daily Build，例如微軟。每一個微軟作業系統，在開發的過程中，都執行Daily Build的機制，每天微軟的開發人員在下午下班前開會討論程式碼，並且由有經驗的開發人員進行程式碼審核，最後系統自動執行Daily Build，隔天這些開發人員聚在一起開會討論昨天Build的結果，討論問題與作法，每天就這樣的進行著。也因為如此，我們可以根據開機時顯示它的版本以及建造編號（以Build XXX標出），利用該數字除以365，就知道它是哪一天推出的版本。 我們的做法 Daily Build是一個每天持續進行的工作，因此最重要的關鍵在於程序的自動化。為建立這樣的機制，我們發展出一系列相關的技術，基本上可分為單元測試技術、自動建構技術、程式碼檢查技術、測試環境重建技術等，說明如下： ‧單元測試測試 單元測試是針對系統內各別元件進行測試，確保所有各別元件功能的正確，才能確保元件整合上，不會出現問題。進行單元測試的前提，就是程式開發人員必須撰寫各元件的測試程式碼，雖然這會增加程式開發人員的工作量，但對於品質的提升，卻是最基礎的工作。 這方面我們採用了Junit的Framework，搭配Catcus、HttpUnit及JunitPerf等測試工具。而當我們在進行元件測試時，難免會與其他元件有互動，所以單元測試上我們也改良了AspectJ的AJMock技術，透過Mock的方式來”假設”另外一個元件的行為是正確的，以釐清問題的歸屬。 ．自動建構技術 Daily Build有個很重要的特點，『資訊系統必須能夠自動建構與測試』，一般我們使用IDE來開發程式碼，須要人工建構，無法自動化。基於此點，我們採用ANT建構工具，搭配各專案人員設定的建構、測試流程。執行下圖的流程，我們便能夠達到無須人力介入之建構與測試的目標。 ‧程式碼檢查技術 系統功能由兩個不同的人來撰寫，程式碼一定會不同，如同文章主題相同，由兩個人撰文，內容也肯定不會相同。但在文章中的不同是創意，對於資訊系統開發而言卻是惡夢。因此我們定義了許多關於程式撰寫的規範，例如Coding Style。定義程式人員撰寫程式的規範後，必須有工具來輔助驗證，否則定義將會流於形式。因此在我們Daily Build的技術中，我們導入了Coding Style檢查機制，透過工具來讀取程式開發的規範，透過Daily Build來檢查每一位開發人員所撰寫的程式碼是否符合規範，如此確保每一位程式人員所開發的程式碼是可讀的、寫法是統一的。換句話說，每一位程式開發人員都可以看的懂別人的程式碼。 ．測試環境重建技術 基於ANT工具，我們能夠做到自動化建構與測試。測試的目的是希望透過一連串的運算與比較，來確保系統不會存在臭蟲。但是程式碼動輒上千行，整個系統甚至超過數十萬行，要如何確認系統出錯是因為程式碼所造成，而不是其他外在因素，例如測試機器內其他的軟體、作業系統問題、網路問題、測試資料的一致性…等因素所造成的？我們必須控制外在變數，使其維持不變，因此必須導入無塵室(Clean Room)的概念。 在無塵室的概念下，我們每進行一次測試，都安裝一次新的作業系統，並且系統所需要的元件是當次才進行安裝，期望能夠使每一次的測試都是在乾淨的環境中進行的。如下圖所示，在Windows 2000我們從CM工具下載建構程序檔(如Project A Build Plan)，由ANT來幫我們進行自動化建構與測試，測試結束後，自動將作業系統毀損，再進行Project A 的Windows 2003作業系統安裝、測試、毀損，之後再進行XP與Linux的步驟。如此我們可將同一份程式碼在不同的作業系統中進行建構與測試。 從A到A ：軟體開發流程再精進-導入Daily Build 研發處研發工程師 潘明正/呂凱星/吳佳霖/吳麗雲 軟體專案每天不停地進行，代表著每天都會有程式碼的新增與修改，但整合卻可能是一段時間才進行，這意味著，許多整合性的錯誤此時才會浮現。錯誤發現的越晚，所需付出的代價越大，因此我們必須盡可能提高整合的頻率，讓潛在的錯誤即早現形。基於這樣的想法，我們展開了每日建構(Daily Build)的嘗試。 Daily Build 建構(Build)廣義係指包含撰寫程式碼、測試、整合程式碼、測試整合的程式碼一系列工作。其過程是每一個程式發展人員先針對部分單元撰寫程式碼（含編譯）及單元測試，再將此單元程式碼整合至共有的程式碼中並執行整合性的測試。而Daily Build即是每天進行這個建構的步驟。 在此，我們以eXtreme Programming的觀點來說明Daily Build存在的意義。 ‧看得到進度 Daily Build可以讓專案的進展具體呈現，對於軟體開發而言，如果可以將進度的差異控制在一天之內，那將會是相當理想的。 ‧降低整合的痛苦 五天整合一次所需要的成本，比起一天整合一次，不會只有五倍，可能是二十五倍之多。因此，一天進行一次整合的Daily Build，可以大大的降低未來整合的成本。 ‧頻繁的執行測試 Daily Build所進行的不僅僅是將程式碼整合，更要進行測試，透過單元測試與整合性測試來找出每天所新增或修改的程式，發生了哪些臭蟲，進而除掉臭蟲。 ‧降低開發者的部分壓力 通常越接近專案尾聲，所面臨的壓力也越大，除了開發進度外，亦有專案整合的不確定性：若整合的動作許久才進行一次，因為累積的變動甚多，整合成本往往難以精確估計。而在Daily Build機制輔助下，依據Swedish Engineering Industries專案經驗，開發者進行整合時的壓力可有效的減輕(如下圖所示)。 圖1. 軟體開發人員在專案中壓力程度比較( 資料來源：Swedish Engineering Industries 1999) 一般而言，成功的Daily Build必須以下四個步驟都完成： 所有最後的原始碼都通過版控軟體的檢測； 每一個檔案都重新編譯過； 產出的目標檔(Object Files)已Linked及Deployed做為執行之用（例如：放到Jars中）； 系統被啟動而且測試系列(Suite)已經測試過系統。 如果這些步驟已經執行，且沒有任何錯誤或者人為的干預，同時通過所有的測試，這表示我們已經有了一個成功的建構。 資訊業界已經有許多的公司與組織進行Daily Build，例如微軟。每一個微軟作業系統，在開發的過程中，都執行Daily Build的機制，每天微軟的開發人員在下午下班前開會討論程式碼，並且由有經驗的開發人員進行程式碼審核，最後系統自動執行Daily Build，隔天這些開發人員聚在一起開會討論昨天Build的結果，討論問題與作法，每天就這樣的進行著。也因為如此，我們可以根據開機時顯示它的版本以及建造編號（以Build XXX標出），利用該數字除以365，就知道它是哪一天推出的版本。 我們的做法 Daily Build是一個每天持續進行的工作，因此最重要的關鍵在於程序的自動化。為建立這樣的機制，我們發展出一系列相關的技術，基本上可分為單元測試技術、自動建構技術、程式碼檢查技術、測試環境重建技術等，說明如下： ‧單元測試測試 單元測試是針對系統內各別元件進行測試，確保所有各別元件功能的正確，才能確保元件整合上，不會出現問題。進行單元測試的前提，就是程式開發人員必須撰寫各元件的測試程式碼，雖然這會增加程式開發人員的工作量，但對於品質的提升，卻是最基礎的工作。 這方面我們採用了Junit的Framework，搭配Catcus、HttpUnit及JunitPerf等測試工具。而當我們在進行元件測試時，難免會與其他元件有互動，所以單元測試上我們也改良了AspectJ的AJMock技術，透過Mock的方式來”假設”另外一個元件的行為是正確的，以釐清問題的歸屬。 ．自動建構技術 Daily Build有個很重要的特點，『資訊系統必須能夠自動建構與測試』，一般我們使用IDE來開發程式碼，須要人工建構，無法自動化。基於此點，我們採用ANT建構工具，搭配各專案人員設定的建構、測試流程。執行下圖的流程，我們便能夠達到無須人力介入之建構與測試的目標。 ‧程式碼檢查技術 系統功能由兩個不同的人來撰寫，程式碼一定會不同，如同文章主題相同，由兩個人撰文，內容也肯定不會相同。但在文章中的不同是創意，對於資訊系統開發而言卻是惡夢。因此我們定義了許多關於程式撰寫的規範，例如Coding Style。定義程式人員撰寫程式的規範後，必須有工具來輔助驗證，否則定義將會流於形式。因此在我們Daily Build的技術中，我們導入了Coding Style檢查機制，透過工具來讀取程式開發的規範，透過Daily Build來檢查每一位開發人員所撰寫的程式碼是否符合規範，如此確保每一位程式人員所開發的程式碼是可讀的、寫法是統一的。換句話說，每一位程式開發人員都可以看的懂別人的程式碼。 ．測試環境重建技術 基於ANT工具，我們能夠做到自動化建構與測試。測試的目的是希望透過一連串的運算與比較，來確保系統不會存在臭蟲。但是程式碼動輒上千行，整個系統甚至超過數十萬行，要如何確認系統出錯是因為程式碼所造成，而不是其他外在因素，例如測試機器內其他的軟體、作業系統問題、網路問題、測試資料的一致性…等因素所造成的？我們必須控制外在變數，使其維持不變，因此必須導入無塵室(Clean Room)的概念。 在無塵室的概念下，我們每進行一次測試，都安裝一次新的作業系統，並且系統所需要的元件是當次才進行安裝，期望能夠使每一次的測試都是在乾淨的環境中進行的。如下圖所示，在Windows 2000我們從CM工具下載建構程序檔(如Project A Build Plan)，由ANT來幫我們進行自動化建構與測試，測試結束後，自動將作業系統毀損，再進行Project A 的Windows 2003作業系統安裝、測試、毀損，之後再進行XP與Linux的步驟。如此我們可將同一份程式碼在不同的作業系統中進行建構與測試。 圖3. 自動化測試示意圖 雖然一個軟體產品最終的執行環境，絕對不會是在這所謂的無塵室底下，它會遇到不同的軟體、不同的週邊、不同的環境參數…，但是為了加速系統開發，在程式發展時期予以適度隔離，降低外在的影響因素，應有其必要。事實上，無塵室的概念可以繼續延伸，在必要時再針對系統可能遇到的執行環境，一一建立特殊的測試環境，將有助於問題的分析與改進。 可能會有人會有疑問？如果程式碼沒有更動，那測試有必要進行嗎？答案當然是肯定的，主要的原因是現在的軟體都很複雜，某個元件的修改，會去影響到其它未修改的元件的行為，所以只測試有修改的部份有時不能找出穩藏的問題，有另外一個原因也很重要，因為導入Daily Build的自動化測試，執行測試的成本很低。 在推行Daily Build時，不免也有一些推行的困難。以我們實際導入的經驗而言，就面臨了兩個難題：一是如何寫出正確有效的測試程式碼，二是如何提升工程師撰寫測試程式的意願。前者屬於技術面的問題，可以用教育訓練來解決，但後者屬於管理面的問題。通常工程師在完成產品的程式碼後，都會有一種想法：程式都寫完了，幹嘛要寫測試碼？只是浪費時間罷了。所以我們建議在程式開發前，先完成相關的測試碼；其實這樣也有一個好處，可以讓工程師先對未來的程式碼有先一步構思的機會，進而提昇軟體的品質。 研發人的一天 落實Daily Build，有賴於程式開發人員將其理念融入日常生活中。下面將說明此流程的觀念與重要環節。 (請參閱下圖4) 圖4. 實施Daily Build後，研發人員的一天 ‧Morning Meeting(9:00-9:30) 每天早上軟體元件小組的人員一到公司的第一件事，就是進行每日例行的半個小時的Morning Meeting ，這個會議主要的內容是報告每個人昨天的工作進度及今天的預定工作，如果有昨天的工作有遇到問題，也可在這個時間提出來大家討論，但Morning Meeting最重要的事。是Review昨天Daily Build所產生出來的報表，這個報表包含了各種環境之下單元，整合，壓力測試的結果，也會列出不符合程式撰寫風格的部份，此時。小組成員就可以一起討論，測試結果問題的歸屬，並討論解決的方法，在Morning Meeting運作之下，所有軟體元件的問題，都可以得到最快速的回應。 ‧工作(9:30-17:30) 這段時間內，小組成員就依照工作內容修改Bug、撰寫程式及自行程式的測試。工作到一段落後將程式Check In進VSS。 ‧Code Review(17：00 - 17：30) 由軟體工作小組召開Code Review的會議。這個會議主要的內容為檢核VSS中的程式，如註解的撰寫、程式碼檢查等等。進行方式有採用隨機方式抽檢或由軟體工作小組事先準備Review的程式二種。 ‧Daily Build(24:00) 測試機台由排程程式自動?動。先載入第一種的測試環境，再從VSS上Check Out下最新版本的程式碼，進行編譯等動作，之後測試程式?動，逐一進行單元，整合，壓力測試，並檢查Coding Style，最後回傳報告，接下再載入第二種測試環境進行第二回合的測試，直到測完所有的測試環境。在測試完成之後。測試系統將回饋一個版號(Build Number)到VSS上，並將匯總的測試報告，E-Mail給相關的人員。 結論 藉由導入Daily Build機制於日常生活中，軟體的開發流程將由原本的瀑布式開發流程模型，升級成不斷實作與測試之小型反覆式開發循環流程模型(Iterative-Cyclic Software Process Model)，將大幅降低開發的風險。(請參閱圖5、圖6)。根據eXtreme Programming eXplained一書(ISBN：986-7910-31-1)表示，導入Daily Build機制可以有效的降低系統變更的成本。(請參閱圖7) 圖5. 未導入Daily Build的軟體開發流程（資料來源：Swedish Engineering Industries 1999） 圖6. 導入Daily Build之後的軟體開發流程（資料來源：Swedish Engineering Industries 1999） 圖7. 導入Daily Build前後改變成本比較（資料來源：eXtreme Programming eXplained）