全面分析持續集成優缺點(2)

持續集成的關鍵是自動化。絕大多數的集成都可以而且應該自動完成。讀取源代碼、編譯、連接、測試，這些都可以自動完成。最後，你應該得到一條簡單的信息，告訴你這次創建是否成功："yes"或"no"。如果成功，本次集成到此爲止；如果失敗，你應該可以很簡單地撤消最後一次的修改，回到前一次成功的創建。在整個創建過程中，完全不需要你動腦子。

　　如果有了這樣一套自動化過程，你隨便想多頻繁進行創建都可以。唯一的侷限性就是創建過程本身也會消耗一定的時間。（譯註：不過與捉蟲所需的時間比起來，這點時間是微不足道的。） [Page]

一次成功的創建是什麼樣的？

　　有一件重要的事需要確定：怎樣的創建纔算是成功的？看上去很簡單，但是如此簡單的事情有時卻會變得一團糟，這是值得注意的。有一次，Martin Fowler去檢查一個項目。他問這個項目是否執行日創建，得到了肯定的回答。幸虧Ron Jeffries也在場，他又提了一個問題："你們如何處理創建錯誤？"回答是："我們給相關的人發一個e-mail。"實際上，這個項目已經好幾個月沒有得到成功的創建了。這不是日創建，這只是日創建的嘗試。

　　對於下列"成功創建"的標準，我們還是相當自信的：

　　所有最新的源代碼都被配置管理系統驗證合格

　　所有文件都通過重新編譯

　　得到的目標文件（在我們這裏就是Java的class文件）都通過連接，得到可執行文件

　　系統開始運行，針對系統的測試套件（在我們這裏大概有150個測試類）開始運行

　　如果所有的步驟都沒有錯誤、沒有人爲干涉，所有的測試也都通過了，我們就得到了一個成功的創建

　　絕大多數人都認爲"編譯+連接=創建"。至少我們認爲：創建還應該包括啓動應用程序、針對應用程序運行簡單測試（McConnell稱之爲"冒煙測試"：打開開關讓軟件運行，看它是否會"冒煙"）。運行更詳盡的測試集可以大大提高持續集成的價值，所以我們會首選更詳盡的測試。

單一代碼源

　　爲了實現每日集成，任何開發者都需要能夠很容易地獲取全部最新的源代碼。以前，如果要做一次集成，我們就必須跑遍整個開發中心，詢問每一個程序員有沒有新的代碼，然後把這些新代碼拷貝過來，再找到合適的插入位置……沒有什麼比這更糟糕的了。

　　辦法很簡單。任何人都應該可以帶一臺乾淨的機器過來，連上局域網，然後用一條命令就得到所有的源文件，馬上開始系統的創建。

　　最簡單的解決方案就是：用一套配置管理（源代碼控制）系統作爲所有代碼的來源。配置管理系統通常都設計有網絡功能，並且帶有讓開發者輕鬆獲取源代碼的工具。而且，它們還提供版本管理工具，這樣你可以很輕鬆地找到文件以前的版本。成本就更不成問題了，CVS就是一套出色的開放源代碼的配置管理工具。

　　所有的源文件都應該保存在配置管理系統中。我說的這個"所有"常常比人們想到的還要多，它還包括創建腳本、屬性文件、數據庫調度DLL、安裝腳本、以及在一臺乾淨的機器上開始創建所需的其他一切東西。經常都能看到這樣的情況：代碼得到了控制，但是其他一些重要的文件卻找不到了。

　　儘量確保所有的東西都保存在配置管理系統的同一棵代碼源樹中。有時候爲了得到不同的組件，人們會使用配置管理系統中不同的項目。這帶來的麻煩就是：人們不得不記住哪個組件的哪個版本使用了其他組件的哪些版本。在某些情況下，你必須將代碼源分開，但是這種情況出現的機率比你想象的要小得多。你可以在從一棵代碼源樹創建多個組件，上面那些問題可以通過創建腳本來解決，而不必改變存儲結構。

自動化創建腳本

　　如果你編寫的是一個小程序，只有十幾個文件，那麼應用程序的創建可能只是一行命令的事：javac *.java。更大的項目就需要更多的創建工作：你可能把文件放在許多目錄裏面，需要確保得到的目標代碼都在適當的位置；除了編譯，可能還有連接的步驟；你可能還從別的文件中生成了代碼，在編譯之前需要先生成；測試也需要自動運行。 [Page]

　　大規模的創建經常會耗費一些時間，如果只做了一點小小的改動，當然你不會希望重新做所有這些步驟。所以好的創建工具會自動分析需要改變的部分，常見的方法就是檢查源文件和目標文件的修改日期，只有當源文件的修改日期遲於目標文件時，纔會重新編譯。於是，文件之間的依賴就需要一點技巧了：如果一個目標文件發生了變化，那麼只有那些依賴它的目標文件纔會重新編譯。編譯器可能會處理這類事情，也可能不會。

　　取決於自己的需要，你可以選擇不同的創建類型：你創建的系統可以有測試代碼，也可以沒有，甚至還可以選擇不同的測試集；一些組件可以單獨創建。創建腳本應該讓你可以根據不同的情況選擇不同的創建目標。

　　你輸入一行簡單的命令之後，幫你挑起這副重擔常常是腳本。你使用的可能是shell腳本，也可能是更復雜的腳本語言（例如Perl或Python）。但是很快你就會發現一個專門設計的創建環境是很有用的，例如Unix下的make工具。

　　在我們的Java開發中，我們很快就發現需要一個更復雜的解決方案。Matt用了相當多的時間開發了一個用於企業級Java開發的創建工具，叫做Jinx。但是，最近我們已經轉而使用開放源代碼的創建工具Ant（http://jakarta.apache.org/ant/index.html）。Ant的設計與Jinx非常相似，也支持Java文件編譯和Jar封裝。同時，編寫Ant的擴展也很容易，這讓我們可以在創建過程中完成更多的任務。

　　許多人都使用IDE，絕大多數的IDE中都包含了創建管理的功能。但是，這些文件都依賴於特定的IDE，而且經常比較脆弱，而且還需要在IDE中才能工作。IDE的用戶可以建立自己的項目文件，並且在自己的單獨開發中使用它們。但是我們的主創建過程用Ant建立，並且在一臺使用Ant的服務器上運行。

自測試的代碼

　　只讓程序通過編譯還是遠遠不夠的。儘管強類型語言的編譯器可以指出許多問題，但是即使成功通過了編譯，程序中仍然可能留下很多錯誤。爲了幫助跟蹤這些錯誤，我們非常強調自動化測試--這也是XP提倡的另一個實踐。