前言

引言

昨天，老板讓你給客戶演示一下產品很好的新特性，但你卻什么都演示不了。所有新功能都只開發了一半，沒人能讓這個系統運行起來。你能拿到代碼，可以編譯，所有的單元測試在持續集成服務器上都能跑過，但是還要花幾天才能把這個新版本發布到對外公開的UAT環境中。這種臨時安排的商務演示活動算不上不合理吧？

在生產環境中發現了一個嚴重缺陷，它每天都在讓你的公司蒙受損失。你也知道怎么修復它：只要在這個三層架構的系統中，修改那個被這三層都用到的庫上的一行代碼，然后再修改一下數據庫中對應的表即可。但是，上次發布新版本到生產環境時，你花掉了整個周末的時間，而且直到凌晨三點才完活兒。另外，上次執行部署的那個家伙在不久之后因厭倦這樣的工作辭職了。你清楚地知道，下次發布肯定不是一個周末就能搞定的。也就是說，該系統在工作日也會停機一段時間。唉，要是業務人員也能理解我們的問題就好了。

雖然這些事都很常見，但這些問題并不是軟件開發過程不可避免的產物，它們只是在暗示我們：某個地方做錯了。軟件發布應該是一個快速且可重復的過程。現在，很多公司都會在一天內發布很多次。甚至對于那些代碼非常復雜的代碼庫來說，這樣做也是可能的。我們在本書中就會告訴你如何做到這一點。

Poppendieck夫婦（Mary和Tom）問道：“在你的公司里，僅涉及一行代碼的改動需要花多長時間才能部署上線？你的處理方式是否可重復且可靠呢？”從“決定做某種修改”到“該修改結果正式上線”的這段時間稱為周期時間（cycle time）。對任何項目而言，它都是一個極為重要的度量標準。

在很多組織中，周期時間的度量單位是周或者月，而且發布過程也是不可重復或不可靠的。部署常常是手工操作過程，甚至將軟件部署到測試環境或試運行環境都需要一個團隊來完成，更不用說部署到生產環境了。我們遇到過同樣復雜的項目，它們曾經也是這種狀態，但是經過深入的業務流程重組后，對于某一關鍵的修改，團隊做到了小時級別甚至分鐘級別的發布。之所以能做到，就是因為我們創建了一個完全自動化、可重復且可靠的過程，讓變更順利地經過構建、部署、測試和發布過程。在這里，自動化是關鍵，它讓開發人員、測試人員和運營人員能夠通過一鍵式操作完成軟件創建和部署過程中的所有常見任務。

本書將講述如何縮短從想法到商業價值實現的時間，并使之更安全，從而徹底改變軟件交付方式。

軟件交到用戶手上之后才會為個人或公司帶來收入。這是顯而易見的事，但在大多數組織中，將軟件發布到生產環境的過程是一種手工密集型的、易出錯且高風險的過程。雖然幾個月的周期時間很常見，但很多公司的情況會更糟糕：發布周期會超過一年。對于大公司，從一個想法到用代碼實現它的時間每延遲一周就意味著多出數百萬美元的機會成本，而且這些大公司每次發布所經歷的時間往往也是最長的。

盡管如此，現代大多數的軟件開發項目仍舊沒有把低風險軟件交付的機制和過程作為其組成部分。

我們的目標是改變軟件交付方式，將其由開發人員的手工操作變成一種可靠、可預期、可視化的過程并在很大程度上實現了自動化的流程，而且它要具備易于理解與風險可量化的特點。使用本書所描述的方法，就有可能在幾分鐘或幾個小時內把一個想法變成可交付到生產環境中的工作代碼，而且同時還能提高交付軟件的質量。

交付成功軟件的成本絕大部分都是在首次發布后產生的。這些成本包括技術支持、維護、增加新功能和修復缺陷的成本。通過迭代方式交付的軟件更是如此，因為首次發布只會包含能給用戶提供價值的最小功能集合。因此本書的書名《持續交付》就來源于敏捷宣言的第一原則：“我們的首要任務是盡早持續交付有價值的軟件并讓客戶滿意。”[bibNp0]這也反映了這樣一個現實：對于成功的軟件，首次發布只是交付過程的開始。

書中描述的所有技術都與交付軟件新版本給客戶相關，旨在減少時間和降低風險。這些技術的核心是增加反饋，改進負責交付的開發、測試和運維人員之間的協作。這些技術能確保當需要修改應用程序（也許是修復缺陷，也許是開發新功能）時，從修改代碼到正式部署上線之間的時間盡可能短，盡早發現缺陷以便快速修復，并更好地了解與本次修改相關的風險。

讀者對象及本書內容

本書的一個主要目標是改善負責軟件交付的相關人員之間的協作，尤其是開發人員、測試人員、系統和數據庫管理員以及經理。

本書內容廣泛，包括經常提到的配置管理、源代碼控制、發布計劃、審計、符合性和集成，以及構建、測試和部署流程的自動化。我們也會講述自動化驗收測試、依賴管理、數據庫遷移，以及測試和生產環境的創建與管理等技術。

參與過軟件開發的很多人認為與寫代碼相比，這些活動不那么重要。然而，根據我們的經驗，它們會消耗大量的時間和精力，而且是成功交付軟件的關鍵因素。當與這些活動相關的風險管理沒有做到位時，它們就可能耗費很多資金，甚至經常會超過構建軟件本身的成本。本書會告訴你如何了解這些風險，而且更重要的是，會教會你如何降低這些風險。

這個目標很大，我們當然無法在一本書中面面俱到。事實上，我們很有可能會疏遠各類目標受眾，比如由于沒有深入討論架構、行為驅動的開發和重構等問題而疏遠開發人員，或由于沒花足夠多的篇幅討論探索性測試和測試管理策略而疏遠測試人員，或由于沒有特別關注容量計劃、數據庫遷移和生產環境監控等問題而疏遠運維人員。

然而，市面上已經有一些分別詳細討論這些內容的書了。我們認為，真正缺少的是一本討論如何把各方面（包括配置管理、自動化測試、持續集成和部署、數據管理、環境管理以及發布管理）融合在一起的書。精益軟件開發運動告訴我們很多事情，其中有一件就是“整體優化是非常重要的”。為了做到整體優化，用一種整體方法將交付過程中各個方面以及參與該過程的所有人聯系在一起是非常必要的。只有當能夠控制每一次從引入變更到發布的整個過程時，你才能開始優化和改進軟件交付的速度和質量。

我們的目標是提供一個整體方案，并給出這個方案涉及的各種原則。我們會告訴你如何在自己的項目中使用這些實踐。我們認為不會有一種一刀切的解決方案可以應對軟件開發中的各個方面，更不用說像配置管理和企業系統的運維控制這么大的主題了。然而本書所述的基本內容是可以廣泛應用于各種軟件項目的，包括大的、小的、高技術要求或短平快的快速收益項目。

在開始實際應用這些原則時你會發現，針對特定場景還需要關于這些方面的更詳細信息。本書最后列有一份參考書目，以及一些在線資源鏈接，你可以在其中找到關于本書中各主題的更詳細信息。

本書由三部分組成。第一部分闡述了持續交付背后的一些原則，以及支持這些原則所需的實踐。第二部分是本書的核心——我們稱為部署流水線（deployment pipeline）的一種模式。第三部分更詳細地介紹了支持部署流水線的生態系統，包括：讓增量開發成為可能的技術；高級版本控制模式；基礎設施、環境和數據的管理；治理（governance）。

其中很多技術看上去只適用于大型軟件應用。盡管我們的經驗多數來自于大型軟件應用，但相信即便是極小的項目也可以從這些技術中受益，理由很簡單，項目會變大的。當小項目開始時，你的決定會對其發展產生不可避免的影響，以正確的方式開始，你會使自己或者后繼者在前進的路上減少很多痛苦。

本書作者都認同精益和迭代軟件開發理論，即我們的目標是向客戶快速并迭代地交付有價值且可工作的軟件，并持續不斷地從交付流程中消除浪費。我們描述的很多原則與技術最早都是在大型敏捷軟件項目中總結出來的。然而，本書中提到的技術都是通用的。我們的關注點更多的是通過更好的可視化和更快的反饋改善協作。這在每個項目中都會產生積極影響，無論項目是否使用迭代開發過程。

我們盡量做到每一章（甚至每一節）都相對獨立，可以分開閱讀。至少，我們希望你想了解的內容以及相關的進一步的參考信息是清晰且容易找到的，以便你可以把這本書當做一本工具書來用。

還要說明的一點是，我們并不追求所討論主題的學術性。市面上與之相關的理論書籍非常豐富，其中很多都非常有趣，也不乏深刻的見解。尤其是，我們不會花太多時間在標準上，而是會關注那些對軟件開發中的每個角色都很有用且經過實戰檢驗的技能和技術，并盡量言簡意賅地闡明它們，使其在現實中每天都能發揮作用。在適當之處，我們還會提供一些案例，以方便闡述這些技術。

內容簡介

我們知道，并不是每個人都想從頭到尾讀完這本書。所以本書采用了特別的編寫方式，使你一旦看過了介紹，就可以從不同的地方開始閱讀它。為此，書中會有一定量的重復內容，但是希望不至于讓逐頁閱讀的讀者感到啰嗦。

本書包括三部分。第一部分從第1章到第4章，講述有規律、可重復、低風險發布的基本原則和與其相關的實踐。第二部分從第5章到第10章，講述部署流水線。從第11章開始，我們會深入分析支撐持續交付的生態系統。

建議第1章必讀。我們相信，那些剛接觸軟件開發流程的人，甚至是有經驗的開發人員，都會從中發現很多挑戰其對專業軟件開發原有觀點的內容。對于本書的其他部分，你可以在閑暇時翻看，或者在遇到問題時查看。

第一部分——基礎篇

第一部分描述了理解部署流水線的前提條件。每章的內容都建立在上一章的基礎之上。

第1章首先描述了在很多軟件開發團隊中常見的反模式，然后闡述了我們的目標以及實現方式。最后總結了軟件交付的一些原則，本書的其他內容都以這些原則為基礎。

第2章闡述了管理構建、部署、測試和發布應用程序所需的一些要素，包括源代碼、構建腳本，以及環境和應用程序配置。

第3章講述了在程序每個變更后執行構建和運行自動化測試相關的實踐，以便確保你的軟件一直處于可工作狀態。

第4章介紹了每個項目中的各種手工和自動化測試，并討論了如何確定適合自己項目的策略。

第二部分——部署流水線

本書的第二部分詳細介紹了部署流水線，包括如何實現部署流水線中的各種階段。

第5章介紹了一種模式，即本書的核心——每次代碼修改后從提交到發布的一個自動化過程。我們也討論了如何在團隊級別和組織級別實現流水線。

第6章討論了用于創建自動化構建和部署流程的腳本化技術，以及使用這些腳本的最佳實踐。

第7章討論了部署流水線中的第一個階段，即任何一次提交都應該觸發的自動化過程。我們還討論了如何創建一個快速、高效的提交測試套件。

第8章展現了從分析一直到實現的自動化驗收測試。我們討論了為什么對于持續交付來說驗收測試非常關鍵，以及如何創建一個成本合理的高效驗收測試套件，來保護應用程序中那些有價值的功能。

第9章討論了非功能需求，并重點介紹了容量測試，內容包括如何創建容量測試，以及如何準備容量測試環境。

第10章講述自動化測試之后應做什么：一鍵式將候選發布版本部署到手工測試環境、用戶驗收測試環境、試運行環境，直至最終發布。其中包括一些至關重要的主題，如持續部署、回滾以及零停機發布。

第三部分——交付生態圈

本書的最后一部分討論了用于支撐部署流水線的各類交叉實踐與技術。

第11章的內容包括環境的自動化創建、管理和監控，包括虛擬化技術和云計算的使用。

第12章討論了在應用程序的生命周期中，如何創建和遷移測試數據和生產數據。

第13章首先討論了如何在不使用分支的情況下讓應用程序一直處于可發布狀態。然后描述了如何將應用程序分解成多個組件，以及如何建立和測試這些組件。

第14章概述了最流行的一些工具，以及使用版本控制的不同模式。

第15章的內容是風險管理和符合度，并提出了配置和發布管理的一個成熟度模型。然后，我們討論了持續交付帶來的商業價值，和迭代增量交付項目的生命周期。

本書中的在線鏈接

由于外部網站的完整鏈接很長，所以我們用了短鏈接，其格式如 [bibNp0]。有兩種方法打開這個鏈接，可以使用bit.ly（其URL是http://bit.ly/bibNp0），也可以使用我們安裝在http://continuousdelivery.com/go/上的一個短鏈接服務（Key值是一樣的，所以上例中的URL是http://continuousdelivery.com/go/bibNp0），如果bit.ly因為某種原因停止了服務，你還可以用這個鏈接。如果網頁更換了地址，我們會盡量保留http://continuousdelivery. com/go/這個短鏈接服務，所以如果bit.ly不可用，可以試一試這個。

關于封面的插圖

Martin Fowler簽名系列的所有書中，其封面都以“橋”為主題。我們原打算使用“英國大鐵橋”的照片，但是它已經用在了本系列的另一本書上。所以，我們選擇了英國的另一座大橋“福斯鐵路橋”，這張美麗的照片由Stewart Hardy拍攝而成。

福斯鐵路橋是英國第一座使用鋼鐵建造的大橋。其鋼鐵使用最新的西門子-馬丁平爐工藝制造，并由在蘇格蘭的兩個鋼鐵廠和威爾士的一個鋼鐵廠交付。鋼鐵是以管狀桁架的形式運送的，這是英國首次使用大規模生產的零部件組裝橋梁。與早期的橋梁不同，設計師John Fowler爵士，Benjamin Baker爵士和Allan Stewart計算了建筑壓發生率，以便減少后續的維護成本，并計算了風壓和溫度對結構的影響，而這很像軟件開發中的功能需求和非功能需求。他們還監督了橋梁建設，以確保這些要求都能得到滿足。

當時有4600名工人參與建造該橋，其中不幸死亡約一百人，致殘數百人。然而它仍是工業革命的一個奇跡，因為1890年建成時，它是世界上最長的橋，而到了21世紀初，它仍是世界第二長的懸臂大橋。就像長生命周期的軟件項目一樣，這座橋需要持續維護。這已在設計時考慮到了，大橋配套工程中不但有一個維護車間和場地，而且在Dalmeny車站還有一個50個房間的鐵路“聚居點”。據估計，該橋的使用壽命還有一百多年。

版本記錄

本書直接利用DocBook寫完。David使用了TextMate編輯器，而Jez使用了Aquamacs Emacs。圖形是用OmniGraffle畫的。David和Jez通常身居地球的不同地方，他們之間的協作是通過Subversion完成的。我們還使用了持續集成技術，工具是CruiseControl.rb，每次有人提交一個更改后，它就會運行dblatex產生本書的PDF。

本書印刷前一個月，Dmitry Kirsanov和Alina Kirsanova開始排版制作，與作者的合作都通過Subversion庫、電子郵件和共享的Google Docs表進行協調。Dmitry用XEmacs做DocBook源文件的修編，Alina則完成了其他事情，包括使用定制的XSLT樣式表和一個XSL-FO格式化工具進行頁面排版，從源文件中的索引標簽里編譯并編輯索引，并做了本書的最終校訂。