在多次的構建過程中,一個好的構建工具或構建過程,不應有不必要和冗余耗時的工作花費在那些尚未改變的代碼上.換句話說,它應該做的就是把那些變動過的地方添加進來進行重新構建.假如你的構建工具或構建過程沒有以上所述的表現,那么可以考慮是否能避免做無用功,從而優化你的構建.

　　舉個例子,假設有一個自上而下的構建過程,即此工程是從持久層到更高一層的構建.通常,這類工程因為那些所用的代碼生成器和反轉引擎工具會導致非常長的構建時間.如圖1所示,首先，構建過程通過數據庫治理系統（比如，MySQL）運行一段sql腳本，生成一個數據庫(譯者注:針對某些可以生成新的數據庫的數據庫系統)，添加測試數據.之后，Middlegen任務將生成CMP（container-managed Persistence）實體；接著，XDoclet 任務繼續生成romote 接口，local接口 和 home 接口 以及值實體（value object）和上一步生成的CMP實體bean的部署描述。（獲取更多Middlegen和Xdoclet的情況，請參閱資源）。接著，產生的代碼加上開發者所寫的java源代碼一起生成class文件，最后把這些class文件，和其它的資源一起打包成.jar,.war..ear后綴的文件。(譯者注: jar (Java Archive), .war (Web Archive) and .ear (EnterPRise Archive))


圖1. 構建的步驟和輸出

　　現在假設，某個正在從事此系統代碼設計的開發人員，需要稍微變動某個if-else塊，并且希望看到變動以后的運行結果。所以他必須重新構建，那么構建過程可能要清空之前構建好的所有的東西，從零開始構建。對于開發者而言，這意味著大量的無聊的等待，而所有這些的出現僅僅因為做了一些微小的變動,因為變動而必須要更新編譯修改了的類,以便更新所用的相關jar或war文件。

　　在這篇文章中，我將介紹一些技巧.通過這些技巧你可以通過只僅僅構建那些被更新變動了的部分,從而使得構建變得快速,也就相應的節約了時間。

持續集成

　　在開始我們討論之前，我們先對持續集成達成一下共識，所謂的持續集成就是說只要工程的代碼庫發生了變動，那么這些變動將被構建和測試，并隨時得到相關的報告。所做的一切將降低團隊整合開發過程的成本和時間。這個過程需要以下條件：

* 一個源碼的版本控制系統比如CVS，這樣的話你可以把代碼放到某一中心地進行維護。
* 一個全自動的構建和測試過程。（比如，用Ant）
*一個可選的，但我們強烈推薦的自動的持續集成工具，類似CruiseControl

　　我們參照下圖(圖2所示)看一下一個完全的采用了以上原則的開發團隊及其開發人員所做的一切.每個開發者都有工程的本地拷貝.在他被分配新的任務之前,首先他必須根據已經提交給了代碼庫的變動來更新自己當前的本地拷貝,完成最新下達的任務(比如改變一些代碼),在接下來他自己的開發過程中，他有可能會修改代碼從而更新自己的工作目錄,然后進行構建,測試,假如測試無誤的話,那么就可以把自己的代碼的變動提交給代碼庫.

　　自動化的持續集成工具監控著代碼庫的變動(CVS)，在代碼庫發生變動時, 持續集成工具會開始一個新的構建,以判定這個變動是否能成功地整合到了代碼庫.假如變動不能成功的整合,提交變動的開發者就會收到惶跬ㄖ畔?那么他必須撤銷自己的提交操作,使代碼庫的代碼恢復到提交前的樣子,接著解決整合出錯的問題,解決完后再次提交.


圖2. 持續集成系統中的各個角色

　　在這篇文章中,我們主要關注的情形是:一個開發者操作著自己的本地工作目錄,他對工程做了一些改動,并想盡快知道這些改動的結果,以及反饋信息. 在完成最后一個任務并把它提交給代碼庫之前,開發者希望做幾個快速的增量式構建.通過使用這篇文章所介紹的技巧,你可以加快你的構建過程,自然而然地節約了開發時間.

注釋
　　加快構建服務器的構建過程本身有它專門的工具和技巧,比如介于多服務器的集群構建(clustering builds)

　　在進一步探討之前,我們定義一些對我們的討論很重要也很有必要的基本術語和概念.

*全構建 (干凈構建) 是指從零開始構建,執行構建所要求的全部的步驟.它把所有的資源當作是從未見過的全新的資源來操作,它會完全忽略之前的操作.

*增量式構建: 一種優化了的構建,由最近一次構建以來所產生的變動觸發.它只對那些變動過但是目前為止尚未被構建的資源進行構建.

*依靠性檢測  所謂的依靠型檢測是指查找當前的工程資源和上次的構建生成的產品的異同，并確定資源只是被修改還是是一個新的或其它的資源。通過這種檢測，構建工作就會只針對那些需要重新構建的資源，從而體現所謂的增量式構建。

　　大多數情況，依靠性檢測是基于代碼的時間標簽和這些代碼相關的產品。也就是代碼的修正時間標簽和已經生成了的產品的修正時間標簽做比較。假如現在產品的時間標簽比生成此產品的代碼的時間標簽陳舊，那么這個產品就會被標識出來，以便于下一次的重構建。

　　然而，基于zip的任務（zip,jar,和其他）在依靠性檢查中表現得更好。假如我們這些任務的更新參數設為“yes”，那么這些zip文件就會被自己包含得所有入口文件所更新（假如zip文件已經存在）。新的文件將會增加進來，而已過時的文件將會被更新到新的版本。

　　我將依靠性檢查和構建優化分成兩個層次：
*Task級 比如，編譯任務只編譯那些被修改過的資源以及這些資源所依靠的類。
*Target級 完全略過那些不必要的任務的執行。這種優化，將不會進行一個一個地檢測所有任務資源的變動的多余工作。

Make構建工具

　　Make的文件是遵從依靠性原則的。Make是Unix系統下一個能夠自動并可以起優化程序結構作用的工具。“make”的效用就是用于自動決定一個大程序中哪些是需要被重編譯，從而觸發命令進行編譯。為了進行Make的工作，必須先寫一個稱為“makefile”的文件，這個文件將描述你的程序中文件之間的關系，以及更新每一個文件的命令行。“makefile”就是由所有的規則組成的。每一條規則都是解釋用什么方法以及在什么時間去構造那些特定文件，而這些文件是某個非凡文件的 target。每一規則由三部分組成：一個或多個的 target，零個或多個的先決條件，零條或多條的命令。

接下來是一個很簡單的makefile文件的片斷：
Listing 1. Sample makefile
    Prog1:  main.o    file1.o
       cc -o prog1 main.o file1.o
     main.o:     main.c    mydefs.h
       cc –c main c

　　Make 程序運行時，先讀當前目錄中的“makefile”文件，并開始執行第一個 target。Make會檢測每一個執行 target的” target依靠”(或稱為prerequisites)屬性，看看這個 target的執行所依靠的其他 target的是否也是作為一個 target出現。Make程序會順著這條依靠鏈,查找依靠性 target（dependencies屬性中提到的 target）,這個過程是一個遞歸的過程，返回的條件是查找到的當前的 target沒有執行所必須的先決條件,或者這個 target的先決條件沒有不受控制.當查找依靠鏈到達鏈的末端,程序將以遞歸的形式依次執行 target中的規則的命令行.

　　Ant 和Make區別于他們對執行過程的不同看法。Make需要你說明資源依靠，非資源依靠以及轉換這些的命令行。Ant 則需要你說明構建步驟，以及這些步驟的順序（很像一個流水線）。
無論任務自身是否可以執行依靠性檢查,Make構建器擁有顯式的依靠性檢測的機制,用戶都可以通過編寫makefile,使得構建器執行之。然而，相比Ant，Make并非平臺獨立。縱觀兩點，他們都各有千秋，假如能各取所長，那么將皆大歡喜。

技巧和準則

　　在我們回顧了一些概念和定義之后，我將對增量式構建提出一些如何加快構建以及如何優化構建的技巧和準則。請注重我只是簡要的介紹這些技巧，也就是說這篇文章只是一個起點。更多的關于工具本身的介紹，可以參考資源.


注釋
　　Jonathon Rasmusson 在他的文章中討論了長構建以及解決這些問題的技巧,”解決長構建指引”( "Long Build Trouble Shooting Guide.") 在這篇文章中，他關注于如何提速以及解決自動測試過程的問題。

　　避免不必要的 target執行
　　一方面要保證你的構建 target的正確的以及符合邏輯的依靠關系，同時避免在依靠性執行環節發生的不必要的 target執行。忽視 target之間的依靠關系而進行所謂的優化，是極其錯誤的習慣，因為它要求編程者具體地記住一系列非凡順序的 target，以得到正確的構建（請參閱Eric M. Burke 寫的“十五個最佳Ant使用習慣“（“Top 15 Ant Best Practices“），發表于ONJAVA.com 2003年12月）。實際中應該是讓構建文件自己記住正確的依靠關系和同時執行最優化的構建。

　　回到之前提到的自下而上的構建過程，每次我們執行構建，并不需要去執行SQL命令，Middlegen，Xdoclet等等。不過我們希望保持 target之間那種正確的依從關系，然而，某些情況下的依靠性檢測本身卻極其耗時（比如，基于數據庫來檢查實體Beans是否正確），假如可能的話，我們希望徹底地跳過這些工作。
　
　　我介紹一個很簡單的技巧，通過這個技巧你可以略過那些不必要的 target：檢查那些將有可能被忽略的 target的最后執行動作的時間標簽和它所依靠的 target的最后執行動作的時間標簽，從而決定 target的輸出是否是最新的。舉例說明一下，假如有 targetA，它的執行依靠與 targetB和C，假如B 和C在A上次執行以來重新執行過，那么就有必要再次執行A以保持數據的一致性，反之則可以跳過A的執行。這種規則依據的條件時，所有的A的輸入都有由B和C提供，并且在 target執行期間B和C的輸出沒有經過人為的修改, target之間的完全銜接。

　　為了能增加這個功能，我們使用Ant工具的“toUCh“ 任務來實現。 “touch” 任務將創建一個新的臨時文件，假如這個文件已經建立，那么它只要去更新臨時文件中不必要的 target和它所依靠的 target的執行的時間標簽。接著，在執行不必要的 target之前，通過”uptodate”任務我們檢查最近一次 target執行所生成的時間標簽異與最近一次通過更新 target而執行的依靠性 target生成的時間標簽。這個任務將會設置一個跳躍屬性，我們把這個屬性作為不必要執行的 target的unless屬性值，從而使Ant跳過這個 target的執行。

　　現在讓我們先回到我們給出的例子。很明顯，當我們改變數據庫schema時，我們的這個例子將要執行Middlegen target，這樣就可以從數據庫產生實體Bean。另一方面，通過改變SQL腳本文件來改變原數據庫schema,并通過執行SQL target來執行這種差異。為了把數據庫schema在沒有改變的情況下不執行Middlegen target的這種邏輯嵌入到構建中，我們需要對比SQL target上一次執行的時間標簽和Middlegen target上一次執行的時間標簽。假如SQL target的執行時間標簽不比Middlegen target執行的時間標簽早，我們可以跳過Middlegen target的執行。

Listing 2. Sample Ant file that skips unnecessary targets
<project name="sample-build" default="" basedir=".">
<target name="init-skip-properties" description="initializes the skip properties" depends="init">
   <uptodate srcfile="create-database.timestamp" targetfile="middlegen.timestamp"
      property="middlegen.skip" value="true"/>
</target>
<target name="create-database" description="runs sql script file on dbms to create db"
   depends="init-skip-properties">

   <sql
      src=" MySQL.sql"
       ...
    />
   <touch file="create-database.timestamp"/>
</target>

<target
   name="middlegen"
   description="Runs Middlegen to create Entity Beans "
   depends="create-database"
   unless="middlegen.skip" >
       ...

   <middlegen
      <cmp20
       ...  
      </cmp20>

   </middlegen>
   <touch file="middlegen.timestamp"/>
</target>
</project>