[轉載]持續交付和DevOps的前世今生

作者/分享人：喬樑，20年IT老兵，騰訊公司高階管理顧問，敏捷和精益開發專家，持續交付領域先行者。曾就職於百度，國內多個知名網際網路公司的企業教練。 歷年QCon技術大會的講師和專題出品人。

這是一個新概念風起雲勇的時代。 就讓我們從雲端抓它幾個名詞下來，一起玩耍吧！！！ “敏捷軟體開發”，“增長黑客”，“持續整合”，“DevOps”，“精益創業”，“持續交付”，“大資料”… …

OK，就這四個啦：

“敏捷軟體開發”，“持續整合”，“DevOps”，“持續交付”。

先讓我們在Wikipedia上驗明正身。

在Wikipedia上的定義

敏捷軟體開發

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

持續整合

Continuous Integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

持續交付

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.

DevOps

DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.

我的解讀

1. 敏捷軟體開發方法

從來就沒有一種方法，叫做“敏捷軟體開發方法”。因為，IT行業中的“敏捷（Agile）”一詞，從2001年它的誕生之日起，就是個軟體開發方法集合，當時這個集合中的方法，都遵從敏捷宣言和相同的工作原則（十二原則），它的締造者是十七位軟體工程師（請查敏捷，雪鳥會議）。目前，在這面大旗下，又增加了很多種方法，當然也有很多方法走出了人們的視線。

在國內比較活躍的幾種方法：極限程式設計XP（2009年以前），Scrum及其進化品（2006年至今），精益軟體開發方法（2009年至今），看板方法（2012年至今）。當然，現在好象也不再特意強調“敏捷宣言”和“十二原則”了，只在培訓課堂上還能聽到。

2. 持續整合

早在1999年KentBack的《解析極限程式設計》一書中，對“持續整合”這一概念就有提及，它是極限程式設計XP方法中的十二最佳實踐之一。在2004年，Martin Fowler發表的一篇博文上，給“持續整合”下了一個定義，並一直沿用至今。即：“持續整合是一個軟體開發實踐， 是指團隊成員頻繁地整合他們的工作成果，通常每天每個人至少整合一次， 這樣在團隊內每天都會有多次程式碼整合，每次整合都有通過自動化的構建（包括測試）儘可能快地發現整合問題。” 這個概念已被軟體研發團隊廣泛接受，但是其中提到做法，並未能全部落實，太困難了。 這是正常的，來自極限程式設計方法的實踐，都是有挑戰的，否則就不叫“極限”二字了。

3. DevOps

在2008年的一次敏捷大會上，運維相關人員就“敏捷基礎設施（Agile Infrastructure）”展開討論，並在2009年以後逐步發展成為一場大規模“運動”，它是期望改變開發團隊和運維團隊之間協作關係的一場運動。強調開發團隊與運維團隊的溝通與協作，同時將軟體的交付與基礎設施變更過程都能夠自動化。近年基礎設施及工具鏈的發展，也讓DevOps多了一些發力點。

4. 持續交付

Jez Humble和David Farley在2010年《持續交付》一書中正式提出這個概念，它在書中被定義為：一系列的原則與實踐的集合；通過這個集合，團隊能夠在低成本、短時間及低風險的狀態下以增量方式將軟體變更交到使用者手上。Jez認為，持續交付有三個支柱，它們分別是持續整合、自動化測試和部署流水線（Deployment Pipeline）。

它們的關係

1. 空間與時間維度

根據以上的資訊，我認為它們在空間和時間維度的關係是這樣的：

上面這個圖是從實踐或環境的角度來看它們之間的關係。那麼，如果我們換一個角度呢？

2. 人或組織維度

我的微信簽名是“別提概念，只解決問題！”。所以我更願意從解決問題的角度看這些概念。一談到問題，就有一個經典的話浮現在我腦海裡：“所有的問題，都是人的問題”。所以，這個角度看到的才是本質。那麼，它們的關係是什麼呢？

持續整合，有助於打破開發人員和測試人員之間的“牆”。

敏捷開發，有助於打破研發團隊（開發+測試）與業務（產品）人員之間的“牆”。

DevOps，有助於打破開發團隊與運維團隊之間的“牆”。

持續交付，則是希望從端到端的角度，考慮如何解決問題。

為什麼從“人”開始

在我多年的持續交付踐行及諮詢工作中，總結的經驗是：如果希望在最短的時間和成本內，取得最大的收穫，那麼在一開始，與“人”相比，技術實踐並不需要太在意，即：最好還是先從“人”的角度看問題。真正去解決問題時，上面說的種種概念並不是那麼重要。它們都是你用來解決問題的工具，而且其中的每一個工具（概念）都包含了很多個小工具（原則和實踐）。而且，在解決問題時，你也不必整套選擇這些工具。

從哪裡找問題

從參與者的問題陳述中找問題。比如：

老闆：

• “專案經常延期” “做東西太慢”

產品：

• “老闆的想法總變”

• “事情太多，忙成狗”

• “開發說這個實現不了”

開發：

• “需求總變”

• “UI方案給的太晚”

• “活兒太多”

測試：

• “需求變了沒提前通知”

• “測試時間總被壓縮，還要背鍋”

• “重複測試太多遍”

運維：

• “每天這麼多版本上線，活幹不完，出事兒第一個背鍋。”

每句話的背後都有很多含義。開挖吧～～

提問題的人是問題的創造者，也是接盤俠～

從哪裡找解決方案

在《持續交付》一書的第十五章，提到一個“持續交付成熟度評估模型”。在這個模型中，包含如下六個維度：

• 構建管理和持續整合

• 環境與部署

• 釋出管理和和符合性

• 測試

• 資料管理

• 配置管理

通過實際工作的驗證，我發現，這裡面缺失了一些東西。所以，增加了一些維度，並重組了一下，如下圖所示：

我也沒有稱其為成熟度模型，而是“持續交付七巧板”。

是的，中國的傳統玩具“七巧板”，這個兒時的玩具可以拼出各種各樣的圖形。也就是說，每個團隊、企業都有不同的環境上下文（人也是環境的一部分），解決方案也不必一樣，關鍵是你想解決什麼（想拼成什麼圖形）。

找正確的問題去解決

上面的諸多概念並不是你的問題或目標，而只是你的工具（手段）。千萬不要把手段當成你的目標來實現。很多人問：

• 怎麼做持續交付？

• 怎麼做持續整合？

• 怎麼做敏捷？

• 怎麼做DevOps？

我猜測你是想問：是否有捷徑做XXX。當然有，多種途徑裡，一定有相對來說的捷徑，但不一定是你期望的那種“捷徑”。

• 我們做的是敏捷嗎？

• 我們這麼做持續交付，對嗎？

我猜測你是想問：（某個人或部門）這麼搞，是不是靠譜啊？

• 你這不是敏捷？

• 你這不是DevOps？

• 你這不是持續交付？

• 你這不是持續整合？

我想說：無所謂，因為我的在微信上的簽名是：別提概念，只解決問題。我們還是先討論清楚問題吧～

再炒一炒冷飯

2011年，我在InfoQ上發表了一篇案例文章《DevOps，不是一個傳說！》，其中有兩個評論比較有意思：

1. 怎麼感覺就是一個從瀑布模型到Scrum/CI的變化？

正如我們上面第二張圖所示，這個專案的前期工作，的確主要是在敏捷開發的範疇，但文中還是提到一小部分Ops方面的東西，可能評論者沒有注意到吧。或者沒有看到他想找的內容。

2. 標題黨啊

好吧，我承認在那個很少有人提及“DevOps”的年代，我就做標題黨吧。

這個案例就混合了上面所有的概念，但在專案裡，誰還在意概念呢，達成結果最重要。

一、瞭解環境背景

當任何人想要對組織進行改變時（無論改變的大小，你叫它改進、轉型或者變革都可以），一定先要了解組織的歷史，感受組織的文化，因為組織的歷史決定了問題的來源，定義了問題的範圍。

幾年前的百度，工程管理相對固化，敏捷還在“小步快跑，越變越美”的倡導期（從瀑布到迭代，強調專案管理中的迭代概念）。一個從Google跳槽加盟百度的技術經理在自己的部門裡倡導“主幹開發（Single Branch mode）”，但由於原有的基因特別強大，進展艱難。 而這個專案是在最有百度特質的大搜尋團隊，試驗田是一個10人左右的工程架構團隊。

團隊間接管理者

• 專案交付不太可控：

  • 我們一直在做計劃，但計劃性非常差。

  • 經常有各種各樣的情況發生，總會讓專案改期。

團隊直接管理者

• 我非常希望能夠快速交付，但我們對這類架構變動類的專案不知道怎麼能做到。

• 這個專案中，有一部份需求必須在XXX時間點完成。

團隊Lead

• 估算不準確、臨時插入事情多、專案計劃很難做（這裡省略一千字）。

• 我不知道怎麼改進，因為我周圍的團隊也是這樣，而且一直這樣工作。

開發人員

• 領導說試一下，就試一下吧。

測試人員

• 工作經常被打斷。

• 提測質量不高，經常浪費精力。

• 出了Bug，影響太大。

• （這裡省略一千字）。

二、找到正確的問題來解決（目標）

三個月內：

（１）該專案交付時間可預期。

（２）建立新的軟體開發協作方式。

（３）建立必要的基礎設施，以支援後續的持續釋出模式。

三個月後：

（１）需求的週期時間縮短，可以短週期上線。

（２）生產環境的質量不降低。

（３）測試人力總投入降低。

在少於30人的團隊（61個人也可以～哈哈～那62個人呢～～～）

1. 通常行為的改變，需要一個半月的時間；

2. 帶來強烈可感知的收益需要三個月的時間。

三、承諾是必須的

上面的問題（目標）找到了，也要一併承諾。

要想讓團隊和你走，你必須站在前面。

四、培訓及過程指導

需要解決團隊提出的任何疑問，如果當時不知道如何解決，也要承認。

啟蒙培訓（1小時）

對於這種能夠直接認識團隊每個人的小團隊，一開始就別花費太長時間講大道理，以解決具體問題的方式來啟蒙。

重新定義工作流程

• 新的專案工作流程

• 新的迭代工作流程

• 新的需求工作流程

• 新的程式碼工作流程

解決新流程中的障礙

• 團隊溝通和協作的方式。

• 編譯環境的準備。

• 編譯時間的縮短。

• 自動化測試策略的制定，比如：我們放棄了原教旨主義的單元測試。

  

• 自動化測試執行的環境的準備。

• 自動化測試編寫時機與自動化的利用。

• 自動化測試用例程式碼管理。

我和運維人員的對話（真實的場景再現）

我：我們團隊想每兩週就部署一次服務 

運維：不行 

我：為啥？ 

運維：線上需要穩定 

我：每兩週部署一次，就不穩定了嗎？ 

運維：原來的質量太差，每次上線總是出問題 

我：現在質量很好 

運維：怎麼可能？ 

我：我們改變了工作方法，質量優先，你可以參加我們的站會。你有什麼要求，我們都可以滿足 

運維：那也不行 

我：為啥 

運維：我沒有那麼多時間。一次部署要涉及370多臺機器。原來三個月上線一次，每次前前後後要折騰兩天。現在每兩週上線一次，我還哪裡有時間去幹其它業務線的活啊？

怎麼解決？

改變部署方式，讓他的工作生活美好起來吧～～～～～

• 部署流水線的建立，要求一鍵部署

  • 運維人員負責編寫部署指令碼，並做版本管理。

  • 開發人員在開發自測時使用同樣的指令碼。

  • 測試人員在測試環境上使用同樣的指令碼。

  • 運維人員在生產環境上也使用同樣的指令碼。

如果想了解更多，我的“持續交付”微信公眾號上對這個案例進行連載分析。感興趣就來我的Chat交流吧。

善意的提醒

強烈建議大家仔細研讀《持續交付》，儘管這是一個大部頭著作，而沒有程式碼，少量插圖，也沒有什麼工具使用說明。

我正在寫一本關於持續交付案例解讀相關的書，希望能幫助大家。書中很多內容是我在實際工作裡如何運用書中的理論和原則，做出我認為適當的選擇（比如上例中的不做單元測試），幫助團隊解決實際問題。

原文地址：《持續交付和DevOps的前世今生》

本文轉自SanMaoSpace部落格園部落格，原文連結：http://www.cnblogs.com/SanMaoSpace/p/6842417.html，如需轉載請自行聯絡原作者