組態管理之持續整合

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

雖然持續整合已經講了很多年了，為了保持知識的連貫性，還是總結一篇吧，文中很多內容來自網路

-

持續整合的目的，就是讓產品可以快速迭代，同時還能保持高品質。它的核心措施是，代碼整合到主幹之前，必須通過自動化測試。只要有一個測試案例失敗，就不能整合。
Martin Fowler說過，"持續整合並不能消除Bug，而是讓它們非常容易發現和改正。"

為什麼要做持續整合

在《Code Complete》裡提到了，對於持續整合（在書中，Steve McConnell使用Incremental Integration的術語）有以下幾點好處：

• 易於定位錯誤。也就是當你的持續整合失敗了，說明你新加的代碼或者修改的代碼引起了錯誤，這樣你很容易的就可以知道到底是誰犯了錯誤，可以找誰來討論。
• 及早在項目裡取得系統級的成果。因為代碼已經被整合起來了，所以即使整個系統還不是那麼可用，但至少你和你的團隊都已經可以看到它已經在那了。
• 改善對進度的控制。這點非常明顯，如果每天都在整合，當然每天都可以看到哪些功能可以使用，哪些功能還沒有實現。如果你是程式員，你不用在彙報任務的時候說我完成了多少百分比而煩惱，而如果你是專案經理的話，那麼你也不再煩惱程式員說完成了編碼的50%到底是個什麼概念。
• 改善客戶關係。理由同上。
• 更加充分地測試系統中的各個單元。這也是我們常講的Daily Build與Smoke Test相結合帶來的絕大好處。
• 能在更短的時間裡建造整個系統。這點恐怕要你實施以後才能得出結論。就我們而言，持續整合並沒有為每個項目都縮短時間，但卻比沒有實施時，項目更加可控，也更加有保證。

隨著時間的推移，持續整合帶來的更多好處，也逐漸被認識到了，比如說：

• 有助於項目的開發資料的收集。比如說，項目代碼量的變化，經常出錯的Tests，經常出錯的source code，等等。
• 與其它工具結合的持續代碼品質改進。如與CheckStyle, PMD, FindBugs, Fxcop等等等等的結合。
• 與測試載入器或者架構結合的持續測試。如與xUnit，SilkTest, LoadRunner等等的結合。
• 便於Code Review。在每個build裡，我們都可以知道與前一個build之間有什麼改動，然後針對這些改動，我們就可以實施Code Review了。
• 便於開發流程的管理。比如說，要把一個開發的build提交給測試組作測試，測完滿意了，再提交到發布組去發布。

持續整合實踐

實踐的意思簡單說就是怎麼做。從最初martin fowler 這老爺子的最初文章中有10個實踐，下面我們會一一來講。

1. 維護一個單一的程式碼程式庫

　　軟體項目需要大量的檔案協同工作來構建出最終的產品。跟蹤所有的檔案需要大量的工作，尤其是在多個開發人員參與的項目中。因此，我們可以並不驚奇的看到，不同的軟體Team Dev都在開發用於管理這些檔案的工具——原始程式碼控制工具，也叫組態管理，版本控制系統，程式碼程式庫等。這些工具是多數軟體項目不可分的組成部分。然而，令人傷心並吃驚的是，並不是所有的項目都使用了這樣的工具。我的確見到（雖然很少）不使用這些工具的項目，它們使用本地和共用磁碟這種混亂的結合來共同工作。

　　因此，做為最基本的持續整合實踐，請保證你使用一款體面的代碼管理系統。成本不是問題，有許多高品質的開原始程式碼控制工具存在。當前的選擇為Subversion（譯者註：現在有了更新的hg和Git）。（更老的開源工具CVS如今仍然被大量使用，雖然比沒有強，但是Subversion是更現代的選擇。）有趣的是，當我和一些開發人員聊天時，我發現相比起多數商業化的代碼管理系統，他們更喜歡Subversion。據我所知，唯一值得花錢買的只有Perforce。

　　當你有了代碼管理系統之後，確保每個開發人員都能方便的獲得到原始碼。不應該有人還在問：“foo-whiffle 檔案在哪兒？”所有東西都必須在程式碼程式庫裡。

　　雖然許多團隊都在使用程式碼程式庫，但是我經常發現，他們並不把所有東西都放在裡面。如果大家需要使用一個檔案，他們知道該檔案放到程式碼程式庫中，但是，構建所需的所有都應該包含在程式碼程式庫裡，包括測試指令碼，屬性檔案，資料庫模式檔案，安裝指令碼和第三方庫等。我所知道的有項目將編譯器加到程式碼程式庫中的（對於早期脆弱的C++編譯器來說非常重要）。基本原則是：在一台新機器上check out代碼後構建也能構建成功。新機器上的東西應該盡量的少，通常包括很大的，難於安裝的，並且穩定的軟體，比如作業系統，Java開發環境或者資料庫管理系統等。

　　你需要將構建所需的所有東西都加到代碼管理系統中，同時也需要將大家經常操作的東西方進去，IDE配置便是一個很好的例子，這樣便於大家共用IDE配置。

　　版本控制系統的一大功能是它允許你建立多個分支，以此來處理不同的“開發流”。這種功能很有用，但卻經常被過度使用以至給開發人員帶來了不少麻煩。所以，你需要將分支的使用最小化，特別建議使用主線，即項目中只有單一的開發分支，並且每人在多數時間裡都在“離線”工作。

　　總之，你應該將構建所需的所有東西都放在代碼管理系統中，而不應該將構建的輸出放進去。有些朋友確實將構建輸出放在代碼管理系統中，但我認為這是一個壞味道，可能導致更深的問題——通常是你無法完成重新構建。

1. 使構建自動化

　　將原始碼變成一個能啟動並執行軟體系統通常是一個複雜的過程，包括編譯，檔案搬移，載入資料庫模式等等。但其中大多數任務都是可以自動化的，並且也應該被自動化。讓人去輸入奇怪的命令或點擊對話方塊是非常耗時的，而且從根本上來說也是個錯誤的做法。

　　構建所需的自動化環境對於軟體系統來說是一個通用功能。Unix的Make已經誕生好多年了，Java社區有Ant， .NET社區有Nant，現在又有了MSBuild。當你用這些工具構建和啟動系統時，請確保只使用一個命令完成任務。

　　一個常見的錯誤是在自動化構建裡並沒有完全包括構建所需的東西。構建過程中應該從程式碼程式庫裡取得資料庫模式檔案並自動執行之。結合我上文所講的原則來看，任何人都應該能夠在一台新機器上拉下程式碼程式庫中的代碼，並只用一個命令將系統運行起來。

　　構建指令碼是多種多樣的，通常特定於某個平台或社區，但情況並不必須如此。我們的多數Java項目都使用Ant，而另外有些用Ruby（Ruby世界的Rake是一個非常不錯的構建工具）。我們用Ant完成了早期的一個微軟COM工程的構建自動化，並從中大獲裨益。

　　大型的構建通常需要很長的時間，而在你只做了很小的修改的情況下，你是不想運行所有的構建步驟的。因此，優秀的構建工具能夠分析出哪些地方需要做相應的修改，並將這個分析過程本身做為整個構建過程的一部分。通常的做法是檢查原始碼和目標檔案的修改日期，只有當原始碼的修改日期晚於其對應的目標檔案時才執行編譯。依賴關係因此變得微妙起來了：如果一個目標檔案發生了修改，那些依賴於它的檔案也需要重新構建。有些編譯器能夠處理這種依賴關係，而有些就不見得。

　　根據自己的需要，你可以選擇不同的東西進行構建。構建中既可以包括測試，也可以不包括，甚至可以包括不同的測試板塊。有些組件可以進行單獨構建。構建指令碼應該能夠允許你針對不同的情形進行不同的構建目標。

　　我們大多數都使用IDE，而多數IDE都或多或少地整合了構建管理功能。但是這樣構建檔案通常是特定於IDE的，而且非常脆弱。此外，它們需要依賴於IDE才能工作。雖然對於開發人員個人來說，在IDE中做這樣的構建配置並無不妥，但對於持續整合伺服器來說，一份能夠被其它指令碼調用的主構建指令碼卻是至關重要的。比如一個Java項目，各個開發人員可以在自己的IDE中進行構建，但應該還有一個Ant主構建指令碼來保證構建能在整合服務器上順利完成。

1. 使構建自測試

　　傳統意義上的構建包括只編譯，連結等過程。此時程式也許能運行起來，但這並不意味著系統就能正確地運行。雖然現在的靜態語言已經能夠捕捉到許多bug，但是漏網之魚卻更多。

　　一種快速並高效發現bug的方法是將自動化測試包含到構建過程中。當然，測試也不見得完美，但的確能發現很多bug——足夠多了。特別是隨著極限編程（XP）的升溫，測試驅動開發（TDD）也使自測試代碼流行起來，越來越多的人開始注意到這種技術的價值所在。

　　經常讀我著作的讀者可能知道我是一個TDD和XP的大粉絲，然而我想強調的是這兩種方法和自測試並沒有必然聯絡。TDD和XP都要求先寫測試代碼，再寫功能代碼使測試通過。在這種模式下，測試既用於發現bug，又用於完成系統設計。這是非常好的，但對於持續整合來說不必如此，因為此時我們自測試代碼的要求並不那麼高。（然而TDD是我寫自測試代碼的首選。）

　　對於自測試代碼而言，你需要一組自動化測試來檢測一大部分程式碼程式庫中的bug。測試能通過一個簡單得命令來運行並且具備自檢功能。測試的結果應該能指出哪些測試是失敗的。對於自測試的構建來說，測試失敗應導致構建失敗。

　　過去這些年裡，TDD使開源的XUnit家族流行起來，成為了理想的測試載入器。在ThoughtWorks，XUnit已經是非常有用的測試載入器，我也經常建議人們使用。這組工具起初由Kent Beck開發，它們使自測試環境的搭建變得非常簡單。

　　XUnit當之無愧地是你進行代碼自測試的起點。當然，你也應當多看看那些更側向於端到端測試的工具，包括FIT，Selenium，Sahi，Watir，FITnesse等等，我就不逐一列舉了。

　　當然，別指望測試就是萬能的。常言道，測試並不代表就沒有bug。

1. 每人每天都向主線提交代碼

　　整合首先在於交流，它使其他成員能夠看到你所做的修改。在這種頻繁的交流下，大家都能很快地知道開發過程中所做的修改。

　　在向主線提交代碼之前，開發人員必須保證本地構建成功。這當然也包括使測試全部通過。另外，在提交之前需要更新本地代碼以匹配主線代碼，然後在本地解決主線代碼與本地代碼之間的衝突，再在本地進行構建。如果構建成功，便可以向主線提交代碼了。

　　在這種頻繁提交下，開發人員可以快速地發現自己代碼與他人代碼之間的衝突。快速解決問題的關鍵在於快速地發現問題。幾個小時的提交間隔使得代碼衝突也可以在幾個小時內發現，此時大家的修改都不多，衝突也不大，因此解決衝突也很簡單。對於好幾周都發現不了的衝突，通常是很難解決的。

　　在更新本地程式碼程式庫時就進行構建，這意味著我們既可以發現文本上的衝突，又可以發現編譯衝突。既然構建是自測試的，那麼運行時的衝突也可以被檢測出來，而這樣的衝突往往是一些特別煩人的bug。由於提交間隔只有短短的幾個小時，bug便沒多少藏身之處了。再者，因為每次提交的修改都不多，你可以使用diff-debugging來幫你找出這些bug。

　　我的基本原則是：每個開發人員每天都應當向程式碼程式庫進行提交。在實踐中，越是頻繁提交，可能導致衝突的地方就越少，因而也越容易發現。

　　頻繁提交鼓勵開發人員以幾個小時為單位來分割他們的代碼，這樣便於跟蹤進度。通常，人們一開始認為在短短的幾個小時內做不了什麼事情，但我們發現找個導師和多實踐可以協助他們學習。

1. 每次提交都應在整合機上進行構建

　　有了每日提交，也就又了每日測試，這應該表明主線處於健康狀態。但是在實踐中，的確有出錯的時候，原因之一在於紀律——有人並沒有在提交之前進行本地更新和構建。另外，不同開發機之間的環境不同也是一個原因。

　　因此，你應該保證在整合機上進行構建，只有當整合機上構建成功後，才表明你的任務完成了。由於提交者需要對自己的提交負責，他就得盯著主線上的構建，如果失敗，馬上修改。如果下班之前你提交的修改失敗了，那麼，對不起，請修改好了才回家。

　　我見到過兩種方式來保證主線構建的成功：一是手動構建，二是使用持續整合伺服器。

　　手動構建是最簡單的，基本上與開發人員在本地做的構建差不多——先到整合機上拉下主線的最新代碼，然後運行構建命令，在構建過程中你得盯著構建過程，如果構建成功，表明你的任務完成。（另見Jim Shore的描述。）

　　持續整合伺服器則一直監視著程式碼程式庫，一旦檢測到有提交，便自動拉下代碼到本機，然後開始構建，並將結構通知提交者。只有當提交者收到通知後——通常是以電子郵件的方式，才表明自己的任務完成。

　　在ThoughtWorks，我們是持續整合伺服器的忠實粉絲，我們領導了CruiseControl和CruiseControl.NET的初期開發，此兩者均是廣為使用的CI伺服器。從那時起，我們也開發了商業化的Cruise。在幾乎每個項目中，我們都使用了CI伺服器，並且結果是令人愉悅的。

　　不是所有人都傾向於使用CI伺服器的，Jim Shore便給出了一個很好的論述，在此論述中，他解釋了為什麼他更傾向於手動構建。我同意他的看法——CI不過是安裝一些軟體而已，所有的實踐都應當旨在有效地完成持續整合。但同樣，許多使用CI伺服器的團隊的確發現CI伺服器是很好的工具。

　　有很多團隊週期性進行構建，比如每晚構建。這和持續構建並不是一回事，而且對於持續整合來說，也是不夠的。持續整合的關鍵在於儘快地發現問題。而每晚構建意味著整個白天都發現不了bug，如此，需要很長的時間發現並清楚這些bug。

　　持續構建的重點在於，如果主線構建失敗，你應該馬上進行修改。在持續整合中，你一直是在一個穩定的程式碼程式庫基礎上進行開發。主線構建失敗並不是一件壞事，但是，如果這樣的情況經常發生，那麼就意味著開發人員對於本地更新並沒在意或者在提交之前並沒在本地構建。主線構建一旦失敗，必須馬上修正。為了避免主線構建失敗，也許你可以試試 pending head。

1. 快速構建

　　持續整合的關鍵在於快速反饋，需要長時間構建的CI是極其糟糕的。我的多數同事都認為一個小時的構建時間對於CI來說決無道理可言。我也記得曾經有團隊夢想著他們的構建能有多麼多麼的快，但有時我們不得不面對很難快速構建的情況。

　　對於多數項目來說，將構建時間維持在10鐘之內是合理的，這也是XP的方針之一，我們多數項目也達到了這個目標。這種做法是值得的，因為這樣省下的時間是為開發人員節約的。

　　如果你的構建長到了一小時，那麼想使其加速便不是那麼容易了。對於企業級應用來說，我們發現構建時間的瓶頸通常發生在測試上，特別是那些需要於外部互動的測試——比如資料庫。

　　可能最好的解決辦法是引入階段性構建（也叫構建管道或者部署管道），因為構建事實上是分階段性的。代碼提交後首先觸發的是構建稱為提交構建，提交構建應該快速完成，而棘手的是怎麼保持速度與尋找bug之間的平衡。

　　提交構建成功後，其他人便可自信的工作了。但是，你可能還有其它跑得比較慢的測試需要寫，這時可以用額外的機器來專門跑這些耗時的測試。

　　一個簡單的例子是將構建分為兩個階段，第一個階段完成編譯，並且跑那些不需要外部互動的單元測試，資料庫互動也通過stub的方式完全消除掉。這些測試可以很快跑完，原則是將其保持在10分鐘之內。但是，對於那些需要大量外部互動——特別是涉及到真實資料庫互動時才能發現的bug，這個階段便無能為力了。第二個階段跑的測試則需要操作真實的資料庫了，同時還應包括端到端測試。這個階段可能需要幾個小時。

　　在這種情況下，通常將第一階段視為提交構建，並將此做為主要的CI周期。第二階段則可在有必要時才進行，如果這個階段構建失敗，它也不需要像第一階段那樣“停下全部手頭的工作”，但也應該得到儘快的修改。第二階段的構建不見得需要保持一直通過，對於已經發現的bug來說，可以在之後幾天修改。對於這個案例來說，第二階段全是測試，因為通常情況下最慢的即是測試。

　　如果第二階段構建發現了bug，通常意味著應該在第一階段中引入新的測試來予以保證。

　　當然，以上的兩階段構建只是一個例子，你完全可以加入多個構建階段。提交構建之後的其它構建是可以並行完成的，如果這些階段的構建需要好幾個小時，那麼可以用幾台機器來並行完成。通過這種並行化，你可以將提交構建之外的所有測試都引入到構建過程中來，比如效能測試。

1. 在與生產環境的拷貝環境中運行測試

　　測試旨在發現可能在生產環境中出現的問題，因此如果你的測試環境與生產環境不同，那麼測試很有可能發現不了生產環境中的bug。

　　因此，你的測試環境應該盡量與產生環境相同。使用相同的資料庫，相同的作業系統，並且版本都應該一樣。另外，將生產環境中的庫檔案也放到測試環境中，即使構建時用不到這些庫。IP地址和連接埠號碼也應當相同，當然還包括硬體。

　　但事實上這是有限制的。如果你開發的是案頭軟體，很難預測你的客戶在使用哪些第三方庫。再者，生產環境可能非常昂貴。即便存在這麼多限制，你依然應當盡量去複製生產環境，並熟知因測試環境和生產環境的不同而可能導致的風險。

　　如果你搭建的環境足夠簡單並沒有多少煩人的外部互動，那麼你的提交構建便可在模擬環境中進行。但是，由於系統反應慢等原因，你可能需要test doubles。因此，通常情況是在人工環境下跑提交構建以擷取速度，而用一個生產環境的拷貝環境來跑其它測試。

　　我注意到，虛擬化技術越來越引起人們的興趣。由於虛擬機器可以儲存構建所需的所有東西，故在虛擬機器中運行構建和測試相對比較容易。另外，虛擬機器技術也允許你在一台機器上運行多個測試，或者可以類比多台機器同時訪問網路的情況。隨著虛擬機器效能逐漸提升，它將引起更多的注意。

1. 使任何人都能輕易獲得可執行檔

　　軟體開發最困能的事情之一便是你不能保證所開發的是正確的軟體。我們發現人們往往很難預知自己究竟想要什麼，而相反，對已有的東西進行評判和修改卻容易的多。敏捷開發過程則恰恰是符合人類這種行為習慣的。

　　為此，項目中的所有成員都應能夠獲得最新的可執行檔並能成功的運行，目的可以包括做示範，瀏覽測試或者僅僅看看項目本周有何修改。

　　這是很容易達到的：確保一個通用的地方來存放最新可執行檔。在同一個地方存放多個可執行檔也是很有用的。對於最新的可執行檔，應當保證能夠通過提交測試。

　　如果你的開發過程有一個很好的反覆項目計劃，將每次迭代最後一次構建產生的可執行檔存放起來也是明智的做法。

1. 人人都能看到正在發生什麼

　　持續整合主要在於交流，因此應當保證每人都能輕易看到當前系統的狀態和已做的修改。

　　主線的構建狀態是非常重要的，Cruise伺服器包含一個網站，你可以在該網站上看到當前的構建狀態和最後一次主線構建的結果，許多團隊喜歡用比較顯眼的標識來反應構建狀態，比如在螢幕上放一盞燈，燈綠表示構建成功，燈紅表示失敗。尤其常見的是lava lamps——不僅表明構建狀態，還可顯示構建時間。如果紅燈中有了氣泡，則表明構建已經失敗了很長一段時間了。每個團隊都有自己的選擇，當然，適合自己的才是最好的。

　　對於手工完成的持續整合過程，這種可見度也是很重要的，構建機器的顯示器應該能顯示主線構建的狀態。通常，正在做整合的人會放一個token在桌上來表明他正在做整合。人們喜歡在構建成功後播放一些簡單的聲音，比如鬧鈴之類的。

　　當然，CI伺服器的網站可以展示更多的資訊。Cruise不但能可以顯示是誰在構建，並且能顯示最新提交的修改。另外，Cruise還可以查看提交曆史，這樣，團隊成員便可以很清楚項目的進展情況。據我所知，有些團隊的頭便是通過這種方式來瞭解項目成員的工作情況和整個系統的修改情況。

　　使用CI網站的另一個好處是，哪怕不在一起工作的人都可以看到當前項目的狀態。再者，你也可以將不同項目的構建資訊放到一起。

　　並不是只有CI網站才能展示顯示構建資訊。由於構建的不穩定性是一直存在的，這時我們可以將全年的日曆畫在一張牆上，每天對應一個方塊，如果構建成功，QA則在該天的方塊貼上綠色標籤，否則貼上紅色標籤。時間一久，這份日曆便可顯示出項目的穩定性進展情況。

1. 自動化部署

　　做持續整合需要多種環境，不同的構建階段需要不同的環境。每天，項目的可執行檔都會在這些環境之間搬來移去，於是你希望將這些過程自動化。因此，自動化部署指令碼便很重要了，不僅包括測試環境的指令碼，也包括針對生產環境的部署指令碼。雖然我們不是每天都向生產環境部署，但自動化部署不僅可以加速部署過程，並且能夠減少部署錯誤。

　　如果你已經有了生產環境的自動化部署，那麼也應該考慮一下相應的自動化復原。由於失敗是時而會發生的事情，在這種情況下，我們希望能快速復原到失敗之前的狀態。這樣一來，我們在部署是也不用那麼畏首畏尾了，於是我們可以頻繁的發布軟體，使用者亦能儘快的享受到新的功能。（Ruby on Rails社區有一款名為Capistrano的工具即是一個典型的例子。）

　　在叢集環境中，我看到有每次只向一個節點部署的情況，由此在幾個小時之內逐漸完成所有節點的部署。

　　對於一些面向福士的web應用，我所瞭解的另外一種很有趣的部署方式是，先實驗性針對一部分使用者進行部署，再通過這些使用者的試用情況來決定是否向所有使用者部署。自動化部署，做為CI的一項原則，能夠很好的勝任這些工作。

持續整合的痛點

持續整合有那麼多好處，實踐起來的思路也很清晰，那麼為啥還有那麼多的團隊做得不夠好呢？做好持續整合有很多痛點，下面將會分析一下。

1. 很多維護期的產品分散於很多程式碼程式庫或者很多分支，難以統一維護
   這種情況尤其會出現在那些已經存活多年，卻依然為公司帶來利潤的軟體產品上。另外一種情況就是，公司收購來的軟體產品，因為曆史原因，也很難整合到一起。
2. 自動化測試
   這是最難的。實話實說，我們可以扭過頭看看周邊的團隊，自動化測試的程度到底如何。我覺得80%以上的項目在這一點上都做得不好。之所以很難做好自動化測試，A）有軟體產品自身架構組織的原因。比如軟體架構耦合度很高或者過於分散，難以自動化測試。 B）也有軟體產品形態的原因。比如如果軟體產品主要提供的是介面或者明確的服務，那麼則比較容易自動化；如果產品主要是web介面，這自動化測試起來相對比較難。C）還有一個很重要的原因就是自動化測試的維護成本。自動化測試案例不是一蹴而就的。在寫業務代碼的同時，還要完成相應的測試案例。這是需要成本的。團隊是否有精力和時間去做這件事？一開始也許還好說，一旦業務壓力上來，就會發現很多測試案例過不去，最後也就不了了之。

3. 快速構建
   構建是需要花費時間和成本的。有硬體上的因素，也有語言上的因素，還有軟體架構的因素。

   • 我們願意花多少錢去買機器做這件事？當有的公司早已經用頂配垃圾桶編譯自己的APP了，還有的公司用那種不是SSD的mac mini 硬撐。這就是差距。
   • 有些系統是php，ruby，python等解釋型語言的，有的僅僅需要壓縮、混淆打包一下就可以上線了，這速度當然快；但是還有很多系統用的是C／C＋＋，golang等，這就相對比較耗時。這是語言上的因素。
   • 軟體架構。這對構建時間影響也很大。比如一個大的C＋＋系統，如果模組相對比較獨立，互相依賴少，則完全可以把整個產品劃分成很多個小的模組，進行並行編譯。那麼最終整體的時間就由耗時最長的那個模組決定了。一下子就可以把整體構建時間降下來。
   • 有很多的並行分布式構建系統是收費的，這就涉及到一個許可證購買到問題。

4. 很多環境難以類比
   雖然現在有些公司的產品就是一個網站，一個app；但是不得不說還有很多銀行的大型系統存在著。這些公司的線上系統就一套，很難找到一個預上線環境，很多都是寫好了，直接線上測試。出錯很難避免。

雖然我們現在可以使用更好更強的CPU，更大的記憶體，更快的儲存（如SSD），並行構建、分布式構建去加速我們的構建過程，這些都是顯性的看得到的成本；而要花很多時間去做的自動化測試，則要花費很多的人力成本在上面；而對於有些特殊行業，有的時候是很難找到一個預生產環境的，這就很尷尬了。

小結

剛開始做持續整合容易，真的做好還是需要下一番功夫的。

縮寫解釋：

• EE : Electrical Engineering,電子工程 俗稱EE或Double E
• CS : Computer Science, 電腦科學
• SWE : Software Engineering, 軟體工程

參考資料：

• Code Complete ([美國] 史蒂夫·邁克康奈爾)
• Continuous Integration ([美國] Martin Fowler)
• 持續整合 ([中國] Jack Zhou譯)