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