首先簡單對這本書做個介紹。《持續傳遞》是持續傳遞這個概念開始廣為人知的一步著作，被譽為是2010年最重要的技術書。作者是Jez Humble 和 David Farlery，兩人都曾擔任過ThoughtWorks 的技術顧問和咨詢師，靈活開發技術的先行者。中文譯者橋梁也曾任職ThoughtWorks的咨詢師，在靈活開發方面具有豐富的經驗，後來，他自己又寫了一本《持續傳遞2.0》 。持續傳遞這本書，以怎麼樣實作建構流水線為核心，串聯了很多的行業最佳實踐，它們貫穿了一個軟體實作的整個生命周期，向我們展示了一個真正的靈活應該有的樣子。
好了，讓我們一起來看書。
《持續傳遞》分為了三個部分：
第一部分是基礎篇，先全景了持續傳遞想要達成的具體的目标，和實作持續傳遞過程中的幾個重要内容，分别是：配置，持續內建，和測試。
第二部分是部署流水線，叙述了部署流水線的概念和部署流水線上的幾個重要階段應該做什麼，怎麼做的問題，分别是：建構和部署，送出，自動化驗收測試，非功能性測試，以及程式的部署。
第三部分，圍繞持續傳遞中涉及到的外圍設施使用和政策問題，給出了相應的最佳實踐。他們分别是:基礎設施和環境管理，資料管理，元件和依賴管理，以及版本控制。
差異
持續傳遞帶給我的震撼，首先是持續傳遞的效率。在持續傳遞第一章，就談到軟體的釋出問題，通過分析集中常見的軟體的釋出的反模式，和持續傳遞的式做對比，展現出兩種方式之間效率上的巨大差異
反模式下，每次釋出都是一次祈禱，似乎充斥着運氣的成分，經常通宵達旦，筋疲力盡。
持續傳遞，自動化的釋出模式下，所有的工作隻是需要點一下滑鼠這麼簡單，釋出幾乎是再幾秒間就完成，沒有人感覺到發生了一次釋出，這個不就是我們一直希望的事情麼？
當然是的，隻不過，我們想的和實際之間，缺少了太多的環節和實踐，比如測自動化測試，環境驗證等。而這些正是建構持續傳遞這個大的最佳實踐的基礎，把這些環節串聯起來，就是建構流水線。
建構流水線(Build Pipeline)
圖檔來源：極客時間《十倍程式員工作法》
《持續傳遞》對部署流水線是這樣定義的：
對軟體從版本控制到使用者手中一系列過程的自動化建構過程的模組化。在持續內建和釋出管理工具上，它展現為支援檢視并控制整個流程，包括每次變更從被送出到版本控制庫開始，直到通過各類測試和部署，再到釋出給使用者的過程 。
在建構流水線中存在多個階段
這些階段是送出階段、自動化驗收階段、自動化驗收、以及後續的各個環境的部署階段，一個階段不通過，不允許進入下一個階段。
這樣，通過建構流水線，把一個應用軟體從産生到釋出的所有相關人員串聯到了一起，有關産品和開發人員，有關于測試和運維人員。這個流程是一個自動化的流程，自動化不是說就不需要相關人員的參與，而在于把這些執行過程中複雜且容易出錯的環節變成了可以重複自動化的環節。從建構到釋出的整個過程，對于所有人都是可見的，這樣，釋出流程中的低效環節就會很快的回報出來。
持續傳遞的目标，是讓軟體具備随時可以部署到生産環境的能力。顯然，保證軟體傳遞的品質，是整個目标的前提。是以，持續傳遞的核心就是：自動化測試。
自動化測試
說起測試，所謂開發人員的我們很容易覺得：那不是測試應該做的事兒麼？一開始我也這麼覺得，直到接觸到TDD（測試驅動開發）後，才猛然驚醒，自己這份責任推诿了很久。
測試時一個貫穿軟體全部生命周期的一個内容，開發階段的單元測試，元件測試和部署測試，驗收極端的功能測試以及非功能測試，部署階段的部署測試都是測試的内容，作為開發，起碼應該打響代碼品質保衛戰的第一槍。
最近，我參與《重構，改善既有代碼的設計》的中文譯者熊節老師辦的一個測試驅動開發的訓練營，進行了為期一個月的測試驅動開發訓練，深刻的感受到了測試對于開發人員的深刻意義。
首先，拿什麼來保證你的代碼是可靠的？答案就是：測試。Micheal Feathers 在《修改代碼的藝術》一書中有句被很多書引用過的名言：遺留代碼就是沒有測試的代碼。這句話把測試對于一個軟體系統的品質保障作用的重要性提高到了一個前所未有的高度，每次讓人聽到都心頭為之一震，原來自己的代碼從一開始就已經出現了腐化。（末尾我添加了該書的PDF 附件，現在該書已經停版）
測試的作用有兩個：一方面，建構代碼品質的安全網，讓開發人員可以放心的對代碼進行重構，另一方面，就是快速回報，可以快速暴露缺陷，有限提高開發人員的開發效率，保證代碼的品質。《持續傳遞》 中提到：“修複那些在送出階段發現的問題，要比修複那些由後續運作大量測試的階段發現的問題簡單得多。”
關于測試還有一個常談的話題：沒時間寫測試。甚至還有人在知乎上提出過代碼品質守恒定律這種無稽之談。用這種理由拒絕寫測試後，我們看到的是另一種怪現象：改bug就像是打地鼠，永遠沒有結束，直到開發人員崩潰。
測試會強制開發人員寫出可以測試的代碼，TDD 的節奏：紅-綠-重構，保證代碼随時可以通過測試和保證高品質的代碼。還有就是在動手寫測試之前，必須對開發的所有任務有一個清晰的分解清單，這樣，對開發節奏和開發品質，都有一個全局性的指導作用。從整個角度來說：測試代碼就是一個可以運作的需求文檔，隻要有不符合需求的地方，立馬可以給出回報。
關于驗收測試和非功能性測試，涉及到測試人員，今天不多提及。
版本控制
版本控制在《持續傳遞》中也占據了相當大的篇幅，甚至部署環境也被納入了版本控制的範圍。版本控制是持續傳遞的基石，幾乎所有開發相關的資源都被納入了版本控制，包括源代碼，測試代碼，文檔，配置資訊等等。
其他的不多說，對于版本控制，《持續傳遞》 反複提到一個理念就是：頻繁提高代碼到主幹，保證主幹代碼上的代碼随時都是可以釋出的代碼，注意三個關鍵詞：頻繁，随時，釋出。頻繁送出，保證主幹上的代碼随時都是最新的，這個是保證主幹代碼實時性的前提；随時可以釋出，保證代碼随時都是可以通過測試的代碼，這樣，測試的又被放到的眼前，是以，可以測試的代碼，是保證代碼品質的前提。
由頻繁送出，延伸到另一個分支使用政策：使用主幹進行開發，這個是行業内的最佳實踐，使用主幹開發的前提就要求必須能頻繁的送出代碼，這樣，代碼每次拉取的代碼差異就會小的多，很容易随時進行內建，避免項目後期的“合并地獄”。當然，如果你要說代碼品質風格，品質啥的，這都是前提内容，代碼風格，品質啥的，都可以用相應的插件來檢查，比如checkStyle等，不符合代碼格式檢測，不符合測試覆寫率要求的代碼都是無法送出的。是以，主幹上的代碼一定是符合要求的，高品質的，可以運作的代碼。鄭晔老師曾說過：你多久送出一次代碼？如果你的回答超過一個上午，對不起，你的步子太大了。
使用主幹進行開發的分支政策并不是否定gitFlow 或者pull Request 這種分支政策的使用，關鍵在于什麼時候使用分支。根據書中提建議：盡量避免使用分支政策。除非為了釋出或技術調研建立分支，以及在極困難的情況下沒有更合适的方式通過别的方法對應用程式做進一步的修改時才建立分支。如果建立了分支，也要保證這個分支的生命周期不會太長，很快就會切回主分支。
下圖是書中的一個插圖：可以想一下這種分支政策下，合并會是何等苦難的一件事兒。
如果使用了分支，實作持續內建就成了一件不可能的事情，因為各種合并本來就是一件成本很高的事情，和持續傳遞的目标南轅北轍了。
小結
說起持續傳遞，我開始很容易聯想到另一個詞語：持續內建，也很容易想到持續內建伺服器，例如：Jenkins。實際上，在讀完《持續傳遞》之後，才明白持續傳遞的環節遠遠要比持續內建廣得多，持續內建隻是持續傳遞這個龐大的目标體系中的一部分。 持續傳遞，是一種讓軟體随時可以部署到生産環境的能力，這個是持續傳遞的目标。如果把軟體部署到生産環境的過程也全部自動化，這就上升到了持續部署的這個層面。
持續傳遞的核心是自動化測試，沒有測試，就沒有代碼品質保障和效率，沒有回報。持續傳遞，除了體系化了持續傳遞流水線中的理念和實踐外，更然我們從一個宏觀的角度來去看待兩個被說了很久的字：靈活，很多人，很多組織都在說自己用的是靈活，是不是真靈活，拉出個單子和持續傳遞中說的這些對一下基本就123很明白了。
《持續傳遞》全書一共有15個章節，每個章節都有不同的側重點，我今天挑了三個：分别是：持續傳遞流水線，版本控制，以及非常核心的：自動化測試。其他的内容，也建議大家去拜讀一下，看看好的的工作狀态是什麼樣子的，注意，我沒用理想的工作狀态來形容，因為這種狀态也是可以實作的。
作為一個開發人員，我始終覺得我們的工作不應該是實在反複加班的惡性循環中度過的，解決之道，一定有，最佳實踐給了我們很好的指導思路，重點是，要去實踐！！！要找到這個職業應該有的樂趣和成就感。
話外
前段時間，知乎上有一場讨論叫做“中華田園靈活”，有兩個回答可以跟大家分享下：
第二個回答是熊節的回答，我看了之後很服氣。确實，目前國内田園靈活盛行軟體開發生态确實有一些外部因素，如第一個回答中的這種風格的上司，但是更多的是開發人員本身，自身的基本功是否過硬，自己的工作效率是否合格的，工作是否是有效的。
我們目前所處的時代，從來不缺乏各種資料，更不缺乏最佳各種最佳實踐，隻要想找，就會發現最佳實踐這個東西基本是公認的，比如測試驅動開發，這個行業最佳實踐，從kent back的《測試驅動開發》 ，到Martin Fowler《重構,改善既有代碼的設計》，到今天的《持續傳遞》以及耳熟能詳的《整潔代碼之道》，以及文中提及的《修改代碼的藝術》 ，它都是最重要的内容之一。
有很多的最佳實踐其實誕生已經很多年了，很多的人隻是聽說過（比如我），但是并未深入的一探究竟，是的，我們都太懶了，懶得思考，懶得學習，習慣于目前已成模式的工作方式。鄭晔大佬曾說過：這些最佳實踐其實做起來也沒那麼難，就像是一個開關，撥過去就好了。但是前提是你得動手去撥。