持續交付2.0：業務引領的DevOps精要（增訂本）

持續交付2.0=精益創業+持續交付1.0=價值探索+快速驗證 在書中，不僅可以收穫 2.0 雙環模型、實施原則、案例分享，也有諸如「某姓網無法合併的分支」之類的“鬼故事”，還有「別走得太快，等一等靈魂」之類的哲理小故事。 全書乾貨滿滿，又不失生（ou）動（er）有（ba）趣（gua）。 推薦翻翻，讓靈魂跟上你的腳步？[旺柴]

軟件這種複雜系統，越多人蔘與協作，個體平均效率就越低。軟件工程從最初的瀑布模型發展到敏捷開發和 DevOps 解決的就是如何通過合理地管理軟件系統的複雜性以及軟件生產運營流程的複雜性來提升組織效率。持續交付以部署流水線的模式高質量低風險地快速發佈軟件價值。

面對複雜的大型軟件，會面臨如何又快又好完成持續交付的困境，幾乎是每個IT公司不可迴避的問題。作者以豐富的經驗列舉了大量案例，確實能解惑，但實踐才能出真知，一起踐行吧，共勉。

對日常工作的優化要比日常工作本身更爲重要，軟件研發要做到高效的過程管理是一個巨大的挑戰，不同人亦有不同的見解和做法：Scrum、LeSS、Kanban、SAFes、Devops等思想層出不窮，但無一模式可放之四海皆準，核心在於對現有組織文化和過程問題的分析和洞察，在思想指導下采用本地化的策略和節奏。 有幸和喬梁老師在騰訊共事兩年，並對書中模式進行深度實踐，效果和反饋均很好，個人亦受益匪淺。深感從簡單的問題開始持續改善，識別和消除過程浪費恰是核心。 入職新公司三年，現如今也到了再提研發變革的時機，故再度翻出本書精讀了兩遍。時過境遷，心境和目的，團隊和文化大相徑庭，難度更大但信心和興奮依然在。 習慣的改變是一個艱難和痛苦的過程，希望本書可以幫你克服惰性和恐懼，所有成長和收穫。

整體而言，本書有點虎頭蛇尾 前幾章能夠把精益思想與持續交付思想相結合，這是一大亮點 後面幾章（11章-13章）攤子鋪太大，面很廣但都不深入，蜻蜓點水，其中一些理念在某些行業中應用是錯誤的： 比如第11章對於軟件配置管理的描述要分場景來看待，在智能硬件領域，比如汽車，自動駕駛，手機，芯片等場景中，整個軟件系統由幾十上百個模塊組成，書中所講的“用顯式版本號相互依賴”是錯誤的做法，應該參考安卓系統對於組件的管理方式。 正確的原則：禁止系統中所有組件之間通過顯式的版本號決定依賴關係。任意兩個或者多個模塊之間是否匹配，只取決於把它們集成後“編譯通過+自動化測試通過”，而不取決於“顯示的版本號依賴關係”。這條原則非常重要，組件越多，越要這麼做，從而降低任意一個組件升級的難度 第17章“研發效能提升的必經之路”，看似治本，實則治標。 絕大部分的公司的研發效能低的源頭在於官僚機構養了太多人，而不在於自動化程度太低。爲一個龐大的官僚機構增加自動化和一致性，並不能解決研發效能低的問題，通過自動化節省的人力資源和時間會繼續消耗在“開會，覆盤，學習，鬥爭”等無意義的事情上。比如：微軟，BAT，等大公司內部，自動化和一致性肯定都是非常優秀的，但是人效卻是不高的。 正確的做法：從源頭把人員精簡到位，同時輔以自動化工具鏈建設。“控制人員精簡+不斷提升人才密度”，這些纔是根本。自動化手段只是輔助 第17章中強調加強code review，這個理念是錯誤的，任何不依賴於自動化工具的措施都無法保證落地質量。code review應該用靜態掃描工具全面代替，幾個方法： 1. 使用行業成熟的靜態掃描工具，precision和recall都堪憂。。。 2. 自研靜態掃描工具，這是最佳路徑； 3. 利用好chatgpt等AI，對企業人才要求很高，要把掃描結果做到穩定不容易

全書共包括3部分內容：第一部分會介紹“持續交付2.0”的雙環模型；第二部分主要討論使用“持續交付2.0”框架時可能遇到的問題，以及改進過程中需要遵循的原則；第三部分主要是案例分享，目的是讓讀者體會在持續改善過程中，不同企業和團隊的實施重點與解決方案的不同。下面我們一起瀏覽一下各章的具體內容。 第一部分主要講述“持續交付2.0”雙環模型（即持續交付“8”字環）和“持續交付2.0”的4個工作原則，還會介紹兩個閉環“價值探索”與“快速驗證”的執行步驟與相關原則。 第1章討論持續交付的發展必然性，並介紹“持續交付2.0雙環模型”及其4個基本原則。 第2章討論“價值探索環”（簡稱“探索環”）的4個關鍵環節，以及每個環節的指導原則與實踐方法。只有業務方能夠以“精益”方式思考，持續交付才能更顯威力，否則很可能退縮成爲持續交付1.0的單環模式，即只有“快速驗證環”。 第3章簡單闡述“快速驗證環”（簡稱“驗證環”）中各環節的主要活動，並給出各環節的工作方法。 第二部分主要闡述“持續交付2.0”的實施七巧板中，三大主要板塊的工作原則與實踐方法。這三大板塊包括組織機制、軟件架構與基礎設施。其中組織機制是一個複雜課題，本書僅討論持續交付所需的文化，以及塑造文化的四步法。組織架構、人才結構、激勵機制等內容將在本書的續篇中專題討論。基礎設施部分是產品研發過程中最基礎的工作。這部分首先討論持續交付部署流水線及其工具設計原則，然後分別介紹部署流水線的建立與優化必須關注的五大領域，也就是說，業務需求協作流程、分支與配置管理、構建與環境管理、自動化測試管理以及部署發佈與監控管理。 第4章討論持續交付能力的提升需要企業具有安全、信任與持續改善的組織文化，並介紹豐田公司和谷歌公司用過的組織文化塑造四步法。 第5章討論軟件架構對實現持續交付快速驗證能力的重要性、有利於持續交付的軟件架構特徵，以及軟件架構改造的3種模式，即“拆遷”“絞殺”和“修繕”。 第6章討論如何利用約束理論和精益思想發現流程中的瓶頸，使各角色之間的業務需求協作更加順暢，提升需求流動速度。 第7章討論快速驗證環所依賴的部署流水線的設計原則與工具鏈建設草案。 第8章討論代碼倉庫的分支方式對持續交付的重大影響，以及不同分支方式下部署流水線的建設方案，最後介紹代碼分支的數量對發佈策略的影響。 第9章回顧持續集成的歷史，並講解如何判斷團隊是否在實踐持續集成，還給出企業實施持續集成實踐的五大步驟。 第10章討論軟件發佈以前制訂自動化測試策略需要考慮的因素，還介紹持續集成對自動化測試用例的編寫與運行要求。最後介紹爲了提高自動化測試的投資回報率，團隊如何爲遺留系統編寫和增加自動化測試用例。 第11章討論軟件配置管理，它是持續交付快速驗證環的基礎。對代碼、配置、環境、數據做好配置管理，最終實現一鍵部署和一鍵測試，讓各角色在協作過程中能夠全部實現自動化服務，並且互不影響，解放人的大腦和雙手，做更有價值的事情，而讓機器做它擅長的事——不斷地重複。 第12章討論降低生產部署與發佈風險的技術與方法。 第13章討論軟件在運行時進行數據收集與分析的重要性，以及衡量數據監測環節的衡量指標，包括正確性、完整性和及時性，此外，還介紹測試活動扁平化趨勢，以及生產環境上的質量巡檢與演習。 第三部分主要是實戰案例的分析。它們分別代表不同類型的公司、不同大小的團隊以及不同的軟件產品特點。我將帶你深入案例現場，瞭解當時狀況，分析問題，並提出解決思路。 第14章介紹一個百人工程師的互聯網產品團隊歷經一年時間，如何打造快速運轉的“持續交付2.0雙環模型”，並且做到可持續運轉。 第15章介紹在無法“測試右移”的情況下，一個大項目中的小團隊如何改變團隊協作模式，從“死亡行軍”轉變爲無缺陷交付。 第16章介紹一個微服務化開發團隊如何在項目運行的過程中，通過逐步對基礎設施板塊中各模塊進行改造，提升交付質量與頻率，並推動運維人員也做出改變，真正成爲一個“DevOps團隊”。 第17章介紹提升組織效能的關鍵點和啓動時機，提供一個關於產品研發勝任力的評估框架並給出相關說明。

本書可以作爲持續交付的入門必讀工具書。 持續交付雙循環：探索環和驗證環。 探索環：4個可持續循環步驟，分別是提問、錨定、共創和精煉。 驗證環：4個可持續循環的步驟，分別是構建、運行、監測和決策。 持續交付交付七巧板：基礎設施，軟件架構，組織機制。

DevOps是一種軟件工程文化和實踐，旨在統一整合軟件開發和軟件運維。DevOps運動的主要特點是強烈倡導對構建軟件的所有環節（從集成、測試、發佈到部署和基礎架構管理）進行全面的自動化和監控。DevOps的目標是縮短開發週期，提高部署頻率和更可靠地發佈，與業務目標保持一致。

以前理解的持續交付以爲是將大的瀑布過程才拆分爲小的，藉助於cicd工具，進行交付過程，本書描述的持續交付2.0，已經不再侷限於此，在項目初期就已經對需求進行滿足要求的評估和拆分 ，測試人員已經編寫並通過了測試用例評估，開發人員在完成某一個功能點後，對該功能點進行ut和自測併成功運行自動化測試後，就可交給測試人員驗證，一旦在各個環境通過驗證，便可進行發佈，既減少了發佈風險，又提高了交付速度，使得需求得到更快的驗證和反饋，不過這種方式目前我還沒參與過，對人員素質要求，平臺工具要求和整個流程要求比較高。

這本書對於比較傳統的公司可能借鑑意義更大，對於身處科技行業早就熟練 SCRUM 的團隊來說，參考意義有限。選感興趣的章節，隨便翻閱一下即可。