作者：Martin Fowler
--------------------------------------------------------------------------------
Martin Fowler & Matthew Foemmel著(zhù) 透明 譯
英文原文版權由Martin Fowler擁有
Original text is copyrighted by Martin Fowler
原文鏈接：http://martinfowler.com/articles/continuousIntegration.html
Martin Fowler
Chief Scientist, ThoughtWorks
譯者語(yǔ)：2002年1月23日，我們很榮幸的在UMLCHINA組織的網(wǎng)上交流中聆聽(tīng)了Martin Fowler先生的教誨。在交流中，Martin Fowler向所有中國軟件開(kāi)發(fā)者推薦了這篇文章：Continuous Integration（《持續集成》）。
初讀之下，我便感覺(jué)到了它的分量，AgileChina的林星也稱(chēng)贊：“其中的思想非常的好，大師就是大師。”然 后，用了一周的時(shí)間，我終于把這篇文章翻譯出來(lái)，以饗讀者。
由于這是Fowler先生送給全體中國軟件開(kāi)發(fā)者的禮物，所以我絕對不敢獨占。任何人都可以在任何地方隨意轉載本文，但是在轉載時(shí)請保持本文完整性——包括標題、版權聲明、原文鏈接、譯者語(yǔ)……總之，請不要在轉載的時(shí)候做任何改動(dòng)或增刪。另外，如果能在轉載的時(shí)候順手給我一個(gè)mail，我會(huì )更加高興。
下面，請開(kāi)始欣賞這篇精彩的文章。
在任何軟件開(kāi)發(fā)過(guò)程中都有一個(gè)重要的部分：得到可靠的軟件創(chuàng )建（build）版本。盡管知道創(chuàng )建的重要性，但是我們仍然會(huì )經(jīng)常因為創(chuàng )建失敗而驚訝不已。在這篇文章里，我們將討論Matt（Matthew Foemmel）在ThoughtWorks的一個(gè)重要項目中實(shí)施的過(guò)程，這個(gè)過(guò)程在我們的公司里日益受到重視。它強調完全自動(dòng)化的、可重復的創(chuàng )建過(guò)程，其中包括每天運行多次的自動(dòng)化測試。它讓開(kāi)發(fā)者可以每天進(jìn)行系統集成，從而減少了集成中 的問(wèn)題。
ThoughtWorks公司已經(jīng)開(kāi)放了CruiseControl軟件的源代碼，這是一個(gè)自動(dòng)化持續集成的工具。此外，我們還 提供CruiseControl、Ant和持續集成方面的顧問(wèn)服務(wù)。如果需要更多的信息，請與Josh Mackenzie
（jmackenz@ThoughtWorks.com）聯(lián)系。
本文有以下主要內容：
持續集成的優(yōu)點(diǎn)
集成越頻繁，效果越好
一次成功的創(chuàng )建是什么樣的？
單一代碼源
自動(dòng)化創(chuàng )建腳本
自測試的代碼
主創(chuàng )建
代碼歸還
總結
在軟件開(kāi)發(fā)的領(lǐng)域里有各種各樣的“最佳實(shí)踐”，它們經(jīng)常被人們談起，但是似乎很少有真正得到實(shí)現的。這些實(shí)踐最基本、最有價(jià)值的就是：都有一個(gè)完全自動(dòng)化的創(chuàng )建、測試過(guò)程，讓開(kāi)發(fā)團隊可以每天多次創(chuàng )建他們的軟件。“日創(chuàng )建”也是人們經(jīng)常討論的一個(gè)觀(guān)點(diǎn)，McConnell在他的《快速軟件開(kāi)發(fā)》中將日創(chuàng )建作為一個(gè)最佳實(shí)踐來(lái)推薦，同時(shí)日創(chuàng )建也是微軟很出名的一項開(kāi)發(fā)方法。但是，我們更支持XP社群的觀(guān)點(diǎn)：日創(chuàng )建只是最低要求。一個(gè)完全自動(dòng)化的過(guò)程讓你可以每天完成多次創(chuàng )建，這是可以做到的，也是完全值得的。
在這里，我們使用了“持續集成（Continuous Integration）”這個(gè)術(shù)語(yǔ)，這個(gè)術(shù)語(yǔ)來(lái)自于XP（極限編程）的一個(gè)實(shí)踐。但是我們認為：這個(gè)實(shí)踐早就存在，并且很多并沒(méi)有考慮XP的人也在使用著(zhù)它。只不過(guò)我們一直用XP作為軟件開(kāi)發(fā)過(guò)程的標準，XP也對我們的術(shù)語(yǔ)和實(shí)踐產(chǎn)生了深遠的影響。盡管如此，你還是可以只使用持續集成，而不必使用XP的任何其他部分——實(shí)際上，我們認為：對于任何切實(shí)可行的軟件開(kāi)發(fā)活動(dòng)，持續集成都是很 基本的組成部分。
實(shí)現自動(dòng)化日創(chuàng )建需要做以下幾部分的工作：
將所有的源代碼保存在單一的地點(diǎn)，讓所有人都能從這里獲取最新的源代碼（以及以前的版本）。使創(chuàng )建過(guò)程完全自動(dòng)化，讓任何人都可以只輸入一條命令就完成系統的創(chuàng )建。 使測試完全自動(dòng)化，讓任何人都可以只輸入一條命令就運行一套完整的系統測試。 確保所有人都可以得到最新、最好的可執行文件。
所有這些都必須得到制度的保證。我們發(fā)現，向一個(gè)項目中引入這些制度需要耗費相當大的精力。但是，我 們也發(fā)現，一旦制度建立起來(lái)，保持它的正常運轉就不需要花多少力氣了。
持續集成的優(yōu)點(diǎn)
描述持續集成最大的難點(diǎn)在于：它從根本上改變了整個(gè)開(kāi)發(fā)模式。如果沒(méi)有在持續集成的實(shí)踐環(huán)境中工作過(guò)，你很難理解它的開(kāi)發(fā)模式。實(shí)際上，在單獨工作的時(shí)候，絕大多數人都能感覺(jué)到這種氣氛——因為他們只需要與自己的系統相集成。對于許多人來(lái)說(shuō)，“團隊開(kāi)發(fā)”這個(gè)詞總讓他們想起軟件工程領(lǐng)域中的一些難題。持續集成減少了這些難題的數量，代之以一定的制度。
持續集成最基本的優(yōu)點(diǎn)就是：它完全避免了開(kāi)發(fā)者們的“除蟲(chóng)會(huì )議”——以前開(kāi)發(fā)者們經(jīng)常需要開(kāi)這樣的會(huì )，因為某個(gè)人在工作的時(shí)候踩進(jìn)了別人的領(lǐng)域、影響了別人的代碼，而被影響的人還不知道發(fā)生了什么，于是bug就出現了。這種bug是最難查的，因為問(wèn)題不是出在某一個(gè)人的領(lǐng)域里，而是出在兩個(gè)人的交流上面。隨著(zhù)時(shí)間的推移，問(wèn)題會(huì )逐漸惡化。通常，在集成階段出現的bug早在幾周甚至幾個(gè)月之前就已經(jīng)存在了。結果，開(kāi)發(fā)者需要在集成階段耗費大量的時(shí)間和精力來(lái)尋找這些bug的根源。
如果使用持續集成，這樣的bug絕大多數都可以在引入的同一天就被發(fā)現。而且，由于一天之中發(fā)生變動(dòng)的部分并不多，所以可以很快找到出錯的位置。如果找不到bug究竟在哪里，你也可以不把這些討厭的代碼集成到產(chǎn)品中去。所以，即使在最壞的情況下，你也只是不添加引起bug的特性而已。（當然，可能你對新特性的要求勝過(guò)了對bug的憎恨，不過(guò)至少你可以多一種選擇。）
到現在為止，持續集成還不能保證你抓到所有集成時(shí)出現的bug。持續集成的排錯能力取決于測試技術(shù)，眾 所周知，測試無(wú)法證明已經(jīng)找到了所有的錯誤。關(guān)鍵是在于：持續集成可以及時(shí)抓到足夠多的bug，這就已經(jīng)值 回它的開(kāi)銷(xiāo)了。
所以，持續集成可以減少集成階段“捉蟲(chóng)”消耗的時(shí)間，從而最終提高生產(chǎn)力。盡管現在還不知道是否有人對這種方法進(jìn)行過(guò)科學(xué)研究，但是作為一種實(shí)踐性的方法，很明顯它是相當有效的。持續集成可以大幅減少耗費在“集成地獄”中的時(shí)間，實(shí)際上，它可以把地獄變成小菜一碟。
集成越頻繁，效果越好
持續集成有一個(gè)與直覺(jué)相悖的基本要點(diǎn)：經(jīng)常性的集成比很少集成要好。對于持續集成的實(shí)踐者來(lái)說(shuō)，這是 很自然的；但是對于從未實(shí)踐過(guò)持續集成的人來(lái)說(shuō)，這是與直觀(guān)印象相矛盾的。
如果你的集成不是經(jīng)常進(jìn)行的（少于每天一次），那么集成就是一件痛苦的事情，會(huì )耗費你大量的時(shí)間與精 力。我們經(jīng)常聽(tīng)見(jiàn)有人說(shuō)：“在一個(gè)大型的項目中，不能應用日創(chuàng )建”，實(shí)際上這是一種十分愚蠢的觀(guān)點(diǎn)。
不過(guò)，還是有很多項目實(shí)踐著(zhù)持續集成。在一個(gè)五十人的團隊、二十萬(wàn)行代碼的項目中，我們每天要集成二 十多次。微軟在上千萬(wàn)行代碼的項目中仍然堅持日創(chuàng )建。
持續集成之所以可行，原因在于集成的工作量是與兩次集成間隔時(shí)間的平方成正比的。盡管我們還沒(méi)有具體的衡量數據，但是可以大概估計出來(lái)：每周集成一次所需的工作量絕對不是每天集成的5倍，而是大約25倍。所以，如果集成讓你感到痛苦，也許就說(shuō)明你應該更頻繁地進(jìn)行集成。如果方法正確，更頻繁的集成應該能減少你的痛苦，讓你節約大量時(shí)間。
持續集成的關(guān)鍵是自動(dòng)化。絕大多數的集成都可以而且應該自動(dòng)完成。讀取源代碼、編譯、連接、測試，這些都可以自動(dòng)完成。最后，你應該得到一條簡(jiǎn)單的信息，告訴你這次創(chuàng )建是否成功：“yes”或“no”。 如果成功，本次集成到此為止；如果失敗，你應該可以很簡(jiǎn)單地撤消最后一次的修改，回到前一次成功的創(chuàng )建。在整個(gè)
創(chuàng )建過(guò)程中，完全不需要你動(dòng)腦子。
如果有了這樣一套自動(dòng)化過(guò)程，你隨便想多頻繁進(jìn)行創(chuàng )建都可以。唯一的局限性就是創(chuàng )建過(guò)程本身也會(huì )消耗 一定的時(shí)間。（譯注：不過(guò)與捉蟲(chóng)所需的時(shí)間比起來(lái)，這點(diǎn)時(shí)間是微不足道的。）
一次成功的創(chuàng )建是什么樣的？
有一件重要的事需要確定：怎樣的創(chuàng )建才算是成功的？看上去很簡(jiǎn)單，但是如此簡(jiǎn)單的事情有時(shí)卻會(huì )變得一 團糟，這是值得注意的。有一次，MartinFowler去檢查一個(gè)項目。他問(wèn)這個(gè)項目是否執行日創(chuàng )建，得到了肯定 的回答。幸虧RonJeffries也在場(chǎng)，他又提了一個(gè)問(wèn)題：“你們如何處理創(chuàng )建錯誤？”回答是：“我們給相關(guān)的人發(fā)一個(gè)e-mail。”實(shí)際上，這個(gè)項目已經(jīng)好幾個(gè)月沒(méi)有得到成功的創(chuàng )建了。這不是日創(chuàng )建，這只是日創(chuàng )建的嘗 試。
對于下列“成功創(chuàng )建”的標準，我們還是相當自信的：
所有最新的源代碼都被配置管理系統驗證合格
所有文件都通過(guò)重新編譯
得到的目標文件（在我們這里就是Java的class文件）都通過(guò)連接，得到可執行文件
系統開(kāi)始運行，針對系統的測試套件（在我們這里大概有150個(gè)測試類(lèi)）開(kāi)始運行
如果所有的步驟都沒(méi)有錯誤、沒(méi)有人為干涉，所有的測試也都通過(guò)了，我們就得到了一個(gè)成功的創(chuàng )建
絕大多數人都認為“編譯+連接=創(chuàng )建”。至少我們認為：創(chuàng )建還應該包括啟動(dòng)應用程序、針對應用程序運行 簡(jiǎn)單測試（McConnell稱(chēng)之為“冒煙測試”：打開(kāi)開(kāi)關(guān)讓軟件運行，看它是否會(huì )“冒煙”）。
運行更詳盡的測試 集可以大大提高持續集成的價(jià)值，所以我們會(huì )首選更詳盡的測試。
單一代碼源
為了實(shí)現每日集成，任何開(kāi)發(fā)者都需要能夠很容易地獲取全部最新的源代碼。以前，如果要做一次集成，我 們就必須跑遍整個(gè)開(kāi)發(fā)中心，詢(xún)問(wèn)每一個(gè)程序員有沒(méi)有新的代碼，然后把這些新代碼拷貝過(guò)來(lái)，再找到合適的插 入位置……沒(méi)有什么比這更糟糕的了。
辦法很簡(jiǎn)單。任何人都應該可以帶一臺干凈的機器過(guò)來(lái)，連上局域網(wǎng)，然后用一條命令就得到所有的源文 件，馬上開(kāi)始系統的創(chuàng )建。
最簡(jiǎn)單的解決方案就是：用一套配置管理（源代碼控制）系統作為所有代碼的來(lái)源。配置管理系統通常都設計有網(wǎng)絡(luò )功能，并且帶有讓開(kāi)發(fā)者輕松獲取源代碼的工具。而且，它們還提供版本管理工具，這樣你可以很輕松地找到文件以前的版本。成本就更不成問(wèn)題了，CVS就是一套出色的開(kāi)放源代碼的配置管理工具。
所有的源文件都應該保存在配置管理系統中。我說(shuō)的這個(gè)“所有”常常比人們想到的還要多，它還包括創(chuàng )建腳本、屬性文件、數據庫調度DLL、安裝腳本、以及在一臺干凈的機器上開(kāi)始創(chuàng )建所需的其他一切東西。經(jīng)常都能看到這樣的情況：代碼得到了控制，但是其他一些重要的文件卻找不到了。
盡量確保所有的東西都保存在配置管理系統的同一棵代碼源樹(shù)中。有時(shí)候為了得到不同的組件，人們會(huì )使用配置管理系統中不同的項目。這帶來(lái)的麻煩就是：人們不得不記住哪個(gè)組件的哪個(gè)版本使用了其他組件的哪些版本。在某些情況下，你必須將代碼源分開(kāi)，但是這種情況出現的幾率比你想象的要小得多。你可以在從一棵代碼源樹(shù)創(chuàng )建多個(gè)組件，上面那些問(wèn)題可以通過(guò)創(chuàng )建腳本來(lái)解決，而不必改變存儲結構。
自動(dòng)化創(chuàng )建腳本
如果你編寫(xiě)的是一個(gè)小程序，只有十幾個(gè)文件，那么應用程序的創(chuàng )建可能只是一行命令的事：javac *.java。更大的項目就需要更多的創(chuàng )建工作：你可能把文件放在許多目錄里面，需要確保得到的目標代碼都在適當的位置；除了編譯，可能還有連接的步驟；你可能還從別的文件中生成了代碼，在編譯之前需要先生成；測試 也需要自動(dòng)運行。
大規模的創(chuàng )建經(jīng)常會(huì )耗費一些時(shí)間，如果只做了一點(diǎn)小小的改動(dòng)，當然你不會(huì )希望重新做所有這些步驟。所以好的創(chuàng )建工具會(huì )自動(dòng)分析需要改變的部分，常見(jiàn)的方法就是檢查源文件和目標文件的修改日期，只有當源文件的修改日期遲于目標文件時(shí)，才會(huì )重新編譯。于是，文件之間的依賴(lài)就需要一點(diǎn)技巧了：如果一個(gè)目標文件發(fā)生
了變化，那么只有那些依賴(lài)它的目標文件才會(huì )重新編譯。編譯器可能會(huì )處理這類(lèi)事情，也可能不會(huì )。
取決于自己的需要，你可以選擇不同的創(chuàng )建類(lèi)型：你創(chuàng )建的系統可以有測試代碼，也可以沒(méi)有，甚至還可以 選擇不同的測試集；一些組件可以單獨創(chuàng )建。創(chuàng )建腳本應該讓你可以根據不同的情況選擇不同的創(chuàng )建目標。
你輸入一行簡(jiǎn)單的命令之后，幫你挑起這副重擔常常是腳本。你使用的可能是shell腳本，也可能是更復雜 的腳本語(yǔ)言（例如Perl或Python）。但是很快你就會(huì )發(fā)現一個(gè)專(zhuān)門(mén)設計的創(chuàng )建環(huán)境是很有用的，例如Unix下的make工具。
在我們的Java開(kāi)發(fā)中，我們很快就發(fā)現需要一個(gè)更復雜的解決方案。Matt用了相當多的時(shí)間開(kāi)發(fā)了一個(gè)用于 企業(yè)級Java開(kāi)發(fā)的創(chuàng )建工具，叫做Jinx。但是，最近我們已經(jīng)轉而使用開(kāi)放源代碼的創(chuàng )建工具Ant （http://jakarta.apache.org/ant/index.html）。Ant的設計與Jinx非常相似，也支持Java文件編譯和Jar封 裝。同時(shí)，編寫(xiě)Ant的擴展也很容易，這讓我們可以在創(chuàng )建過(guò)程中完成更多的任務(wù)。
許多人都使用IDE，絕大多數的IDE中都包含了創(chuàng )建管理的功能。但是，這些文件都依賴(lài)于特定的IDE，而且經(jīng)常比較脆弱，而且還需要在IDE中才能工作。IDE的用戶(hù)可以建立自己的項目文件，并且在自己的單獨開(kāi)發(fā)中使用它們。但是我們的主創(chuàng )建過(guò)程用Ant建立，并且在一臺使用Ant的服務(wù)器上運行。
自測試的代碼
只讓程序通過(guò)編譯還是遠遠不夠的。盡管強類(lèi)型語(yǔ)言的編譯器可以指出許多問(wèn)題，但是即使成功通過(guò)了編 譯，程序中仍然可能留下很多錯誤。為了幫助跟蹤這些錯誤，我們非常強調自動(dòng)化測試——這也是XP提倡的另一 個(gè)實(shí)踐。
XP將測試分為兩類(lèi)：?jiǎn)卧獪y試和容納測試（也叫功能測試）。單元測試是由開(kāi)發(fā)者自己編寫(xiě)的，通常只測試一個(gè)類(lèi)或一小組類(lèi)。容納測試通常是由客戶(hù)或外部的測試組在開(kāi)發(fā)者的幫助下編寫(xiě)的，對整個(gè)系統進(jìn)行端到端的測試。這兩種測試我們都會(huì )用到，并且盡量提高測試的自動(dòng)化程度。
作為創(chuàng )建的一部分，我們需要運行一組被稱(chēng)為“BVT”（Build Verification Tests，創(chuàng )建確認測試）的測試。BVT中所有的測試都必須通過(guò)，然后我們才能宣布得到了一個(gè)成功的創(chuàng )建。所有XP風(fēng)格的單元測試都屬于BVT。由于本文是關(guān)于創(chuàng )建過(guò)程的，所以我們所說(shuō)的“測試”基本上都是指BVT。請記住，除了BVT之外，還有一條測試線(xiàn)存在（譯注：指功能測試），所以不要把BVT和整體測試、QA等混為一談。實(shí)際上，我們的QA小組根本不會(huì )看到?jīng)]有通過(guò)BVT的代碼，因為他們只對成功的創(chuàng )建進(jìn)行測試。
有一條基本的原則：在編寫(xiě)代碼的同時(shí)，開(kāi)發(fā)者也應該編寫(xiě)相應的測試。完成任務(wù)之后，他們不但要歸還 （checkin）產(chǎn)品代碼，而且還要歸還這些代碼的測試。這也跟XP的“測試第一”的編程風(fēng)格很相似：在編寫(xiě)完相應的測試、并看到測試失敗之前，你不應該編寫(xiě)任何代碼。所以，如果想給系統添加新特性，你首先應該編寫(xiě)一個(gè)測試。只有當新的特性已經(jīng)實(shí)現了以后，這個(gè)測試才可能通過(guò)。然后，你的工作就是讓這個(gè)測試能夠通過(guò)。
我們用Java編寫(xiě)這些測試，與開(kāi)發(fā)使用同樣的語(yǔ)言，所以編寫(xiě)測試與編寫(xiě)代碼沒(méi)有太大的區別。我們使用JUnit（http://www.junit.org/）來(lái)作為組織、編寫(xiě)測試的框架。JUnit是一個(gè)簡(jiǎn)單的框架，讓我們可以快速編 寫(xiě)測試、將測試組織為套件、并以交互或批處理的模式來(lái)運行測試套件。（JUnit是xUnit家族的Java版本 ——xUnit包括了幾乎所有語(yǔ)言的測試框架。）
在編寫(xiě)軟件的過(guò)程中，在每一次的編譯之后，開(kāi)發(fā)者通常都會(huì )運行一部分單元測試。這實(shí)際上提高了開(kāi)發(fā)者的工作效率，因為這些單元測試可以幫助你發(fā)現代碼中的邏輯錯誤。然后，你就沒(méi)必要去調試查錯，只需要注意 最后一次運行測試之后修改的代碼就行了。這個(gè)修改的范圍應該很小，所以尋找bug也就容易多了。
并非所有的人都嚴格遵循XP“測試第一”的風(fēng)格，但是在第一時(shí)間編寫(xiě)測試的好處是顯而易見(jiàn)的。它們不但讓每個(gè)人的工作效率更高，而且由這些測試構成的BVT更能捕捉到系統中的錯誤。因為BVT每天要運行好幾次，所以BVT檢查出的任何問(wèn)題都是比較容易改正的，原因很簡(jiǎn)單：我們只做了相當小范圍的修改，所以我們可以在這個(gè)范圍內尋找bug。在修改過(guò)的一小塊代碼中排錯當然比跟蹤整個(gè)系統來(lái)排錯要有效多了。
當然，你不能指望測試幫你找到所有的問(wèn)題。就象人們常說(shuō)的：測試不能證明系統中不存在錯誤。但是，盡 善盡美不是我們唯一的要求。不夠完美的測試只要經(jīng)常運行，也比永遠寫(xiě)不出來(lái)的“完美測試”要好得多。
另一個(gè)相關(guān)的問(wèn)題就是：開(kāi)發(fā)者們?yōu)樽约旱拇a編寫(xiě)測試。我們經(jīng)常聽(tīng)人說(shuō)：開(kāi)發(fā)者不應該測試自己的代碼，因為他們很容易忽視自己工作中的錯誤。盡管這也是事實(shí)，但是自測試過(guò)程需要快速將測試轉入代碼基礎中。這種快速轉換的價(jià)值超過(guò)獨立測試者的價(jià)值。所以，我們還是用開(kāi)發(fā)者自己編寫(xiě)的測試來(lái)構造BVT，但是仍 然有獨立編寫(xiě)的容納測試。
自測試另一個(gè)很重要的部分就是它通過(guò)反饋——XP的一項核心價(jià)值——來(lái)提高測試的質(zhì)量。這里的反饋來(lái)自于從BVT中逃脫的bug。自測試的規則是：除非你在BVT中加入了相應的測試，否則就不能修正任何錯誤。這樣，每當要修正某個(gè)錯誤的時(shí)候，你都必須添加相應的測試，以確保BVT不會(huì )再把錯誤放過(guò)去。而且，這個(gè)測試應該引導你去考慮更多的測試、編寫(xiě)更多的測試來(lái)加強BVT。
主創(chuàng )建
創(chuàng )建過(guò)程的自動(dòng)化對于單個(gè)開(kāi)發(fā)者來(lái)說(shuō)很有意義，但是它真正發(fā)光的，還是在整個(gè)系統的主創(chuàng )建（master build）的生成。我們發(fā)現，主創(chuàng )建過(guò)程能讓整個(gè)團隊走到一起來(lái)，讓他們及早發(fā)現集成中的問(wèn)題。
第一步是要選擇運行主創(chuàng )建的機器。我們選擇了一臺叫做“投石車(chē)”的計算機（我們經(jīng)常玩“帝國時(shí)代” J），這是一臺裝有四個(gè)CPU的服務(wù)器，非常適合專(zhuān)門(mén)用來(lái)做創(chuàng )建。（由于完整的創(chuàng )建需要相當長(cháng)的時(shí)間，所以這 種馬力是必須的。）
創(chuàng )建進(jìn)程是在一個(gè)隨時(shí)保持運行的Java類(lèi)中進(jìn)行的。如果沒(méi)有創(chuàng )建任務(wù)，創(chuàng )建進(jìn)程就一直循環(huán)等待，每過(guò)幾 分鐘去檢查一下代碼倉庫。如果在最后的創(chuàng )建之后沒(méi)有人歸還任何代碼，進(jìn)程就繼續等待。如果代碼倉庫中有了 新的代碼，就開(kāi)始創(chuàng )建。
創(chuàng )建的第一階段是完全提取倉庫中的代碼。Starteam已經(jīng)為我們提供了相當好的Java API，所以切入代碼倉庫也很容易。守護進(jìn)程（daemon）會(huì )觀(guān)察五分鐘以前的倉庫，看最近五分鐘里面有沒(méi)有人歸還了代碼。如果有，守護進(jìn)程就會(huì )考慮等五分鐘再提取代碼（以免在別人歸還代碼的過(guò)程中提?。?。
守護進(jìn)程將全部代碼提取到投石機的一個(gè)目錄中。提取完成之后，守護進(jìn)程就會(huì )在這個(gè)目錄里調用Ant腳本。然后，Ant會(huì )接管整個(gè)創(chuàng )建過(guò)程，對所有源代碼做一次完整的創(chuàng )建。Ant腳本會(huì )負責整個(gè)編譯過(guò)程，并把得到的class文件放進(jìn)六個(gè)jar包里，發(fā)布到EJB服務(wù)器上。
當Ant完成了編譯和發(fā)布的工作之后，創(chuàng )建守護進(jìn)程就會(huì )在EJB服務(wù)器上開(kāi)始運行新的jar，同時(shí)開(kāi)始運行BVT測試套件。如果所有的測試都能正常運行通過(guò)，我們就得到了一個(gè)成功的創(chuàng )建。然后創(chuàng )建守護進(jìn)程就會(huì )回到Starteam，將所有提取出的源代碼標記上創(chuàng )建號。然后，守護進(jìn)程會(huì )觀(guān)察創(chuàng )建過(guò)程中是否還有人歸還了代碼。如果有，就再開(kāi)始一次創(chuàng )建；如果沒(méi)有，守護進(jìn)程就回到它的循環(huán)中，等待下一次的歸還。
創(chuàng )建結束之后，創(chuàng )建守護進(jìn)程會(huì )給所有向最新一次創(chuàng )建歸還了代碼的開(kāi)發(fā)者發(fā)一個(gè)e-mail，匯報創(chuàng )建的情 況。如果把創(chuàng )建留在代碼歸還之后去做，而又不用e-mail向開(kāi)發(fā)者通報創(chuàng )建的情況，我們通常認為這是不好的組 織形式。
守護進(jìn)程將所有的步驟都寫(xiě)在XML格式的日志文件里面。投石車(chē)上會(huì )運行一個(gè)servlet，允許任何人通過(guò)它檢 查日志，以觀(guān)察創(chuàng )建的狀態(tài)。（見(jiàn)圖1）
屏幕上會(huì )顯示出創(chuàng )建是否正在運行、開(kāi)始運行的時(shí)間。在左邊有所有創(chuàng )建的歷史記錄，成功的、失敗的都記 錄在案。點(diǎn)擊其中的某一條記錄，就會(huì )顯示出這次創(chuàng )建的詳細信息：編譯是否通過(guò)、測試的結果、發(fā)生了哪些變 化……
我們發(fā)現很多開(kāi)發(fā)者都經(jīng)?？纯催@個(gè)頁(yè)面，因為它讓他們看到項目發(fā)展的方向，看到隨著(zhù)人們不斷歸還代碼 而發(fā)生的變化。有時(shí)我們也會(huì )在這個(gè)頁(yè)面上放一些其他的項目新聞，但是需要把握好尺度。
要讓開(kāi)發(fā)者能在自己的本地機器上模擬主創(chuàng )建過(guò)程，這是很重要的。這樣，如果集成錯誤出現了，開(kāi)發(fā)者可 以在自己的機器上研究、調試，而不必真的執行主創(chuàng )建過(guò)程。而且，開(kāi)發(fā)者也可以在歸還代碼之前先在本地執行 創(chuàng )建，從而降低了主創(chuàng )建失敗的可能性。
這里有一個(gè)比較重要的問(wèn)題：主創(chuàng )建應該是干凈的創(chuàng )建（完全從源代碼開(kāi)始）還是增量創(chuàng )建？增量創(chuàng )建會(huì )快得多，但是也增大了引入錯誤的風(fēng)險，因為有些部分是沒(méi)有編譯的。而且我們還有無(wú)法重新創(chuàng )建的風(fēng)險。我們的創(chuàng )建速度相當快（20萬(wàn)行代碼約15分鐘），所以我們樂(lè )于每次都做干凈的創(chuàng )建。但是，有些團隊喜歡在大多數時(shí)候做增量創(chuàng )建，但是當那些奇怪的問(wèn)題突然出現時(shí)，也經(jīng)常性地做干凈的創(chuàng )建（至少每天一次）。
圖1：運行在投石車(chē)上的servlet
代碼歸還（Check in）
使用自動(dòng)化創(chuàng )建就意味著(zhù)開(kāi)發(fā)者應該遵循某種節奏來(lái)開(kāi)發(fā)軟件，最重要的就是他們應該經(jīng)常集成。我們曾經(jīng)見(jiàn)過(guò)一些組織，他們也做日創(chuàng )建，但是其中的開(kāi)發(fā)者卻不經(jīng)常歸還代碼。如果開(kāi)發(fā)者幾周才歸還一次代碼，那么日創(chuàng )建又有什么意義呢？我們遵循的原則是：每個(gè)開(kāi)發(fā)者至少每天要歸還一次代碼。
在開(kāi)始新的任務(wù)之前，開(kāi)發(fā)者應該首先與配置管理系統同步。也就是說(shuō)，他們應該首先更新本地機器上的源 代碼。在舊的代碼基礎上編寫(xiě)代碼，這只會(huì )帶來(lái)麻煩和混亂。
然后，開(kāi)發(fā)者要隨時(shí)保持文件的更新。開(kāi)發(fā)者可以在一段任務(wù)完成之后將代碼集成到整個(gè)系統中，也可以在 任務(wù)的中途集成，但是在集成的時(shí)候必須保證所有的測試都能通過(guò)。
集成的第一步是要再次使開(kāi)發(fā)者的本地文件與代碼倉庫同步。代碼倉庫中所有新近有改動(dòng)的文件都要拷貝到開(kāi)發(fā)者的工作目錄中來(lái)，當文件發(fā)生沖突時(shí)，配置管理系統會(huì )向開(kāi)發(fā)者提出警告。然后，開(kāi)發(fā)者需要對同步后的工作集進(jìn)行創(chuàng )建，對這些文件運行BVT，并得到正確的結果。
現在，開(kāi)發(fā)者可以把新的文件提交到代碼倉庫中。提交完成之后，開(kāi)發(fā)者就需要等待主創(chuàng )建。如果主創(chuàng )建成功，那么這次歸還也是成功的。如果主創(chuàng )建失敗了，開(kāi)發(fā)者可以在本地修改。如果修改很簡(jiǎn)單，就可以直接提交；如果修改比較復雜，開(kāi)發(fā)者就需要放棄這次修改，重新同步自己的工作目錄，然后繼續在本地開(kāi)發(fā)、調試,然后再次提交。
某些系統強制要求歸還進(jìn)程逐個(gè)進(jìn)行。在這種情況下，系統中會(huì )有一個(gè)創(chuàng )建令牌，同一時(shí)間只有一個(gè)開(kāi)發(fā)者能拿到令牌。開(kāi)發(fā)者獲取創(chuàng )建令牌，再次同步文件，提交修改，然后釋放令牌。這就確保創(chuàng )建過(guò)程中，最多只能有一個(gè)開(kāi)發(fā)者在更新代碼倉庫。不過(guò)我們發(fā)現，即使沒(méi)有創(chuàng )建令牌，我們也很少遇到麻煩，所以我們也不用這種方法。經(jīng)常會(huì )有多個(gè)人同時(shí)向同一個(gè)主創(chuàng )建提交代碼的情況，但是這很少造成創(chuàng )建失敗，而且這樣的錯誤也很容 易修復。
同時(shí)，我們還讓開(kāi)發(fā)者自己來(lái)決定歸還過(guò)程中的小心程度。這反映出開(kāi)發(fā)者對集成錯誤出現幾率的評估。如果她覺(jué)得很有可能出現集成錯誤，那么她就會(huì )在歸還之前先做一次本地創(chuàng )建；如果她覺(jué)得根本不可能出現集成錯誤，那么她可以直接歸還。如果犯了錯誤，在主創(chuàng )建運行時(shí)她立刻就會(huì )發(fā)現，然后她就必須放棄自己的修改，找到出錯的地方。如果錯誤很容易發(fā)現、很容易修補，那么這種錯誤也是可以接受的。
總結
發(fā)展一個(gè)制度嚴密的自動(dòng)化創(chuàng )建過(guò)程對于項目的控制是很重要的。許多軟件先賢都這樣說(shuō)，但是我們發(fā)現， 這樣的過(guò)程在軟件開(kāi)發(fā)領(lǐng)域中仍然罕見(jiàn)。
關(guān)鍵是要讓所有的事情都完全自動(dòng)化，并且要經(jīng)常進(jìn)行集成，這樣才能盡快發(fā)現錯誤。然后，人們可以隨時(shí) 修改需要修改的東西，因為他們知道：如果他們做的修改引起了集成錯誤，那也是很容易發(fā)現和修補的。一旦獲得了這些利益，你會(huì )發(fā)現自己再也無(wú)法放下它們
聯(lián)系客服
