喬樑，《持續交付》中文版譯者，騰訊高階管理顧問，“輕敏捷”方法創始人，持續交付先行者，映客、卷皮、墨跡天氣等多家移動網際網路公司高階管理顧問，也為魅族、上汽、平安等不同型別的公司提供組織管理諮詢服務。

我與《持續交付》之緣

《持續交付》是我在2011年翻譯的一本書，由人民郵電出版社出版。今天給大家分享的這段主題，對我來說，也是對”持續交付之路“的一次小結：為什麼炒那麼多年的”飯“，到現在好象還沒有”炒“好？

2001年接觸敏捷

我最早接觸敏捷這個概念的時候是2001年。我看到了一本書，名叫《解析極限程式設計》，當時覺得非常的棒。因為做為軟體開發者，感覺這本書可以解決我工作中一直被困擾的難題。但也並沒有馬上使用，因為好象太難了，不太現實。有一些實踐，當時，我也不太能完全接受。

2004年引入敏捷實踐

2004年以後，作為一個產品的技術負責人，在我的團隊裡引入相關的一些敏捷實踐，但是在我們公司裡發現這個很難推行開來，覺得成本太高了，於是，我選擇做了一些折中方案，比如不做結對程式設計，但做code review。

2007年加入ThoughtWorks

但實踐結果並沒有我預期的那麼好。在2007年，我加入了 ThoughtWorks，它是當時在國內大力推廣敏捷開發方法的先行者。加入 ThoughtWorks，我就想知道他們是怎麼在他們的軟體專案中運用敏捷開發方法的。比較幸運的時，正好與《持續交付》這本書的作者 Jez Humble在同一個產品團隊，這個產品就是goCD（它最初的名字是Cruise）。他是這個產品的產品經理，我是作為業務分析師加入這個團隊，後來作為產品的delivery manager。在工作過程中，真正地理解了敏捷開發方法的精髓。

2010年《持續交付》的手稿

在開發這個產品的時候，Jez Humble就在寫這本書。我在第一時間看到了這書的手稿，覺得非常棒，就開始積極聯絡國內的出版社，看看哪個出版社能引入這本書。

2011年《持續整合》翻譯成書

當我完成這本書的翻譯，並出版時已經是2011年，那時我已經加入百度，並工作了一段時間。一會兒後面提到的第一個案例也是在百度的，在座的劉俊老師，當時就是這個案例專案的運維工程師。

2013年成為外聘顧問

2012年，我開始作為外部顧問，幫助騰訊多個團隊去做組織及研發管理上的改進。直到現在。從2007年開始，我的所有工作中都會看到“持續交付”的理念和做法。

什麼是持續交付

新興的IT詞彙？

IT行業新詞多，我們今天提到的我想解釋的可能就圖片上這麼幾個，持續整合，敏捷軟體開發，持續交付以及DevOps。最後面的這兩個詞彙是今天想要講的主題，之所以這麼說是因為我在2011年和2012年的時候，在QCon技術大會上就講過一個主題，名為“DevOps，讓持續交付成為可能”。所以，DevOps並不是什麼新鮮的東西，也沒有什麼神祕。

從場景出發理解持續交付

當我們討論這個名詞的時候必然和場景相結合，通常在一個軟體產品團隊裡，總是會談到這樣四個角色————產品、研發、測試、運維。幾乎所有的公司，都會以員工的技能將他們分成相應的四個部門，然後，自然而然就會出現部門牆。用通俗的話講，就是“屁股決定腦袋”。

那麼來看看剛才提到的那四個IT熱詞，根本想解決的問題是什麼。

• 持續整合，你會發現，這個實踐的參與方是我們的開發團隊和測試團隊，你做好了持續整合，會逐步打破開發和測試之間的牆。

• 敏捷開發，則引導往上游走了一步，讓PO（在XP方法中，叫現場客戶）捲入進來，試圖消除業務需求與產品研發之間的牆。

• DevOps，則想要解決的是運維團隊和研發團隊之間的牆。

• 持續交付，從我的理解，持續交付則是希望端到端的去解決隔離牆的問題。然而，在《持續交付》這本書裡面，大篇幅講了很多具體技術原則和技巧相關的內容，並沒有把這一點提到一個特別高的高度上，我認為這算是《持續交付》這本書的一個不足之處吧。

從理論出發理解持續交付

什麼是持續交付? 從上現這個定義來看，持續交付本身是一種能力，什麼樣的能力？以一種可持續的方式，安全快速的把你的變更，無論是features、配置管理、使用者體驗，放到你的生產環境上讓使用者使用。所以說持續交付本身定義的是一種能力，一種軟體團隊端到端的交付能力。

當很多人聽到新的概念的時候，都會有一些興奮，“又出來一個新的，正好解決了我的問題，讓我們動手幹吧！”。對它有特別大的期待。然後你就會在各大招聘網站上看到大量招聘DevOps工程師的廣告。在2013年的時候，甚至有很多公司在說：”我們要有一個部門，叫DevOps部門“。

其實這個和DevOps所倡導的恰恰相反，因為當你增加這個部門的時候，很可能實際上會再多了一堵牆，DevOps和Dev和Ops之間到底是什麼關係，平白無故為什麼又多了一堵牆呢？DevOps運動本來是要打破開發團隊和運維團隊之間的隔閡啊？

那麼，到底哪條路是正確的呢？這是仁者見仁、智者見智的事情。接下來把我做的兩個案例跟大家分享一下，我最後會總結一下我在這裡的一些思考。

案例一，在百度的持續交付案例

這是百度大廈，2010年下半年我加入百度，並在2011年指導大搜索部門的一個架構服務組做專案改進。當時我們在下面幾個維度進行改進，它們是持續整合、環境部署、配置管理、資料管理、測試管理、釋出管理。

《持續交付》一書上的成熟度模型

當然《持續交付》那本書的第15章也有一個模型。我們在這個團隊裡，因為它是一個後端架構服務的團隊，C/C++程式碼，我們對開原始碼也進行了改造，所有模組的程式碼加在起來，也有幾百萬行了。這個團隊原來的節奏基本上是每三個月釋出一個新版本。在剛才我提到的這幾個角度裡做了很多實踐。

在百度的看板實踐

圖片上的這個白板是他們的故事板。而那個燈是持續整合實踐中，顯示整合狀態（失敗，或者成功）的。只要你入了工作區，就能看到持續整合的狀態。如果這個燈是紅色的，你就知道剛剛的一次構建失敗了，有人正在修復。如果是綠色的，就說明現在的程式碼質量還不錯，一切正常進行中。這種方式有很大的視覺衝擊力，督促團隊保持質量。

持續整合六步法

這張圖是持續整合六步提交法。這是團隊開始啟動這個試點專案時共同約定的一個行為規範。只要是與程式碼相關的操作，你的工作步驟就應該是這樣的。

關於測試的實踐

在測試方面，我們在專案啟動時也有一些約定。圖上是一個我們自己的測試金字塔。對於最上層的系統測試，我們會根據具體情況，決定是否對新功能寫自動化測試用例。對於第二層的子系統測試和模組測試，我們決定全部使用自動化測試用例。而最下層的單元測試，我們決定在剛開始的階段，並不引入它。

當然，為了讓上面提到的持續整合和自動化測試實踐能夠真正變得具有可操作性，我們在編譯和測試系統也做了一些優化。通過引入分散式編譯技術，對編譯指令碼進行優化，以及在分散式編譯系統上加入編譯快取技術，讓持續整合能幫助開發人員節省更多的時間。

最後的結果

當團隊具備了持續交付的能力之後，團隊希望更高頻率地釋出版本。當與運維同學溝通這個需求時，他的迴應卻是一個非常為難的表情。問他原故時，他說：“開發同學搞的三個月一個版本都質量那麼不靠譜，現在要兩週釋出一次，我運維事故怕要多幾倍了吧？”

當時的一個業務運維人員，本身就要負責多個業務單元。而當前這個業務單元每三個月部署一次，每次需要花費兩天的時間，在三百多臺機器完成所有的升級部署工作。現在要兩週釋出一次，這就相當於把工作量提升了數倍。因此，運維第一反應是排斥這麼頻繁釋出軟體服務的。

後來我們想了很多自動化的方式，讓運維同學的工作量降下來，而且運維質量提高了。我們所有的部署的指令碼（無論是開發環境、測試環境，還是生產環境），都由運維同學提供。這樣，這些指令碼在開發環境和測試環境上就會得到充分地應用，同時也是對它們的測試。

經過半年多的執行，效果非常明顯。原來這個團隊的節奏是三個月一個版本，在這次改造之後，變成了兩週一個版本。對於一個後端負責架構改造的團隊來說，這是相當不容易能夠做到的。

試點專案結束半年以後，我與這個業務服務的專案經理聊天。他說團隊其實能做到一週釋出一次，但客戶方覺得兩週的節奏已經完全滿足他們的需求了，所以也就沒有執行一週釋出一次。

這就是說：“只要團隊具備能力，就可以隨心所遇。願意一週釋出就一週釋出，想兩週釋出一次就兩週釋出一次”。這個試點團隊並沒有利用到組織的力量，團隊自身的改進動力讓它自身的工作方式得到了改善。然而，當在三萬英尺的高度來看俯瞰全域性時，我就發現，這個試點的小團隊是非常美好的區域性，放到整個大環境中，就會產生一種無力感。如何讓這種工作方式能夠快速地推廣出去，讓所有人都受益呢？

案例二，在騰訊的持續交付案例

明明感覺很好是對的事情，但是卻總是有一種無力感，怎麼辦？

2013年我受邀到騰訊，在騰訊負責一個產品的研發改進工作。這個團隊的規模約400人。

新團隊的情況

當時，這個團隊設想得很好，希望每兩週釋出一個beta版，每個月釋出一個全網穩定版本。然而，現實是：可能兩三個月都搞不出來一個可以全網穩定的釋出版本。就像圖片上的情況一樣，理想中是整整齊齊的通向最終目的地，而實際的情況則是崎嶇坎坷的。

這個團隊人員多，流程多，各種延遲也就相應增多，同時，團隊面對的問題也很多。

到了這個團隊以後，他們我了描述了一下團研工作情況，上面羅列了他們在專案開發的過程中遇到的各種問題，類似於上圖所示。

注意:這不是服務端軟體，這是一款PC客戶端軟體。

最終實現的成果

面對如山的問題，我仍舊用時三個月時間，通過改進做到每天有兩個beta版本可對外發布，每週一個候選穩定版。每月一個全網穩定釋出版本。

改進後，軟體的基本質量得到保障，crash率下降了90%，產品品牌在騰訊精品軟體中排名第五，進步排名第三。而在前一年，這個產品被評為騰訊內部所有產品中最需改進的產品第二名。

改進實施步驟

• 組織架構解耦
  

  我們在這個團隊裡做了一個組織架構的解耦，根據我們的業務來組成不同的團隊。每個團隊裡可能包含產品、開發、測試等不同角色的成員。當然，這裡的“可能包含”是指：根據業務的不同，有的團隊裡沒有產品經理，而有的組裡可能沒有測試人員。我舉這個例子，並不是說一個組或一個業務裡，一定要有產品經理，或者一定要有測試人員。具體團隊組成需要根據實際情況來組織。但是每一個團隊都能負責一塊小的業務閉環，這是最重要的。

  

  當我們把組織解耦做完之後，我們發現，按照業務來這麼劃分後，原來的軟體系統架構不適合團隊協作了。為什麼呢？因為整個系統架構就像這個義大利麵條一樣交織在一起，就是現在經常提到的“單體系統”。這不利於每個業務閉環團隊各自按自己的節奏工作。

• 軟體架構解耦
  

  所以，我們做的第二個事情就是：軟體解耦。我們花了一定的時間和工作量，把整個系統在架構上做了一次調整，根據現行的小業務團隊，基於業務小閉環模式來做解耦。

  

  當我們做過架構解耦後，新問題又浮現了出來。在過去，所有人都繫結在一起釋出版本，因為他們原來的模式就是一起工作，一起發版本，就像圖片中被綁在一起跑步的同學們。現在，每個小團隊各自負責自己的業務閉環。所以，很多業務團隊說：“我自己想跑得快一點兒，我的功能已經開發完成了，為什麼還要等其他團隊，跟他們一起發版本呢?我們能不能在不傷害使用者的情況下自己團隊發自己的版本？於是改進還得繼續。

• 配置管理&一鍵式
  

  接著我們繼續做了非常好的配置管理系統、釋出系統，用來實現：在不傷害使用者的情況下，團隊如何自己釋出版本。

  最終實現了前面提到的效果：從2個月到2個小時。這2個小時是什麼概念呢？發版前的測試階段只需要2個小時的時間。只要測試沒有發現問題，就可以外發（改進之前，每個版本在最後的系統測試，需要兩週的時間）。如果發現問題，則會直接將程式碼回滾。這樣，就不會耽誤其它團隊的版本釋出了。

現在，你會發現：我們的改進步驟與前一個案例稍有不同。這個案例一共是四個步驟。第一步：組織解耦；第二步：架構解耦；第三步：配置管理升級；第四步：將一切自動化，提高效率。

案例反思

做了這個案例之後我就思考這樣一個問題：這兩個案例有哪些不一樣之處。（1）產品團隊的大小不同（一個300多人，一個10多個人）；（2）產品形態不同（一個是PC客戶端軟體，一個是後臺服務；（3）一個從整個團隊組織架構入手；一個從基礎設施入手。

那麼，在百度案例中用的這個成熟度模型，是正確的嗎？看上去是正確的，但還有一些瑕疵。因此，我在指導騰訊的產品團隊時，改進了一下，我稱之為“持續交付七巧板”。

除了在百度案例中所涉及的與技術基礎設施相關的那一部分內容之外，我還加入了另外兩塊內容，它們分別是（1）團隊協作機制；（2）系統架構適應性。

為什麼要用“七巧板”這個名字呢？我認為，基本因素只有這麼多，但是，你可以根據產品形態以及所處的發展階段、團隊規模，以及組織架構的不同，拼搭出不同的研發管理模式，而不需要一模一樣。

《持續交付》三步走

那麼，這兩個案例有哪些是一致的。我認為，做事的方式是相同的，都是三步：我稱之為“持續交付”三步走。

• 第一步 確定目標
  你要達成什麼目標？這個目標在團隊中是否達成了共識？這個目標最好能夠包含業務目標，而不僅僅是“提高工作效率，或工程效率”這樣比較寬泛的目標。當團隊有業務目標驅動的時候，更容易團隊一致。比如，“縮短髮布週期”只是一個寬泛目標，而“將釋出週期從兩個月縮短到一個月”，就是一個比較明確的業務目標。因為釋出週期的縮短可以為業務帶來更大的靈活性。

• 第二步 制定機制和方法
  當定義了業務目標之後，就需要制定合理的協作機制？比如，如何拆分你的團隊，團隊之間如何協作，你的架構應該是什麼樣子的。所以一定要從業務目標出發來討論這樣機制與方法。

• 第三步 完善配套基礎支援
  在制定和機制和方法後，就需要團隊執行。因為不可能在事先計劃好所有的內容。在執行過程中可能還會遇到一些困難和障礙。此時，一定要堅持目標，想辦法移除障礙，持續改善。而不是放棄或走回頭路。

這就是我的小結————“持續交付”三步法。

尾聲

為什麼有這樣的思考呢？因為在過去的幾年裡，我輔導過很多個公司，有知名的網際網路大公司，也有兩三百人的移動網際網路公司，還有傳統IT公司，一直使用“持續交付”三步法和“七巧板”來指導自己的諮詢工作。

最重要的一點，你要知道你解決的是什麼問題。

本文轉載自公眾號 「DevOps 時代」。

====================================

想更深的理解持續交付？

想更透徹的領悟 DevOps？

來 DevOpsDays 上海站吧

喬樑老師將帶來精彩的演講：《持續交付與 DevOps 精要》

點選“閱讀原文”，關注 DevOpsDays 上海站