Martin Fowler 的持續集成

　　持續集成是一種軟件開發實踐，在實踐中項目成員頻繁地進行集成，通常每個成員每天都會做集成工作，如此，每天整個項目將會有多次集成。每次集成后都會通過自動化構建(包括測試)來盡快發現其中的錯誤。許多團隊都發現這種方法大大地減少了集成問題并且能夠快速地開發出高內聚性的軟件。本文簡要地總結了持續集成技術及其現狀。

　　我還清楚地記得我剛加入一個大型軟件項目時的情形，那時我正在英國一個電子公司做暑期實習。我的經理(屬于QA部門)領我參觀了一個巨大并很壓抑的倉庫，里面堆滿了大塊頭的主機。經理告訴我這個項目已經開發了有些年頭，現在正在做集成，并且已經集成了好幾個月了。經理還告訴我說，沒有人真正知道完成集成工作需要多少時間。由此我學到了軟件項目的一個通?。很浖墒且粋€漫長并且無法預測的過程。

　　然而，軟件集成不必像這樣的。在ThoughtWorks的大多數項目還有世界上許多其它組織的軟件項目中，軟件集成并不是什么難事。每個開發人員離共享的工程狀態只有咫尺之遙，并且可以在幾分鐘之內將自己的代碼集成進去。任何集成錯誤都能被快速地發現并得到快速的修正。

　　這種鮮明的對比并不是源自于后者有多么昂貴或復雜的工具，而關鍵在于每人都頻繁集成這種簡單實踐，通常是每天向一個被管控的代碼庫集成。

　　當我向人們闡述這種實踐時，通常得到兩種反應：“(在我們這里)行不通”和“無關緊要”。當人們嘗試了這種實踐之后，他們發現其實做起來比說起來簡單，而且這樣的實踐對于開發“至關重要”。因此有了第三種反應：“是的，我們就是這么做的，不然該怎么活啊?”

　　“持續集成”源自于極限編程(XP)，并且是XP最初的12種實踐之一。當我以咨詢師的角色加入ThoughtWorks時，我鼓勵我的團隊使用這種技術。Matthew Foemmel將我的建議變成了實實在在的行動，由此軟件集成從少有發生并且復雜的狀態變成了一樁易事。Matthew和我將我們的經驗寫在了本文的第一版中，而本文也是我的個人網站上最受歡迎的文章之一。

　　雖然持續集成并不需要使用特別的工具來部署，但是我們發現擁有一臺持續集成服務器將大有益處，其中最著名的有開源的CruiseControl，該軟件最初由ThoughtWorks的幾個員工開發，現在由一個很大的社區維護著。后來幾款其它的持續集成服務器也相繼出現了，有開源的，也有商業化的，包括ThoughtWorks Studios的Cruise。

　　在開發中使用持續集成

　　對于我來說，解釋持續集成及其工作原理最簡單的方法便是以一個小的軟件功能的開發為例來進行演示。假設我們需要向軟件添加一點功能，至于是什么樣的功能并不重要，我們假定它很小并且可以在幾個小時內完成。

　　首先我們需要在本地機器上保留一份當前已經處于集成狀態的代碼的拷貝。我通過代碼管理系統在代碼庫的主線(mainline)上拉下(check out)一份工作代碼拷貝。

　　上一段文字主要針對使用代碼控制系統的人，對于不使用代碼控制系統的人來說便是胡言亂語了。因此，我將向后者解釋一下。代碼控制系統用于將項目所有的代碼保存在一個代碼庫(repository)中，項目當前的狀態通常被稱為主線。任何時候開發人員都可以從主線上獲得一份拷貝到本地機器，這被稱為“checking out”。本地機器上的代碼拷貝稱為“working copy”。(多數時候，實際上你是在更新(update)本地代碼到主線狀態，實踐中它們是一樣的效果。)

　　現在，為了完成軟件的功能添加，我對本地代碼進行修改，其中既包括修改產品代碼，也包括添加自動化測試。持續集成非?？粗販y試，并且在軟件代碼本身中達到了測試自動化——我將其稱為自測試代碼，通常使用流行的XUnit測試框架的一個版本。

　　當我完成了功能開發(或者在我開發過程的不同階段)，我將在本地開發機上完成自動化構建。構建過程將編譯并鏈接本地代碼，然后跑自動化測試。只有當構建和測試都沒有錯誤時，該次構建才能算是好的構建。

　　有了本地的成功構建，我便可以考慮將我修改的代碼提交到代碼庫了。但是，在我提交之前，其他開發人員可能已經向主線提交了他們的修改，所以首先我需要將他們的修改更新到我本地并且重新構建。如果他人的修改與我的修改有沖突，那么在本地編譯或者測試階段將會發生錯誤，這種情況下，我需要負責修改本地代碼直到與主線代碼保持適當同步為止。

　　當本地代碼與主線代碼同步之后，我便可以向主線提交自己的修改了，代碼庫也得以更新。

　　然而，單是提交了修改并不表示我的工作就完成了。我需要再次構建，但這次是在一臺擁有主線代碼的集成機器上進行。只有這次構建成功了才表示我的任務完成。通常會出現這樣的情況：我忘了提交本地機器上的一些東西，因此代碼庫并沒有得到適當的更新。只有我提交的修改在集成機器上成功構建之后，我的工作才算完成。這樣的集成構建可以由我手動完成，也可以由Cruise自動完成。

　　當兩個開發者的代碼有沖突時，通常會在第二個開發者更新本地代碼時捕獲到，否則，集成構建應該會失敗。在這兩種途徑中，錯誤都可以被快速地發現。在持續集成環境中，你決不應該使失敗的集成構建保留太長時間。一個好的團隊每天都應該有許多成功的構建。當然，失敗的構建也會時常發生，但需要盡快的修復。

　　這樣做的結果是，我們總會得到一個穩定并且工作正常的軟件。每個人都圍繞著一個共享并穩定的基礎代碼庫工作，絕不離基礎代碼庫太遠以至于需要很長的時間將自己的修改集成到基礎代碼庫中。如此這般，我們花在找bug上的時間減少了，因為bug在頻繁的集成中經常出現。

　　持續集成實踐

　　上文只是關于持續集成的一個概要和它在日常開發中的工作原理。讓所有這些都能很好的運作顯然不止于此?，F在，就讓我們來看看有效持續集成所需的關鍵實踐。

　　維護一個單一的代碼庫

　　軟件項目需要大量的文件協同工作來構建出最終的產品。跟蹤所有的文件需要大量的工作，尤其是在多個開發者參與的項目中。因此，我們可以并不驚奇的看到，不同的軟件開發團隊都在開發用于管理這些文件的工具——源代碼管理工具，也叫配置管理，版本控制系統，代碼庫等。這些工具是多數軟件項目不可分的組成部分。然而，令人傷心并吃驚的是，并不是所有的項目都使用了這樣的工具。我的確見到(雖然很少)不使用這些工具的項目，它們使用本地和共享磁盤這種混亂的結合來共同工作。

原文轉自：http://www.anti-gravitydesign.com