Martin Fowler 的持續集成(3)

　　當然，別指望測試就是萬(wàn)能的。常言道，測試并不代表就沒(méi)有bug。

　　每人每天都向主線(xiàn)提交代碼

　　集成首先在于交流，它使其他成員能夠看到你所做的修改。在這種頻繁的交流下，大家都能很快地知道開(kāi)發(fā)過(guò)程中所做的修改。

　　在向主線(xiàn)提交代碼之前，開(kāi)發(fā)人員必須保證本地構建成功。這當然也包括使測試全部通過(guò)。另外，在提交之前需要更新本地代碼以匹配主線(xiàn)代碼，然后在本地解決主線(xiàn)代碼與本地代碼之間的沖突，再在本地進(jìn)行構建。如果構建成功，便可以向主線(xiàn)提交代碼了。

　　在這種頻繁提交下，開(kāi)發(fā)者可以快速地發(fā)現自己代碼與他人代碼之間的沖突?？焖俳鉀Q問(wèn)題的關(guān)鍵在于快速地發(fā)現問(wèn)題。幾個(gè)小時(shí)的提交間隔使得代碼沖突也可以在幾個(gè)小時(shí)內發(fā)現，此時(shí)大家的修改都不多，沖突也不大，因此解決沖突也很簡(jiǎn)單。對于好幾周都發(fā)現不了的沖突，通常是很難解決的。

　　在更新本地代碼庫時(shí)就進(jìn)行構建，這意味著(zhù)我們既可以發(fā)現文本上的沖突，又可以發(fā)現編譯沖突。既然構建是自測試的，那么運行時(shí)的沖突也可以被檢測出來(lái)，而這樣的沖突往往是一些特別煩人的bug。由于提交間隔只有短短的幾個(gè)小時(shí)，bug便沒(méi)多少藏身之處了。再者，因為每次提交的修改都不多，你可以使用diff-debugging來(lái)幫你找出這些bug。

　　我的基本原則是：每個(gè)開(kāi)發(fā)者每天都應當向代碼庫進(jìn)行提交。在實(shí)踐中，越是頻繁提交，可能導致沖突的地方就越少，因而也越容易發(fā)現。

　　頻繁提交鼓勵開(kāi)發(fā)人員以幾個(gè)小時(shí)為單位來(lái)分割他們的代碼，這樣便于跟蹤進(jìn)度。通常，人們一開(kāi)始認為在短短的幾個(gè)小時(shí)內做不了什么事情，但我們發(fā)現找個(gè)導師和多實(shí)踐可以幫助他們學(xué)習。

　　每次提交都應在集成機上進(jìn)行構建

　　有了每日提交，也就又了每日測試，這應該表明主線(xiàn)處于健康狀態(tài)。但是在實(shí)踐中，的確有出錯的時(shí)候，原因之一在于紀律——有人并沒(méi)有在提交之前進(jìn)行本地更新和構建。另外，不同開(kāi)發(fā)機之間的環(huán)境不同也是一個(gè)原因。

　　因此，你應該保證在集成機上進(jìn)行構建，只有當集成機上構建成功后，才表明你的任務(wù)完成了。由于提交者需要對自己的提交負責，他就得盯著(zhù)主線(xiàn)上的構建，如果失敗，馬上修改。如果下班之前你提交的修改失敗了，那么，對不起，請修改好了才回家。

　　我見(jiàn)到過(guò)兩種方式來(lái)保證主線(xiàn)構建的成功：一是手動(dòng)構建，二是使用持續集成服務(wù)器。

　　手動(dòng)構建是最簡(jiǎn)單的，基本上與開(kāi)發(fā)者在本地做的構建差不多——先到集成機上拉下主線(xiàn)的最新代碼，然后運行構建命令，在構建過(guò)程中你得盯著(zhù)構建過(guò)程，如果構建成功，表明你的任務(wù)完成。(另見(jiàn)Jim Shore的描述。)

　　持續集成服務(wù)器則一直監視著(zhù)代碼庫，一旦檢測到有提交，便自動(dòng)拉下代碼到本機，然后開(kāi)始構建，并將結果通知提交者。只有當提交者收到通知后——通常是以電子郵件的方式，才表明自己的任務(wù)完成。

　　在ThoughtWorks，我們是持續集成服務(wù)器的忠實(shí)粉絲，我們領(lǐng)導了CruiseControl和CruiseControl.NET的初期開(kāi)發(fā)，此兩者均是廣為使用的CI服務(wù)器。從那時(shí)起，我們也開(kāi)發(fā)了商業(yè)化的Cruise。在幾乎每個(gè)項目中，我們都使用了CI服務(wù)器，并且結果是令人愉悅的。

　　不是所有人都傾向于使用CI服務(wù)器的，Jim Shore便給出了一個(gè)很好的論述，在此論述中，他解釋了為什么他更傾向于手動(dòng)構建。我同意他的看法——CI不過(guò)是安裝一些軟件而已，所有的實(shí)踐都應當旨在有效地完成持續集成。但同樣，許多使用CI服務(wù)器的團隊的確發(fā)現CI服務(wù)器是很好的工具。

　　有很多團隊定期的進(jìn)行構建，比如每晚構建。這和持續構建并不是一回事，而且對于持續集成來(lái)說(shuō)，也是不夠的。持續集成的關(guān)鍵在于盡快地發(fā)現問(wèn)題。而每晚構建意味著(zhù)整個(gè)白天都發(fā)現不了bug，如此，需要很長(cháng)的時(shí)間發(fā)現并清楚這些bug。

　　持續構建的重點(diǎn)在于，如果主線(xiàn)構建失敗，你應該馬上進(jìn)行修改。在持續集成中，你一直是在一個(gè)穩定的代碼庫基礎上進(jìn)行開(kāi)發(fā)。主線(xiàn)構建失敗并不是一件壞事，但是，如果這樣的情況經(jīng)常發(fā)生，那么就意味著(zhù)開(kāi)發(fā)人員對于本地更新并沒(méi)在意或者在提交之前并沒(méi)在本地構建。主線(xiàn)構建一旦失敗，必須馬上修正。為了避免主線(xiàn)構建失敗，也許你可以試試 pending head。

　　快速構建

　　持續集成的關(guān)鍵在于快速反饋，需要長(cháng)時(shí)間構建的CI是極其糟糕的。我的多數同事都認為一個(gè)小時(shí)的構建時(shí)間對于CI來(lái)說(shuō)決無(wú)道理可言。我也記得曾經(jīng)有團隊夢(mèng)想著(zhù)他們的構建能有多么多么的快，但有時(shí)我們不得不面對很難快速構建的情況。

　　對于多數項目來(lái)說(shuō)，將構建時(shí)間維持在10鐘之內是合理的，這也是XP的方針之一，我們多數項目也達到了這個(gè)目標。這種做法是值得的，因為這樣省下的時(shí)間是為開(kāi)發(fā)者節約的。

　　如果你的構建長(cháng)到了一小時(shí)，那么想使其加速便不是那么容易了。對于企業(yè)級應用來(lái)說(shuō)，我們發(fā)現構建時(shí)間的瓶頸通常發(fā)生在測試上，特別是那些需要于外部交互的測試——比如數據庫。

　　可能最好的解決辦法是引入階段性構建(也叫構建管道或者部署管道)，因為構建事實(shí)上是分階段性的。代碼提交后首先觸發(fā)的是構建稱(chēng)為提交構建，提交構建應該快速完成，而棘手的是怎么保持速度與查找bug之間的平衡。

　　提交構建成功后，其他人便可自信的工作了。但是，你可能還有其它跑得比較慢的測試需要寫(xiě)，這時(shí)可以用額外的機器來(lái)專(zhuān)門(mén)跑這些耗時(shí)的測試。

　　一個(gè)簡(jiǎn)單的例子是將構建分為兩個(gè)階段，第一個(gè)階段完成編譯，并且跑那些不需要外部交互的單元測試，數據庫交互也通過(guò)stub的方式完全消除掉。這些測試可以很快跑完，原則是將其保持在10分鐘之內。但是，對于那些需要大量外部交互——特別是涉及到真實(shí)數據庫交互時(shí)才能發(fā)現的bug，這個(gè)階段便無(wú)能為力了。第二個(gè)階段跑的測試則需要操作真實(shí)的數據庫了，同時(shí)還應包括端到端測試。這個(gè)階段可能需要幾個(gè)小時(shí)。

　　在這種情況下，通常將第一階段視為提交構建，并將此做為主要的CI周期。第二階段則可在有必要時(shí)才進(jìn)行，如果這個(gè)階段構建失敗，它也不需要像第一階段那樣“停下全部手頭的工作”，但也應該得到盡快的修改。第二階段的構建不見(jiàn)得需要保持一直通過(guò)，對于已經(jīng)發(fā)現的bug來(lái)說(shuō)，可以在之后幾天修改。對于這個(gè)案例來(lái)說(shuō)，第二階段全是測試，因為通常情況下最慢的即是測試。

原文轉自：http://kjueaiud.com