作者:Mike Clark;
boool原文地址:
http://www.onjava.com/pub/a/onjava/2004/11/10/automation.html中文地址:
http://www.matrix.org.cn/resource/article/44/44061_Project+Automation.html關(guān)鍵詞： Project Automation
編者語:在這本書中，Pragmatic Project Automation, Mike Clark 為你提供了無所不有的方法來自動化你的軟件項目：用Ant來一步式構(gòu)建（one-step builds），用CruiseControl 按計劃時間來持續(xù)構(gòu)建（scheduling continuous builds），按一下按鈕就可以發(fā)布軟件，輕易地安裝和布署應(yīng)用，通過email,RSS,你的手機，甚至是熔巖燈（lava lamps）來監(jiān)控構(gòu)建和程序運行。方法包含示例使初學者也很容易實踐，即使是熟手也有更多高級的主題能教她們一些新東西。在這篇文章里，他描繪了自動化你的項目能帶來的好處的概要。
你即將要在明天早上交付一個用于關(guān)鍵性演示的軟件版本。穿著西裝的銷售人員嘴里吹著泡炫耀你公司的新的輔助應(yīng)用給一些十分重要的有錢人。正象你正在鍵盤上尋找感覺，你的老板卻站到你的旁邊提醒你這個演示可能會得到這個項目或者讓項目完蛋。不要有任何壓力！
一步構(gòu)建和測試在你為那些“必須有”的演示特征輸入最后一行代碼后，差不多都中午了。你最喜愛的IDE 顯示你的代碼編譯通過并通過了單元測試。但是當他結(jié)合到系統(tǒng)的其余部分，你的代碼是否能象預(yù)期的那樣正常工作呢？為了弄清楚它，你更新了你本地的工作區(qū)，為了同步現(xiàn)在版本控制系統(tǒng)中的文件。然后你運行了項目的一步式構(gòu)建過程：
$ ant這個命令編譯了所有的代碼文件，運行了下面Ant構(gòu)建文件中的配置的所有的單元測試。
清單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中頻繁地點擊方便的構(gòu)建按鈕來確認所有的東西都編譯了。你也已經(jīng)熱衷于當你的JUnit測試通過后，看到一個快樂的綠色條（單元測試成功的標志），然后你使用JUnit測試運行器（JUnit test runner）整合到你的IDE中。但不是團隊里的每個人都象你那樣喜歡這個IDE，而且你也不想在每次有人想做一個構(gòu)建時就不得不啟動IDE。使用構(gòu)建文件來和你的IDE分離，每個團隊里的人都能一步式地持續(xù)構(gòu)建和測試項目。（項目使用Maven 來創(chuàng)建一步式構(gòu)建。）
你不要驚訝，構(gòu)建成功了，你再次意識到你是世界上最偉大的程序員。 不僅是在代碼里做這個構(gòu)建過程帶給你的信心，他也讓你對項目可在你的IDE外構(gòu)建有信心。
感覺非常好，你上傳了已經(jīng)更改的文件并避開了那些麻煩。為了準備演示，你仍舊有許多要做的，你需要更早的離開第一次去參加你兒子的tee-ball游戲比賽。時鐘滴答的響著…
泡泡危機午飯后回辦公室的路上，你注意到項目的紅色熔巖燈在沸騰（這種燈燈罩里有特殊液體材料）。哦！當你想離開去吃飯的時候，綠色的燈正歡快的冒著泡（說明程序一切正常）。你離開后，你項目的按計劃進行的構(gòu)建過程在機器上努力的嘗試構(gòu)建和測試現(xiàn)在版本控制資源（version control repository）上的代碼。但發(fā)生了可怕的錯誤。
讓你的項目連續(xù)地運行構(gòu)建是很容易的，因為實際上你可以在命令行中一步就創(chuàng)建一個構(gòu)建。這意味著你可以很容易的讓一臺計算機整日地為你運行構(gòu)建。否則，你就不得不放一個開發(fā)人員不時地用命令行構(gòu)建文件。取而代之，你用CruiseControl 設(shè)定在你的項目專用構(gòu)建機器上在一定的時間間隔內(nèi)自動地創(chuàng)建構(gòu)建,如下面的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資源，看看是否需要構(gòu)建。只有當你的團隊中有人更改了一個已經(jīng)存在的文件，或者加入了一個新文件到版本控制資源里的時候，CruiseControl 才嘗試去創(chuàng)建一個構(gòu)建。他依賴于怎樣用一個Ant或者Maven構(gòu)建文件為你的項目去創(chuàng)建一個構(gòu)建。你可以用CruiseControl 設(shè)定去運行一個叫cc-build.xml 的Ant構(gòu)建文件，內(nèi)容如下：
清單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文件通過刪除你項目在上次構(gòu)建時的拷貝和從CVS資源上下載一個項目新的拷貝引導運行構(gòu)建過程。然后他自動運行同樣的你在命令行中編譯和測試項目的bulid.xml文件。在運行build文件后，CruiseControl 發(fā)布構(gòu)建結(jié)果給所有注冊了的發(fā)行人。（使用Maven的項目也用了CruiseControl ，不過它被誰設(shè)定用一些你不喜歡使用的其它的版本控制系統(tǒng)去監(jiān)視變化）
每5分鐘把這些工作全都做一遍是個輕松的工作，這就是為什么你喜歡讓CruiseControl 來為你做這些。當你最初設(shè)置它的時候，看起來非常麻煩，但你已經(jīng)學會感激能適時回饋給你信息的價值。5分鐘的計劃任務(wù)不過是編譯了所有的代碼和運行了單元測試，作了一個快捷的健全性的檢測。你也用CruiseControl 設(shè)置去運行一整套系統(tǒng)在不那么頻繁的時間間隔里執(zhí)行測試。如果5分鐘構(gòu)建失敗了，那問題不會存在超過了5分鐘。這就讓你比較容易的查找和修復(fù)問題，從而節(jié)約了你寶貴的時間。如果在最近的5分鐘里，沒有變化被提交，那么CruiseControl 保持休眠。
看，構(gòu)建失敗了！CruiseControl 點燃了紅色熔巖燈是件好事，因為你可能忽略了你裝滿了郵件的收件箱里的構(gòu)建失敗的email。著急找到問題的根源，你打開了構(gòu)建狀態(tài)web頁發(fā)現(xiàn)匆忙間你忘了上傳一個新文件。這很難為情，但至少你現(xiàn)在能更早的修復(fù)構(gòu)建在演示前在問題復(fù)雜起來導致一個噩夢般的調(diào)試會議之前。
快速發(fā)布不久以后，團隊里的每個人都上傳了他們的代碼?，F(xiàn)在你準備創(chuàng)建一個分發(fā)文件部署它到演示的服務(wù)器上。但在出發(fā)之前你只剩了不多的時間，發(fā)布過程包括了以下單調(diào)乏味的步驟：
1． 測試在主干路徑中的代碼
2． 在版本控制上建一個版本分支
3． 校對版本分支的內(nèi)容
4． 構(gòu)建和測試版本分支中的代碼
（修復(fù)所有的問題）
5． 打包這個版本的所有的文件到一個分發(fā)文件里
6． 測試分發(fā)文件中的內(nèi)容
7． 把版本控制中的版本分支作上標簽
8． 把分發(fā)文件發(fā)給QA
這只是你能想起來的步驟！實際上，發(fā)布你的軟件總是一個耗時的易發(fā)生錯誤的過程。因此，你不能經(jīng)常的發(fā)布你軟件的新版本。你對不得不回憶發(fā)布過程中的所有步驟和不得不正確的輸入所有需要的命令的壓力感到疲憊?，F(xiàn)在你的項目一步步的發(fā)布過程都是自動的（甚至備有文檔）憑借著一些按鈕操作般的發(fā)布腳本。
演示將要花費一點準備，你想要一個和程序主干上活躍部分隔離的穩(wěn)定的工作區(qū)。但你又不想在下一個版本發(fā)布前凍結(jié)主干阻塞每個人的開發(fā)。解決方案就是在你的版本控制資源里創(chuàng)建一個版本分支。第一個腳本控制著有運行版本號的發(fā)布過程的1到4的步驟：
$ release_branch 2_7_1腳本成功地運行了，告訴你版本分支創(chuàng)建了所有的代碼編譯并通過了測試。如果有問題，你要在這個版本分支路徑中進行修改，測試這些改變，提交改變給版本分支。你也可以運行其它的腳本合并這些改變到主干。
一旦你有了一個版本分支，你修復(fù)了所有的問題，你準備實際上生成一個發(fā)布版本。為了這些，你運行了另一個腳本去控制4到8的步驟，給了一個版本號。
$ release_generate 2_7_1運行這個腳本的結(jié)果是一個獨立的分發(fā)文件—客戶可以安裝和發(fā)布的相同的文件。你已經(jīng)快完事了；在你離開之前只剩一步了。
臟部署細節(jié)部署應(yīng)用到演示服務(wù)器是另一個多步驟地手動過程，即使你慢慢做，也基本上會出錯。但是因為你的團隊需要頻繁地部署軟件—那正確可靠地部署在任何時候都很重要—你已經(jīng)自動化了部署步驟。當你運行部署腳本的時候所有的臟部署細節(jié)為你執(zhí)行。
$ deploy在這種情況下，腳本傳輸分發(fā)文件到演示服務(wù)器解包所有的部署模塊到他們各自的路徑。但在腳本實際在應(yīng)用服務(wù)器執(zhí)行前，還有一步需要完善。
你不想自動地部署應(yīng)用，只是因為一個愚蠢的配置問題而不能開始。在應(yīng)用干凈地運行之前，你的應(yīng)用有一個配置值的數(shù)字需要適當?shù)卦O(shè)置。于是在啟動應(yīng)用服務(wù)器之前，腳本運行了一套診斷測試來快速查明部署中任何潛在的問題。
特別的，你已經(jīng)注意到搞壞了數(shù)據(jù)庫配置的是一個普通的部署錯誤。調(diào)試這個問題讓你掉了許多頭發(fā)，所以上個星期你用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 方法嘗試使用一個項目的數(shù)據(jù)庫類實例去連接數(shù)據(jù)庫。那個類從配置文件里讀入了配置的值，就像database.url 這樣的屬性。如果診斷測試不能連接到數(shù)據(jù)庫，那看起來在運行的時候你得應(yīng)用將要遭受同樣的命運了。因此，如果connect 方法在診斷測試調(diào)用時拋出一個異常，fail() 方法被調(diào)用來打印一個有用的信息來幫助你修復(fù)問題。
萬分感謝，部署腳本報告沒有錯誤。這告訴你應(yīng)用已被部署了，所有的診斷測試通過了，應(yīng)用服務(wù)器也被啟動了。你得演示在運轉(zhuǎn)了！
泄密監(jiān)視器你點擊了web應(yīng)用的幾個頁面做一個快捷健全的檢測。這看起來很棒，但你想今晚知道對于驅(qū)動明天的演示來說它仍舊會很棒，這樣你就可以睡好了。項目是在線的，這樣你整個晚上都可以知道有什么不好的事情發(fā)生在演示上。
不要擔心。你從你的自動化工具箱找個程序可以每隔幾分鐘搜索一個web網(wǎng)站中的像"Error" 或者 "Exception." 這樣的有關(guān)錯誤的詞。如果有這種詞出現(xiàn)，或者web網(wǎng)站變得不可用了，監(jiān)視器將發(fā)一個SMS消息到你得手機上。這樣的話，如果應(yīng)用當?shù)袅?，你會有比較多的時間在演示前修復(fù)它。在你跑出辦公室門之前，你把監(jiān)視器掛到演示站點上：
$ monitor http://demoserver:8080/whizbang在tee-ball 的場地，你看到你得兒子走上了本壘板。其間，在你得辦公室，你可靠的監(jiān)視程序獨自運行著。你的手機就在旁邊，但他始終沒響，你像個孩子似的睡了因為演示將沒有故障的結(jié)束。
向前和向上演示是如此成功以至于客戶為了得到應(yīng)用的拷貝一直排到了門口。提交分發(fā)文件到你公司的網(wǎng)站或者燒若干的光盤將拖慢你得團隊，如果沒有自動化腳本來控制那些任務(wù)的話，也會是同樣的。如果有人恰巧報告了一個錯誤，你可以輕松的從版本控制中重新生成演示。當錯誤被修正，你可以按一下按鈕生成一個新的發(fā)布。
無論你在哪兒，自動化都可以依靠問題發(fā)生時更早地通知你來幫助減少演示失敗的風險。自動化也節(jié)省了你的時間，保證結(jié)果一致，通過給你提供可重復(fù)的方法來構(gòu)建和部署你的軟件。當你繼續(xù)準備演示和發(fā)布新軟件時，自動化可以多次地發(fā)揮作用。
實際的項目自動化不幸的，這個故事對許多項目來說并不真實，也許也包括你的項目。許多團隊努力用手工去做這些項目的雜事，但人們做這種重復(fù)性的工作并不如計算機做的那么好。這些團隊冒險使用不同的方法運行一個過程，一次只關(guān)注一點，只在一臺機器上而不在其他機器上，或者做著錯誤的事情。坦白的說，你知道你有比持續(xù)構(gòu)建更好的事情去做，按著多步清單，拷貝文件到服務(wù)器，監(jiān)視運行的程序。但你怎樣才能迅速有效地把這一塊塊的工作銜接到一起呢？
從這篇文章看起來，自動化你現(xiàn)在或者下一個項目包括了大量工作。謝天謝地，你不必今天就自動化你所有的項目過程來開始明確自動化的好處。你自動化的每個項目的雜事都是一筆投資，能立即回報和隨時間增加價值。你可以借助免費的可用工具如Ant,Maven，CruiseControl, JUnit, 和簡單的腳本一步步地迅速地開始。Pragmatic Project Automation 這本書告訴你怎樣用你的計算機一次次的用同樣的方式來做你項目的重復(fù)性的任務(wù)，不再煩擾你。這意味著你將擁有更多的時間和精力去做真正令人激動—有挑戰(zhàn)性--的事情就像寫高質(zhì)量的代碼。
