一步構建和測試
在你為那些“必須有”的演示特征輸入最後一行代碼後，差不多都中午了。你最喜愛的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" />
這個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 http://demoserver:8080/whizbang
在tee-ball 的場地，你看到你得兒子走上了本壘板。其間，在你得辦公室，你可靠的監視程序獨自運行著。你的手機就在旁邊，但他始終沒響，你像個孩子似的睡了因為演示將沒有故障的結束。
向前和向上
演示是如此成功以至於客戶為了得到應用的拷貝一直排到了門口。提交分發文件到你公司的網站或者燒若干的光盤將拖慢你得團隊，如果沒有自動化腳本來控制那些任務的話，也會是同樣的。如果有人恰巧報告了一個錯誤，你可以輕松的從版本控制中重新生成演示。當錯誤被修正，你可以按一下按鈕生成一個新的發布。
無論你在哪兒，自動化都可以依靠問題發生時更早地通知你來幫助減少演示失敗的風險。自動化也節省了你的時間，保證結果一致，通過給你提供可重復的方法來構建和部署你的軟件。當你繼續准備演示和發布新軟件時，自動化可以多次地發揮作用。
實際的項目自動化
不幸的，這個故事對許多項目來說並不真實，也許也包括你的項目。許多團隊努力用手工去做這些項目的雜事，但人們做這種重復性的工作並不如計算機做的那麼好。這些團隊冒險使用不同的方法運行一個過程，一次只關注一點，只在一台機器上而不在其他機器上，或者做著錯誤的事情。坦白的說，你知道你有比持續構建更好的事情去做，按著多步清單，拷貝文件到服務器，監視運行的程序。但你怎樣才能迅速有效地把這一塊塊的工作銜接到一起呢？
從這篇文章看起來，自動化你現在或者下一個項目包括了大量工作。謝天謝地，你不必今天就自動化你所有的項目過程來開始明確自動化的好處。你自動化的每個項目的雜事都是一筆投資，能立即回報和隨時間增加價值。你可以借助免費的可用工具如Ant,Maven，CruiseControl, JUnit, 和簡單的腳本一步步地迅速地開始。Pragmatic Project Automation 這本書告訴你怎樣用你的計算機一次次的用同樣的方式來做你項目的重復性的任務，不再煩擾你。這意味著你將擁有更多的時間和精力去做真正令人激動—有挑戰性--的事情就像寫高質量的代碼。
