手把手教你使J2EE項目開發自動化

j2ee|項目

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

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

    一步構建和測試

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

    $ ant

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

    清單1：
<project name="whizbang" default="test" basedir=".">

    <property name="build.prod.dir" location="build/prod"/>
    <property name="build.test.dir" location="build/test"/>
    <property name="src.dir"        location="src"/>
    <property name="test.dir"       location="test"/>
    <property name="vendor.lib.dir" location="vendor/lib"/>

    <path id="project.classpath">
      <pathelement location="${build.prod.dir}" />
      <pathelement location="${build.test.dir}" />
      <fileset dir="${vendor.lib.dir}">
        <include name="*.jar"/>
      </fileset>
    </path>

    <target name="prepare">
      <mkdir dir="${build.prod.dir}"/>
      <mkdir dir="${build.test.dir}"/>
    </target>

    <target name="compile" depends="prepare">
      <javac srcdir="${src.dir}" destdir="${build.prod.dir}">
        <classpath refid="project.classpath" />
      </javac>
    </target>

    <target name="compile-tests" depends="compile">
      <javac srcdir="${test.dir}" destdir="${build.test.dir}">
        <classpath refid="project.classpath" />
      </javac>
    </target>

    <target name="test" depends="compile-tests">
      <junit haltonfailure="true">
        <classpath refid="project.classpath" />
        <formatter type="brief" usefile="false" />
        <batchtest>
          <fileset dir="${build.test.dir}"
            includes="**/*Test.class" />
        </batchtest>
      </junit>
    </target>

  </project>

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

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

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

    泡泡危機

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

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

    清單2：
<cruisecontrol>

    <project name="whizbang" buildafterfailed="false">

      <bootstrappers>
        <currentbuildstatusbootstrapper
          file="logs/whizbang/currentbuildstatus.txt" />
      </bootstrappers>

      <modificationset quietperiod="30">
        <cvs localworkingcopy="checkout/whizbang" />
      </modificationset>

      <schedule interval="300">
        <ant buildfile="cc-build.xml" />
      </schedule>

      <log dir="logs/whizbang">
        <merge dir="checkout/whizbang/junit-results" />
      </log>
  
      <publishers>

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

        <!-- email publisher -->
        <!-- RSS publisher -->
        <!-- lava lamp publisher -->

      </publishers>

    </project>

  </cruisecontrol>

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

    清單3：
<project name="cc-build" default="build" basedir="checkout">

    <target name="build">
      <delete dir="whizbang" />
      <cvs command="co whizbang" />
      <ant antfile="build.xml" dir="whizbang" />
    </target>

  </project>

    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 http://demoserver:8080/whizbang

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

    向前和向上

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

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

    實際的項目自動化

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

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