持續(xù)集成（第一版）

--Martin Fowler & Matthew Foemmel著 透明 譯
英文原文版權(quán)由Martin Fowler擁有
Original text is copyrighted by Martin Fowler
原文鏈接：http://martinfowler.com/articles/continuousIntegration.html

    在任何軟件開發(fā)過程中都有一個重要的部分：得到可靠的軟件創(chuàng)建（build）版本。盡管知道創(chuàng)建的重要性，但是我們?nèi)匀粫?jīng)常因為創(chuàng)建失敗而驚訝不已。在這篇文章里，我們將討論Matt（Matthew Foemmel）在ThoughtWorks的一個重要項目中實施的過程，這個過程在我們的公司里日益受到重視。它強調(diào)完全自動化的、可重復的創(chuàng)建過程，其中包括每天運行多次的自動化測試。它讓開發(fā)者可以每天進行系統(tǒng)集成，從而減少了集成中的問題。
     ThoughtWorks公司已經(jīng)開放了CruiseControl軟件的源代碼，這是一個自動化持續(xù)集成的工具。此外，我們還提供CruiseControl、Ant和持續(xù)集成方面的顧問服務。如果需要更多的信息，請與Josh Mackenzie（jmackenz@ThoughtWorks.com）聯(lián)系。
本文有以下主要內(nèi)容：

• 持續(xù)集成的優(yōu)點
• 集成越頻繁，效果越好
• 一次成功的創(chuàng)建是什么樣的？
• 單一代碼源
• 自動化創(chuàng)建腳本
• 自測試的代碼
• 主創(chuàng)建
• 代碼回歸
• 總結(jié)

      在軟件開發(fā)的領(lǐng)域里有各種各樣的“最佳實踐”，它們經(jīng)常被人們談起，但是似乎很少有真正得到實現(xiàn)的。這些實踐最基本、最有價值的就是：都有一個完全自動化的創(chuàng)建、測試過程，讓開發(fā)團隊可以每天多次創(chuàng)建他們的軟件。“日創(chuàng)建”也是人們經(jīng)常討論的一個觀點，McConnell在他的《快速軟件開發(fā)》中將日創(chuàng)建作為一個最佳實踐來推薦，同時日創(chuàng)建也是微軟很出名的一項開發(fā)方法。但是，我們更支持XP社群的觀點：日創(chuàng)建只是最低要求。一個完全自動化的過程讓你可以每天完成多次創(chuàng)建，這是可以做到的，也是完全值得的。
      在這里，我們使用了“持續(xù)集成（Continuous Integration）”這個術(shù)語，這個術(shù)語來自于XP（極限編程）的一個實踐。但是我們認為：這個實踐早就存在，并且很多并沒有考慮XP的人也在使用著它。只不過我們一直用XP作為軟件開發(fā)過程的標準，XP也對我們的術(shù)語和實踐產(chǎn)生了深遠的影響。盡管如此，你還是可以只使用持續(xù)集成，而不必使用XP的任何其他部分——實際上，我們認為：對于任何切實可行的軟件開發(fā)活動，持續(xù)集成都是很基本的組成部分。
實現(xiàn)自動化日創(chuàng)建需要做以下幾部分的工作：

• 將所有的源代碼保存在單一的地點，讓所有人都能從這里獲取最新的源代碼（以及以前的版本）。
• 使創(chuàng)建過程完全自動化，讓任何人都可以只輸入一條命令就完成系統(tǒng)的創(chuàng)建。
• 使測試完全自動化，讓任何人都可以只輸入一條命令就運行一套完整的系統(tǒng)測試。
• 確保所有人都可以得到最新、最好的可執(zhí)行文件。
• 所有這些都必須得到制度的保證。我們發(fā)現(xiàn)，向一個項目中引入這些制度需要耗費相當大的精力。但是，我們也發(fā)現(xiàn)，一旦制度建立起來，保持它的正常運轉(zhuǎn)就不需要花多少力氣了。

1. 持續(xù)集成的優(yōu)點
      描述持續(xù)集成最大的難點在于：它從根本上改變了整個開發(fā)模式。如果沒有在持續(xù)集成的實踐環(huán)境中工作過，你很難理解它的開發(fā)模式。實際上，在單獨工作的時候，絕大多數(shù)人都能感覺到這種氣氛——因為他們只需要與自己的系統(tǒng)相集成。對于許多人來說，“團隊開發(fā)”這個詞總讓他們想起軟件工程領(lǐng)域中的一些難題。持續(xù)集成減少了這些難題的數(shù)量，代之以一定的制度。
      持續(xù)集成最基本的優(yōu)點就是：它完全避免了開發(fā)者們的“除蟲會議”——以前開發(fā)者們經(jīng)常需要開這樣的會，因為某個人在工作的時候踩進了別人的領(lǐng)域、影響了別人的代碼，而被影響的人還不知道發(fā)生了什么，于是bug就出現(xiàn)了。這種bug是最難查的，因為問題不是出在某一個人的領(lǐng)域里，而是出在兩個人的交流上面。隨著時間的推移，問題會逐漸惡化。通常，在集成階段出現(xiàn)的bug早在幾周甚至幾個月之前就已經(jīng)存在了。結(jié)果，開發(fā)者需要在集成階段耗費大量的時間和精力來尋找這些bug的根源。
      如果使用持續(xù)集成，這樣的bug絕大多數(shù)都可以在引入的同一天就被發(fā)現(xiàn)。而且，由于一天之中發(fā)生變動的部分并不多，所以可以很快找到出錯的位置。如果找不到bug究竟在哪里，你也可以不把這些討厭的代碼集成到產(chǎn)品中去。所以，即使在最壞的情況下，你也只是不添加引起bug的特性而已。（當然，可能你對新特性的要求勝過了對bug的憎恨，不過至少你可以多一種選擇。）
      到現(xiàn)在為止，持續(xù)集成還不能保證你抓到所有集成時出現(xiàn)的bug。持續(xù)集成的排錯能力取決于測試技術(shù)，眾所周知，測試無法證明已經(jīng)找到了所有的錯誤。關(guān)鍵是在于：持續(xù)集成可以及時抓到足夠多的bug，這就已經(jīng)值回它的開銷了。
      所以，持續(xù)集成可以減少集成階段“捉蟲”消耗的時間，從而最終提高生產(chǎn)力。盡管現(xiàn)在還不知道是否有人對這種方法進行過科學研究，但是作為一種實踐性的方法，很明顯它是相當有效的。持續(xù)集成可以大幅減少耗費在“集成地獄”中的時間，實際上，它可以把地獄變成小菜一碟。

2. 集成越頻繁，效果越好
      持續(xù)集成有一個與直覺相悖的基本要點：經(jīng)常性的集成比很少集成要好。對于持續(xù)集成的實踐者來說，這是很自然的；但是對于從未實踐過持續(xù)集成的人來說，這是與直觀印象相矛盾的。
      如果你的集成不是經(jīng)常進行的（少于每天一次），那么集成就是一件痛苦的事情，會耗費你大量的時間與精力。我們經(jīng)常聽見有人說：“在一個大型的項目中，不能應用日創(chuàng)建”，實際上這是一種十分愚蠢的觀點。
      不過，還是有很多項目實踐著持續(xù)集成。在一個五十人的團隊、二十萬行代碼的項目中，我們每天要集成二十多次。微軟在上千萬行代碼的項目中仍然堅持日創(chuàng)建。
      持續(xù)集成之所以可行，原因在于集成的工作量是與兩次集成間隔時間的平方成正比的。盡管我們還沒有具體的衡量數(shù)據(jù)，但是可以大概估計出來：每周集成一次所需的工作量絕對不是每天集成的5倍，而是大約25倍。所以，如果集成讓你感到痛苦，也許就說明你應該更頻繁地進行集成。如果方法正確，更頻繁的集成應該能減少你的痛苦，讓你節(jié)約大量時間。
      持續(xù)集成的關(guān)鍵是自動化。絕大多數(shù)的集成都可以而且應該自動完成。讀取源代碼、編譯、連接、測試，這些都可以自動完成。最后，你應該得到一條簡單的信息，告訴你這次創(chuàng)建是否成功：“yes”或“no”。如果成功，本次集成到此為止；如果失敗，你應該可以很簡單地撤消最后一次的修改，回到前一次成功的創(chuàng)建。在整個創(chuàng)建過程中，完全不需要你動腦子。
      如果有了這樣一套自動化過程，你隨便想多頻繁進行創(chuàng)建都可以。唯一的局限性就是創(chuàng)建過程本身也會消耗一定的時間。（譯注：不過與捉蟲所需的時間比起來，這點時間是微不足道的。）

3. 一次成功的創(chuàng)建是什么樣的？
      有一件重要的事需要確定：怎樣的創(chuàng)建才算是成功的？看上去很簡單，但是如此簡單的事情有時卻會變得一團糟，這是值得注意的。有一次，Martin Fowler去檢查一個項目。他問這個項目是否執(zhí)行日創(chuàng)建，得到了肯定的回答。幸虧Ron Jeffries也在場，他又提了一個問題：“你們?nèi)绾翁幚韯?chuàng)建錯誤？”回答是：“我們給相關(guān)的人發(fā)一個e-mail。”實際上，這個項目已經(jīng)好幾個月沒有得到成功的創(chuàng)建了。這不是日創(chuàng)建，這只是日創(chuàng)建的嘗試。
      對于下列“成功創(chuàng)建”的標準，我們還是相當自信的：

• 所有最新的源代碼都被配置管理系統(tǒng)驗證合格
• 所有文件都通過重新編譯
• 得到的目標文件（在我們這里就是Java的class文件）都通過連接，得到可執(zhí)行文件
• 系統(tǒng)開始運行，針對系統(tǒng)的測試套件（在我們這里大概有150個測試類）開始運行
• 如果所有的步驟都沒有錯誤、沒有人為干涉，所有的測試也都通過了，我們就得到了一個成功的創(chuàng)建

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

4. 單一代碼源
      為了實現(xiàn)每日集成，任何開發(fā)者都需要能夠很容易地獲取全部最新的源代碼。以前，如果要做一次集成，我們就必須跑遍整個開發(fā)中心，詢問每一個程序員有沒有新的代碼，然后把這些新代碼拷貝過來，再找到合適的插入位置……沒有什么比這更糟糕的了。
      辦法很簡單。任何人都應該可以帶一臺干凈的機器過來，連上局域網(wǎng)，然后用一條命令就得到所有的源文件，馬上開始系統(tǒng)的創(chuàng)建。
最簡單的解決方案就是：用一套配置管理（源代碼控制）系統(tǒng)作為所有代碼的來源。配置管理系統(tǒng)通常都設(shè)計有網(wǎng)絡(luò)功能，并且?guī)в凶岄_發(fā)者輕松獲取源代碼的工具。而且，它們還提供版本管理工具，這樣你可以很輕松地找到文件以前的版本。成本就更不成問題了，CVS就是一套出色的開放源代碼的配置管理工具。
      所有的源文件都應該保存在配置管理系統(tǒng)中。我說的這個“所有”常常比人們想到的還要多，它還包括創(chuàng)建腳本、屬性文件、數(shù)據(jù)庫調(diào)度DLL、安裝腳本、以及在一臺干凈的機器上開始創(chuàng)建所需的其他一切東西。經(jīng)常都能看到這樣的情況：代碼得到了控制，但是其他一些重要的文件卻找不到了。
      盡量確保所有的東西都保存在配置管理系統(tǒng)的同一棵代碼源樹中。有時候為了得到不同的組件，人們會使用配置管理系統(tǒng)中不同的項目。這帶來的麻煩就是：人們不得不記住哪個組件的哪個版本使用了其他組件的哪些版本。在某些情況下，你必須將代碼源分開，但是這種情況出現(xiàn)的幾率比你想象的要小得多。你可以在從一棵代碼源樹創(chuàng)建多個組件，上面那些問題可以通過創(chuàng)建腳本來解決，而不必改變存儲結(jié)構(gòu)。

5. 自動化創(chuàng)建腳本
      如果你編寫的是一個小程序，只有十幾個文件，那么應用程序的創(chuàng)建可能只是一行命令的事：javac *.java。更大的項目就需要更多的創(chuàng)建工作：你可能把文件放在許多目錄里面，需要確保得到的目標代碼都在適當?shù)奈恢茫怀司幾g，可能還有連接的步驟；你可能還從別的文件中生成了代碼，在編譯之前需要先生成；測試也需要自動運行。
      大規(guī)模的創(chuàng)建經(jīng)常會耗費一些時間，如果只做了一點小小的改動，當然你不會希望重新做所有這些步驟。所以好的創(chuàng)建工具會自動分析需要改變的部分，常見的方法就是檢查源文件和目標文件的修改日期，只有當源文件的修改日期遲于目標文件時，才會重新編譯。于是，文件之間的依賴就需要一點技巧了：如果一個目標文件發(fā)生了變化，那么只有那些依賴它的目標文件才會重新編譯。編譯器可能會處理這類事情，也可能不會。
取決于自己的需要，你可以選擇不同的創(chuàng)建類型：你創(chuàng)建的系統(tǒng)可以有測試代碼，也可以沒有，甚至還可以選擇不同的測試集；一些組件可以單獨創(chuàng)建。創(chuàng)建腳本應該讓你可以根據(jù)不同的情況選擇不同的創(chuàng)建目標。
      你輸入一行簡單的命令之后，幫你挑起這副重擔常常是腳本。你使用的可能是shell腳本，也可能是更復雜的腳本語言（例如Perl或Python）。但是很快你就會發(fā)現(xiàn)一個專門設(shè)計的創(chuàng)建環(huán)境是很有用的，例如Unix下的make工具。
      在我們的Java開發(fā)中，我們很快就發(fā)現(xiàn)需要一個更復雜的解決方案。Matt用了相當多的時間開發(fā)了一個用于企業(yè)級Java開發(fā)的創(chuàng)建工具，叫做Jinx。但是，最近我們已經(jīng)轉(zhuǎn)而使用開放源代碼的創(chuàng)建工具Ant（http://jakarta.apache.org/ant/index.html）。Ant的設(shè)計與Jinx非常相似，也支持Java文件編譯和Jar封裝。同時，編寫Ant的擴展也很容易，這讓我們可以在創(chuàng)建過程中完成更多的任務。
      許多人都使用IDE，絕大多數(shù)的IDE中都包含了創(chuàng)建管理的功能。但是，這些文件都依賴于特定的IDE，而且經(jīng)常比較脆弱，而且還需要在IDE中才能工作。IDE的用戶可以建立自己的項目文件，并且在自己的單獨開發(fā)中使用它們。但是我們的主創(chuàng)建過程用Ant建立，并且在一臺使用Ant的服務器上運行。

6. 自測試的代碼
      只讓程序通過編譯還是遠遠不夠的。盡管強類型語言的編譯器可以指出許多問題，但是即使成功通過了編譯，程序中仍然可能留下很多錯誤。為了幫助跟蹤這些錯誤，我們非常強調(diào)自動化測試——這也是XP提倡的另一個實踐。
      XP將測試分為兩類：單元測試和容納測試（也叫功能測試）。單元測試是由開發(fā)者自己編寫的，通常只測試一個類或一小組類。容納測試通常是由客戶或外部的測試組在開發(fā)者的幫助下編寫的，對整個系統(tǒng)進行端到端的測試。這兩種測試我們都會用到，并且盡量提高測試的自動化程度。
      作為創(chuàng)建的一部分，我們需要運行一組被稱為“BVT”（Build Verification Tests，創(chuàng)建確認測試）的測試。BVT中所有的測試都必須通過，然后我們才能宣布得到了一個成功的創(chuàng)建。所有XP風格的單元測試都屬于BVT。由于本文是關(guān)于創(chuàng)建過程的，所以我們所說的“測試”基本上都是指BVT。請記住，除了BVT之外，還有一條測試線存在（譯注：指功能測試），所以不要把BVT和整體測試、QA等混為一談。實際上，我們的QA小組根本不會看到?jīng)]有通過BVT的代碼，因為他們只對成功的創(chuàng)建進行測試。
      有一條基本的原則：在編寫代碼的同時，開發(fā)者也應該編寫相應的測試。完成任務之后，他們不但要歸還（check in）產(chǎn)品代碼，而且還要歸還這些代碼的測試。這也跟XP的“測試第一”的編程風格很相似：在編寫完相應的測試、并看到測試失敗之前，你不應該編寫任何代碼。所以，如果想給系統(tǒng)添加新特性，你首先應該編寫一個測試。只有當新的特性已經(jīng)實現(xiàn)了以后，這個測試才可能通過。然后，你的工作就是讓這個測試能夠通過。
      我們用Java編寫這些測試，與開發(fā)使用同樣的語言，所以編寫測試與編寫代碼沒有太大的區(qū)別。我們使用JUnit（http://www.junit.org/）來作為組織、編寫測試的框架。JUnit是一個簡單的框架，讓我們可以快速編寫測試、將測試組織為套件、并以交互或批處理的模式來運行測試套件。（JUnit是xUnit家族的Java版本——xUnit包括了幾乎所有語言的測試框架。）
      在編寫軟件的過程中，在每一次的編譯之后，開發(fā)者通常都會運行一部分單元測試。這實際上提高了開發(fā)者的工作效率，因為這些單元測試可以幫助你發(fā)現(xiàn)代碼中的邏輯錯誤。然后，你就沒必要去調(diào)試查錯，只需要注意最后一次運行測試之后修改的代碼就行了。這個修改的范圍應該很小，所以尋找bug也就容易多了。
并非所有的人都嚴格遵循XP“測試第一”的風格，但是在第一時間編寫測試的好處是顯而易見的。它們不但讓每個人的工作效率更高，而且由這些測試構(gòu)成的BVT更能捕捉到系統(tǒng)中的錯誤。因為BVT每天要運行好幾次，所以BVT檢查出的任何問題都是比較容易改正的，原因很簡單：我們只做了相當小范圍的修改，所以我們可以在這個范圍內(nèi)尋找bug。在修改過的一小塊代碼中排錯當然比跟蹤整個系統(tǒng)來排錯要有效多了。
      當然，你不能指望測試幫你找到所有的問題。就象人們常說的：測試不能證明系統(tǒng)中不存在錯誤。但是，盡善盡美不是我們唯一的要求。不夠完美的測試只要經(jīng)常運行，也比永遠寫不出來的“完美測試”要好得多。
      另一個相關(guān)的問題就是：開發(fā)者們?yōu)樽约旱拇a編寫測試。我們經(jīng)常聽人說：開發(fā)者不應該測試自己的代碼，因為他們很容易忽視自己工作中的錯誤。盡管這也是事實，但是自測試過程需要快速將測試轉(zhuǎn)入代碼基礎(chǔ)中。這種快速轉(zhuǎn)換的價值超過獨立測試者的價值。所以，我們還是用開發(fā)者自己編寫的測試來構(gòu)造BVT，但是仍然有獨立編寫的容納測試。
      自測試另一個很重要的部分就是它通過反饋——XP的一項核心價值——來提高測試的質(zhì)量。這里的反饋來自于從BVT中逃脫的bug。自測試的規(guī)則是：除非你在BVT中加入了相應的測試，否則就不能修正任何錯誤。這樣，每當要修正某個錯誤的時候，你都必須添加相應的測試，以確保BVT不會再把錯誤放過去。而且，這個測試應該引導你去考慮更多的測試、編寫更多的測試來加強BVT。

7. 主創(chuàng)建
      創(chuàng)建過程的自動化對于單個開發(fā)者來說很有意義，但是它真正發(fā)光的，還是在整個系統(tǒng)的主創(chuàng)建（master build）的生成。我們發(fā)現(xiàn)，主創(chuàng)建過程能讓整個團隊走到一起來，讓他們及早發(fā)現(xiàn)集成中的問題。
      第一步是要選擇運行主創(chuàng)建的機器。我們選擇了一臺叫做“投石車”的計算機（我們經(jīng)常玩“帝國時代”J），這是一臺裝有四個CPU的服務器，非常適合專門用來做創(chuàng)建。（由于完整的創(chuàng)建需要相當長的時間，所以這種馬力是必須的。）
      創(chuàng)建進程是在一個隨時保持運行的Java類中進行的。如果沒有創(chuàng)建任務，創(chuàng)建進程就一直循環(huán)等待，每過幾分鐘去檢查一下代碼倉庫。如果在最后的創(chuàng)建之后沒有人歸還任何代碼，進程就繼續(xù)等待。如果代碼倉庫中有了新的代碼，就開始創(chuàng)建。
      創(chuàng)建的第一階段是完全提取倉庫中的代碼。Starteam已經(jīng)為我們提供了相當好的Java API，所以切入代碼倉庫也很容易。守護進程（daemon）會觀察五分鐘以前的倉庫，看最近五分鐘里面有沒有人歸還了代碼。如果有，守護進程就會考慮等五分鐘再提取代碼（以免在別人歸還代碼的過程中提取）。
守護進程將全部代碼提取到投石機的一個目錄中。提取完成之后，守護進程就會在這個目錄里調(diào)用Ant腳本。然后，Ant會接管整個創(chuàng)建過程，對所有源代碼做一次完整的創(chuàng)建。Ant腳本會負責整個編譯過程，并把得到的class文件放進六個jar包里，發(fā)布到EJB服務器上。
      當Ant完成了編譯和發(fā)布的工作之后，創(chuàng)建守護進程就會在EJB服務器上開始運行新的jar，同時開始運行BVT測試套件。如果所有的測試都能正常運行通過，我們就得到了一個成功的創(chuàng)建。然后創(chuàng)建守護進程就會回到Starteam，將所有提取出的源代碼標記上創(chuàng)建號。然后，守護進程會觀察創(chuàng)建過程中是否還有人歸還了代碼。如果有，就再開始一次創(chuàng)建；如果沒有，守護進程就回到它的循環(huán)中，等待下一次的歸還。
      創(chuàng)建結(jié)束之后，創(chuàng)建守護進程會給所有向最新一次創(chuàng)建歸還了代碼的開發(fā)者發(fā)一個e-mail，匯報創(chuàng)建的情況。如果把創(chuàng)建留在代碼歸還之后去做，而又不用e-mail向開發(fā)者通報創(chuàng)建的情況，我們通常認為這是不好的組織形式。
      守護進程將所有的步驟都寫在XML格式的日志文件里面。投石車上會運行一個servlet，允許任何人通過它檢查日志，以觀察創(chuàng)建的狀態(tài)。（見圖1）
屏幕上會顯示出創(chuàng)建是否正在運行、開始運行的時間。在左邊有所有創(chuàng)建的歷史記錄，成功的、失敗的都記錄在案。點擊其中的某一條記錄，就會顯示出這次創(chuàng)建的詳細信息：編譯是否通過、測試的結(jié)果、發(fā)生了哪些變化……
      我們發(fā)現(xiàn)很多開發(fā)者都經(jīng)常看看這個頁面，因為它讓他們看到項目發(fā)展的方向，看到隨著人們不斷歸還代碼而發(fā)生的變化。有時我們也會在這個頁面上放一些其他的項目新聞，但是需要把握好尺度。
      要讓開發(fā)者能在自己的本地機器上模擬主創(chuàng)建過程，這是很重要的。這樣，如果集成錯誤出現(xiàn)了，開發(fā)者可以在自己的機器上研究、調(diào)試，而不必真的執(zhí)行主創(chuàng)建過程。而且，開發(fā)者也可以在歸還代碼之前先在本地執(zhí)行創(chuàng)建，從而降低了主創(chuàng)建失敗的可能性。
      這里有一個比較重要的問題：主創(chuàng)建應該是干凈的創(chuàng)建（完全從源代碼開始）還是增量創(chuàng)建？增量創(chuàng)建會快得多，但是也增大了引入錯誤的風險，因為有些部分是沒有編譯的。而且我們還有無法重新創(chuàng)建的風險。我們的創(chuàng)建速度相當快（20萬行代碼約15分鐘），所以我們樂于每次都做干凈的創(chuàng)建。但是，有些團隊喜歡在大多數(shù)時候做增量創(chuàng)建，但是當那些奇怪的問題突然出現(xiàn)時，也經(jīng)常性地做干凈的創(chuàng)建（至少每天一次）。
圖1：運行在投石車上的servlet

8. 代碼回歸（Check in）
      使用自動化創(chuàng)建就意味著開發(fā)者應該遵循某種節(jié)奏來開發(fā)軟件，最重要的就是他們應該經(jīng)常集成。我們曾經(jīng)見過一些組織，他們也做日創(chuàng)建，但是其中的開發(fā)者卻不經(jīng)常歸還代碼。如果開發(fā)者幾周才歸還一次代碼，那么日創(chuàng)建又有什么意義呢？我們遵循的原則是：每個開發(fā)者至少每天要歸還一次代碼。
在開始新的任務之前，開發(fā)者應該首先與配置管理系統(tǒng)同步。也就是說，他們應該首先更新本地機器上的源代碼。在舊的代碼基礎(chǔ)上編寫代碼，這只會帶來麻煩和混亂。
      然后，開發(fā)者要隨時保持文件的更新。開發(fā)者可以在一段任務完成之后將代碼集成到整個系統(tǒng)中，也可以在任務的中途集成，但是在集成的時候必須保證所有的測試都能通過。
      集成的第一步是要再次使開發(fā)者的本地文件與代碼倉庫同步。代碼倉庫中所有新近有改動的文件都要拷貝到開發(fā)者的工作目錄中來，當文件發(fā)生沖突時，配置管理系統(tǒng)會向開發(fā)者提出警告。然后，開發(fā)者需要對同步后的工作集進行創(chuàng)建，對這些文件運行BVT，并得到正確的結(jié)果。
      現(xiàn)在，開發(fā)者可以把新的文件提交到代碼倉庫中。提交完成之后，開發(fā)者就需要等待主創(chuàng)建。如果主創(chuàng)建成功，那么這次歸還也是成功的。如果主創(chuàng)建失敗了，開發(fā)者可以在本地修改。如果修改很簡單，就可以直接提交；如果修改比較復雜，開發(fā)者就需要放棄這次修改，重新同步自己的工作目錄，然后繼續(xù)在本地開發(fā)、調(diào)試，然后再次提交。
      某些系統(tǒng)強制要求歸還進程逐個進行。在這種情況下，系統(tǒng)中會有一個創(chuàng)建令牌，同一時間只有一個開發(fā)者能拿到令牌。開發(fā)者獲取創(chuàng)建令牌，再次同步文件，提交修改，然后釋放令牌。這就確保創(chuàng)建過程中，最多只能有一個開發(fā)者在更新代碼倉庫。不過我們發(fā)現(xiàn)，即使沒有創(chuàng)建令牌，我們也很少遇到麻煩，所以我們也不用這種方法。經(jīng)常會有多個人同時向同一個主創(chuàng)建提交代碼的情況，但是這很少造成創(chuàng)建失敗，而且這樣的錯誤也很容易修復。
      同時，我們還讓開發(fā)者自己來決定歸還過程中的小心程度。這反映出開發(fā)者對集成錯誤出現(xiàn)幾率的評估。如果她覺得很有可能出現(xiàn)集成錯誤，那么她就會在歸還之前先做一次本地創(chuàng)建；如果她覺得根本不可能出現(xiàn)集成錯誤，那么她可以直接歸還。如果犯了錯誤，在主創(chuàng)建運行時她立刻就會發(fā)現(xiàn)，然后她就必須放棄自己的修改，找到出錯的地方。如果錯誤很容易發(fā)現(xiàn)、很容易修補，那么這種錯誤也是可以接受的。

9. 總結(jié)
      發(fā)展一個制度嚴密的自動化創(chuàng)建過程對于項目的控制是很重要的。許多軟件先賢都這樣說，但是我們發(fā)現(xiàn)，這樣的過程在軟件開發(fā)領(lǐng)域中仍然罕見。
關(guān)鍵是要讓所有的事情都完全自動化，并且要經(jīng)常進行集成，這樣才能盡快發(fā)現(xiàn)錯誤。然后，人們可以隨時修改需要修改的東西，因為他們知道：如果他們做的修改引起了集成錯誤，那也是很容易發(fā)現(xiàn)和修補的。一旦獲得了這些利益，你會發(fā)現(xiàn)自己再也無法放下它們。