手把手教你使J2EE專案開發自動化(轉)

手把手教你使J2EE專案開發自動化(轉)[@more@]

　　編者語:在這本書中，Pragmatic Project Automation, Mike Clark 為你提供了無所不有的方法來自動化你的軟體專案：用Ant來一步式構建（one-step builds），用CruiseControl 按計劃時間來持續構建（scheduling continuous builds），按一下按鈕就可以釋出軟體，輕易地安裝和佈署應用，透過email,RSS,你的手機，甚至是熔岩燈（lava lamps）來監控構建和程式執行。方法包含示例使初學者也很容易實踐，即使是熟手也有更多高階的主題能教她們一些新東西。在這篇文章裡，他描繪了自動化你的專案能帶來的好處的概要。

　　你即將要在明天早上交付一個用於關鍵性演示的軟體版本。穿著西裝的銷售人員嘴裡吹著泡炫耀你公司的新的輔助應用給一些十分重要的有錢人。正象你正在鍵盤上尋找感覺，你的老闆卻站到你的旁邊提醒你這個演示可能會得到這個專案或者讓專案完蛋。不要有任何壓力！

　　 一步構建和測試

　　在你為那些“必須有”的演示特徵輸入最後一行程式碼後，差不多都中午了。你最喜愛的IDE 顯示你的程式碼編譯透過並透過了單元測試。但是當他結合到系統的其餘部分，你的程式碼是否能象預期的那樣正常工作呢？為了弄清楚它，你更新了你本地的工作區，為了同步現在版本控制系統中的檔案。然後你執行了專案的一步式構建過程：

　　$ ant

　　這個命令編譯了所有的程式碼檔案，執行了下面Ant構建檔案中的配置的所有的單元測試。

　　清單1：

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　includes="**/*Test.class" />

　　

　　

　　

　　

　　當你寫程式碼時，你在你的IDE中頻繁地點選方便的構建按鈕來確認所有的東西都編譯了。你也已經熱衷於當你的JUnit測試透過後，看到一個快樂的綠色條（單元測試成功的標誌），然後你使用JUnit測試執行器（JUnit test runner）整合到你的IDE中。但不是團隊裡的每個人都象你那樣喜歡這個IDE，而且你也不想在每次有人想做一個構建時就不得不啟動IDE。使用構建檔案來和你的IDE分離，每個團隊裡的人都能一步式地持續構建和測試專案。（專案使用Maven 來建立一步式構建。）

　　你不要驚訝，構建成功了，你再次意識到你是世界上最偉大的程式設計師。 不僅是在程式碼裡做這個構建過程帶給你的信心，他也讓你對專案可在你的IDE外構建有信心。

　　感覺非常好，你上傳了已經更改的檔案並避開了那些麻煩。為了準備演示，你仍舊有許多要做的，你需要更早的離開第一次去參加你兒子的tee-ball遊戲比賽。時鐘滴答的響著…

　　 泡泡危機

　　午飯後回辦公室的路上，你注意到專案的紅色熔岩燈在沸騰（這種燈燈罩裡有特殊液體材料）。哦！當你想離開去吃飯的時候，綠色的燈正歡快的冒著泡（說明程式一切正常）。你離開後，你專案的按計劃進行的構建過程在機器上努力的嘗試構建和測試現在版本控制資源（version control repository）上的程式碼。但發生了可怕的錯誤。

　　讓你的專案連續地執行構建是很容易的，因為實際上你可以在命令列中一步就建立一個構建。這意味著你可以很容易的讓一臺計算機整日地為你執行構建。否則，你就不得不放一個開發人員不時地用命令列構建檔案。取而代之，你用CruiseControl 設定在你的專案專用構建機器上在一定的時間間隔內自動地建立構建,如下面的config.xml檔案所示：

　　清單2：

　　

　　

　　

　　

　　file="logs/whizbang/currentbuildstatus.txt" />

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　file="logs/whizbang/currentbuildstatus.txt" />

　　<!-- email publisher --&gt

　　<!-- RSS publisher --&gt

　　<!-- lava lamp publisher --&gt

　　

　　

　　

　　這個config.xml檔案使CruiseControl 每5分鐘被喚醒一次，檢測你專案的CVS資源，看看是否需要構建。只有當你的團隊中有人更改了一個已經存在的檔案，或者加入了一個新檔案到版本控制資源裡的時候，CruiseControl 才嘗試去建立一個構建。他依賴於怎樣用一個Ant或者Maven構建檔案為你的專案去建立一個構建。你可以用CruiseControl 設定去執行一個叫cc-build.xml 的Ant構建檔案，內容如下：

　　清單3：

　　

　　

　　

　　

　　

　　

　　

　　cc-build.xml檔案透過刪除你專案在上次構建時的複製和從CVS資源上下載一個專案新的複製引導執行構建過程。然後他自動執行同樣的你在命令列中編譯和測試專案的bulid.xml檔案。在執行build檔案後，CruiseControl 釋出構建結果給所有註冊了的發行人。（使用Maven的專案也用了CruiseControl ，不過它被誰設定用一些你不喜歡使用的其它的版本控制系統去監視變化）

　　每5分鐘把這些工作全都做一遍是個輕鬆的工作，這就是為什麼你喜歡讓CruiseControl 來為你做這些。當你最初設定它的時候，看起來非常麻煩，但你已經學會感激能適時回饋給你資訊的價值。5分鐘的計劃任務不過是編譯了所有的程式碼和執行了單元測試，作了一個快捷的健全性的檢測。你也用CruiseControl 設定去執行一整套系統在不那麼頻繁的時間間隔裡執行測試。如果5分鐘構建失敗了，那問題不會存在超過了5分鐘。這就讓你比較容易的查詢和修復問題，從而節約了你寶貴的時間。如果在最近的5分鐘裡，沒有變化被提交，那麼CruiseControl 保持休眠。

　　看，構建失敗了！CruiseControl 點燃了紅色熔岩燈是件好事，因為你可能忽略了你裝滿了郵件的收件箱裡的構建失敗的email。著急找到問題的根源，你開啟了構建狀態web頁發現匆忙間你忘了上傳一個新檔案。這很難為情，但至少你現在能更早的修復構建在演示前在問題複雜起來導致一個噩夢般的除錯會議之前。

　　 快速釋出

　　不久以後，團隊裡的每個人都上傳了他們的程式碼。現在你準備建立一個分發檔案部署它到演示的伺服器上。但在出發之前你只剩了不多的時間，釋出過程包括了以下單調乏味的步驟：

　　1． 測試在主幹路徑中的程式碼

　　2． 在版本控制上建一個版本分支

　　3． 校對版本分支的內容

　　4． 構建和測試版本分支中的程式碼

　　（修復所有的問題）

　　5． 打包這個版本的所有的檔案到一個分發檔案裡

　　6． 測試分發檔案中的內容

　　7． 把版本控制中的版本分支作上標籤

　　8． 把分發檔案發給QA

　　這只是你能想起來的步驟！實際上，釋出你的軟體總是一個耗時的易發生錯誤的過程。因此，你不能經常的釋出你軟體的新版本。你對不得不回憶釋出過程中的所有步驟和不得不正確的輸入所有需要的命令的壓力感到疲憊。現在你的專案一步步的釋出過程都是自動的（甚至備有文件）憑藉著一些按鈕操作般的釋出指令碼。

　　演示將要花費一點準備，你想要一個和程式主幹上活躍部分隔離的穩定的工作區。但你又不想在下一個版本釋出前凍結主幹阻塞每個人的開發。解決方案就是在你的版本控制資源裡建立一個版本分支。第一個指令碼控制著有執行版本號的釋出過程的1到4的步驟：

　　$ release_branch 2_7_1

　　指令碼成功地執行了，告訴你版本分支建立了所有的程式碼編譯並透過了測試。如果有問題，你要在這個版本分支路徑中進行修改，測試這些改變，提交改變給版本分支。你也可以執行其它的指令碼合併這些改變到主幹。

　　一旦你有了一個版本分支，你修復了所有的問題，你準備實際上生成一個釋出版本。為了這些，你執行了另一個指令碼去控制4到8的步驟，給了一個版本號。

　　$ release_generate 2_7_1

　　執行這個指令碼的結果是一個獨立的分發檔案―客戶可以安裝和釋出的相同的檔案。你已經快完事了；在你離開之前只剩一步了。

　　 髒部署細節

　　部署應用到演示伺服器是另一個多步驟地手動過程，即使你慢慢做，也基本上會出錯。但是因為你的團隊需要頻繁地部署軟體―那正確可靠地部署在任何時候都很重要―你已經自動化了部署步驟。當你執行部署指令碼的時候所有的髒部署細節為你執行。

　　$ deploy

　　在這種情況下，指令碼傳輸分發檔案到演示伺服器解包所有的部署模組到他們各自的路徑。但在指令碼實際在應用伺服器執行前，還有一步需要完善。

　　你不想自動地部署應用，只是因為一個愚蠢的配置問題而不能開始。在應用乾淨地執行之前，你的應用有一個配置值的數字需要適當地設定。於是在啟動應用伺服器之前，指令碼執行了一套診斷測試來快速查明部署中任何潛在的問題。

　　特別的，你已經注意到搞壞了資料庫配置的是一個普通的部署錯誤。除錯這個問題讓你掉了許多頭髮，所以上個星期你用JUnit寫了下面的診斷測試：

　　清單4：

　　public class DiagnosticTests extends junit.framework.TestCase {

　　public void testDatabaseConnection() {

　　Database database = new Database();

　　try {

　　database.connect();

　　} catch(RuntimeException e) {

　　fail("Unable to connect to the database '" +

　　 database.getURL() + "'. " +

　　 "Please check the 'database.url' property.");

　　}

　　}

　　}

　　testDatabaseConnection 方法嘗試使用一個專案的資料庫類例項去連線資料庫。那個類從配置檔案裡讀入了配置的值，就像database.url 這樣的屬性。如果診斷測試不能連線到資料庫，那看起來在執行的時候你得應用將要遭受同樣的命運了。因此，如果connect 方法在診斷測試呼叫時丟擲一個異常，fail() 方法被呼叫來列印一個有用的資訊來幫助你修復問題。

　　萬分感謝，部署指令碼報告沒有錯誤。這告訴你應用已被部署了，所有的診斷測試透過了，應用伺服器也被啟動了。你得演示在運轉了！

　　 洩密監視器

　　你點選了web應用的幾個頁面做一個快捷健全的檢測。這看起來很棒，但你想今晚知道對於驅動明天的演示來說它仍舊會很棒，這樣你就可以睡好了。專案是線上的，這樣你整個晚上都可以知道有什麼不好的事情發生在演示上。

　　不要擔心。你從你的自動化工具箱找個程式可以每隔幾分鐘搜尋一個web網站中的像"Error" 或者 "Exception." 這樣的有關錯誤的詞。如果有這種詞出現，或者web網站變得不可用了，監視器將發一個SMS訊息到你得手機上。這樣的話，如果應用當掉了，你會有比較多的時間在演示前修復它。在你跑出辦公室門之前，你把監視器掛到演示站點上：

　　$ monitor

　　在tee-ball 的場地，你看到你得兒子走上了本壘板。其間，在你得辦公室，你可靠的監視程式獨自執行著。你的手機就在旁邊，但他始終沒響，你像個孩子似的睡了因為演示將沒有故障的結束。

　　 向前和向上

　　演示是如此成功以至於客戶為了得到應用的複製一直排到了門口。提交分發檔案到你公司的網站或者燒若干的光碟將拖慢你得團隊，如果沒有自動化指令碼來控制那些任務的話，也會是同樣的。如果有人恰巧報告了一個錯誤，你可以輕鬆的從版本控制中重新生成演示。當錯誤被修正，你可以按一下按鈕生成一個新的釋出。

　　無論你在哪兒，自動化都可以依靠問題發生時更早地通知你來幫助減少演示失敗的風險。自動化也節省了你的時間，保證結果一致，透過給你提供可重複的方法來構建和部署你的軟體。當你繼續準備演示和釋出新軟體時，自動化可以多次地發揮作用。

　　 實際的專案自動化

　　不幸的，這個故事對許多專案來說並不真實，也許也包括你的專案。許多團隊努力用手工去做這些專案的雜事，但人們做這種重複性的工作並不如計算機做的那麼好。這些團隊冒險使用不同的方法執行一個過程，一次只關注一點，只在一臺機器上而不在其他機器上，或者做著錯誤的事情。坦白的說，你知道你有比持續構建更好的事情去做，按著多步清單，複製檔案到伺服器，監視執行的程式。但你怎樣才能迅速有效地把這一塊塊的工作銜接到一起呢？

　　從這篇文章看起來，自動化你現在或者下一個專案包括了大量工作。謝天謝地，你不必今天就自動化你所有的專案過程來開始明確自動化的好處。你自動化的每個專案的雜事都是一筆投資，能立即回報和隨時間增加價值。你可以藉助免費的可用工具如Ant,Maven，CruiseControl, JUnit, 和簡單的指令碼一步步地迅速地開始。Pragmatic Project Automation 這本書告訴你怎樣用你的計算機一次次的用同樣的方式來做你專案的重複性的任務，不再煩擾你。這意味著你將擁有更多的時間和精力去做真正令人激動―有挑戰性--的事情就像寫高質量的程式碼。

·上一篇：

·下一篇：WeblogicServer9新特性:J2EELibraries

最新更新
	· · · · · · ·WeblogicServer9新特性:J2EELibraries · · · · · · · · · · · · · · · · · · ·使用訊息驅動Beans(3) · · · ·