《一張圖帶你了解“持續(xù)交付”和“DevOps”的前世今生》要點：
本文介紹了一張圖帶你了解“持續(xù)交付”和“DevOps”的前世今生，希望對您有用。如果有疑問，可以聯(lián)系我們。

這是一個新概念風起云勇的時代. 就讓我們從云端抓它幾個名詞下來,一起玩耍吧!!! “敏捷軟件開發(fā)”,“增長黑客”,“持續(xù)集成”,“DevOps”,“精益創(chuàng)業(yè)”,“持續(xù)交付”,“大數(shù)據(jù)”… …

OK,就這四個啦：

“敏捷軟件開發(fā)”,“持續(xù)集成”,“DevOps”,“持續(xù)交付”,

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

在Wikipedia上的定義

敏捷軟件開發(fā)

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.

持續(xù)集成

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

持續(xù)交付

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. 敏捷軟件開發(fā)方法

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

在國內(nèi)比較活躍的幾種方法：極限編程XP(2009年以前),Scrum及其進化品(2006年至今),精益軟件開發(fā)方法(2009年至今),看板方法(2012年至今).當然,現(xiàn)在好象也不再特意強調(diào)“敏捷宣言”和“十二原則”了,只在培訓課堂上還能聽到.

2. 持續(xù)集成

早在1999年KentBack的《解析極限編程》一書中,對“持續(xù)集成”這一概念就有提及,它是極限編程XP方法中的十二最佳實踐之一.在2004年,Martin Fowler發(fā)表的一篇博文上,給“持續(xù)集成”下了一個定義,并一直沿用至今.即：“持續(xù)集成是一個軟件開發(fā)實踐, 是指團隊成員頻繁地集成他們的工作成果,通常每天每個人至少集成一次, 這樣在團隊內(nèi)每天都會有多次代碼集成,每次集成都有通過自動化的構(gòu)建(包括測試)盡可能快地發(fā)現(xiàn)集成問題.” 這個概念已被軟件研發(fā)團隊廣泛接受,但是其中提到做法,并未能全部落實,太困難了. 這是正常的,來自極限編程方法的實踐,都是有挑戰(zhàn)的,否則就不叫“極限”二字了.

3. DevOps

在2008年的一次敏捷大會上,運維相關人員就“敏捷基礎設施(Agile Infrastructure)”展開討論,并在2009年以后逐步發(fā)展成為一場大規(guī)模“運動”,它是期望改變開發(fā)團隊和運維團隊之間協(xié)作關系的一場運動.強調(diào)開發(fā)團隊與運維團隊的溝通與協(xié)作,同時將軟件的交付與基礎設施變更過程都能夠自動化.近年基礎設施及工具鏈的發(fā)展,也讓DevOps多了一些發(fā)力點.

4. 持續(xù)交付

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

它們的關系

1. 空間與時間維度

根據(jù)以上的信息,我認為它們在空間和時間維度的關系是這樣的：

上面這個圖是從實踐或環(huán)境的角度來看它們之間的關系.那么,如果我們換一個角度呢?

2. 人或組織維度

我的微信簽名是“別提概念,只解決問題!”.所以我更愿意從解決問題的角度看這些概念.一談到問題,就有一個經(jīng)典的話浮現(xiàn)在我腦海里：“所有的問題,都是人的問題”.所以,這個角度看到的才是本質(zhì).那么,它們的關系是什么呢?

持續(xù)集成,有助于打破開發(fā)人員和測試人員之間的“墻”.

敏捷開發(fā),有助于打破研發(fā)團隊(開發(fā)+測試)與業(yè)務(產(chǎn)品)人員之間的“墻”.

DevOps,有助于打破開發(fā)團隊與運維團隊之間的“墻”.

持續(xù)交付,則是希望從端到端的角度,考慮如何解決問題.

為什么從“人”開始

在我多年的持續(xù)交付踐行及咨詢工作中,總結(jié)的經(jīng)驗是：如果希望在最短的時間和成本內(nèi),取得最大的收獲,那么在一開始,與“人”相比,技術(shù)實踐并不需要太在意,即：最好還是先從“人”的角度看問題.真正去解決問題時,上面說的種種概念并不是那么重要.它們都是你用來解決問題的工具,而且其中的每一個工具(概念)都包含了很多個小工具(原則和實踐).而且,在解決問題時,你也不必整套選擇這些工具.

從哪里找問題

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

老板：

• “項目經(jīng)常延期” “做東西太慢”

產(chǎn)品：

• “老板的想法總變”
• “事情太多,忙成狗”
• “開發(fā)說這個實現(xiàn)不了”

開發(fā)：

• “需求總變”
• “UI方案給的太晚”
• “活兒太多”

測試：

• “需求變了沒提前通知”
• “測試時間總被壓縮,還要背鍋”
• “重復測試太多遍”

運維：

• “每天這么多版本上線,活干不完,出事兒第一個背鍋.”

每句話的背后都有很多含義.開挖吧～～

提問題的人是問題的創(chuàng)造者,也是接盤俠～

從哪里找解決方案

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

• 構(gòu)建管理和持續(xù)集成
• 環(huán)境與部署
• 發(fā)布管理和和符合性
• 測試
• 數(shù)據(jù)管理
• 配置管理

通過實際工作的驗證,我發(fā)現(xiàn),這里面缺失了一些東西.所以,增加了一些維度,并重組了一下,如下圖所示：

我也沒有稱其為成熟度模型,而是“持續(xù)交付七巧板”.

是的,中國的傳統(tǒng)玩具“七巧板”,這個兒時的玩具可以拼出各種各樣的圖形.也就是說,每個團隊、企業(yè)都有不同的環(huán)境上下文(人也是環(huán)境的一部分),解決方案也不必一樣,關鍵是你想解決什么(想拼成什么圖形).

找正確的問題去解決

上面的諸多概念并不是你的問題或目標,而只是你的工具(手段).千萬不要把手段當成你的目標來實現(xiàn).很多人問：

• 怎么做持續(xù)交付?
• 怎么做持續(xù)集成?
• 怎么做敏捷?
• 怎么做DevOps?

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

• 我們做的是敏捷嗎?
• 我們這么做持續(xù)交付,對嗎?

我猜測你是想問：(某個人或部門)這么搞,是不是靠譜啊?

• 你這不是敏捷?
• 你這不是DevOps?
• 你這不是持續(xù)交付?
• 你這不是持續(xù)集成?

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

再炒一炒冷飯

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

1. 怎么感覺就是一個從瀑布模型到Scrum/CI的變化?
正如我們上面第二張圖所示,這個項目的前期工作,的確主要是在敏捷開發(fā)的范疇,但文中還是提到一小部分Ops方面的東西,可能評論者沒有注意到吧.或者沒有看到他想找的內(nèi)容.

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

這個案例就混合了上面所有的概念,但在項目里,誰還在意概念呢,達成結(jié)果最重要.

一、了解環(huán)境背景

當任何人想要對組織進行改變時(無論改變的大小,你叫它改進、轉(zhuǎn)型或者變革都可以),一定先要了解組織的歷史,感受組織的文化,因為組織的歷史決定了問題的來源,定義了問題的范圍.

幾年前的百度,工程管理相對固化,敏捷還在“小步快跑,越變越美”的倡導期(從瀑布到迭代,強調(diào)項目管理中的迭代概念).一個從Google跳槽加盟百度的技術(shù)經(jīng)理在自己的部門里倡導“主干開發(fā)(Single Branch mode)”,但由于原有的基因特別強大,進展艱難. 而這個項目是在最有百度特質(zhì)的大搜索團隊,試驗田是一個10人左右的工程架構(gòu)團隊.

團隊間接管理者

• 項目交付不太可控：
  • 我們一直在做計劃,但計劃性非常差.
  • 經(jīng)常有各種各樣的情況發(fā)生,總會讓項目改期.

團隊直接管理者

• 我非常希望能夠快速交付,但我們對這類架構(gòu)變動類的項目不知道怎么能做到.
• 這個項目中,有一部份需求必須在XXX時間點完成.

團隊Lead

• 估算不準確、臨時插入事情多、項目計劃很難做(這里省略一千字).
• 我不知道怎么改進,因為我周圍的團隊也是這樣,而且一直這樣工作.

開發(fā)人員

• 領導說試一下,就試一下吧.

測試人員

• 工作經(jīng)常被打斷.
• 提測質(zhì)量不高,經(jīng)常浪費精力.
• 出了Bug,影響太大.
• (這里省略一千字).

二、找到正確的問題來解決(目標)

三個月內(nèi)：

(１)該項目交付時間可預期.

(２)建立新的軟件開發(fā)協(xié)作方式.

(３)建立必要的基礎設施,以支持后續(xù)的持續(xù)發(fā)布模式.

三個月后：

(１)需求的周期時間縮短,可以短周期上線.

(２)生產(chǎn)環(huán)境的質(zhì)量不降低.

(３)測試人力總投入降低.

在少于30人的團隊(61個人也可以～哈哈～那62個人呢～～～)

1. 通常行為的改變,需要一個半月的時間；
2. 帶來強烈可感知的收益需要三個月的時間.

三、承諾是必須的

上面的問題(目標)找到了,也要一并承諾.

要想讓團隊和你走,你必須站在前面.

四、培訓及過程指導

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

啟蒙培訓(1小時)

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

重新定義工作流程

• 新的項目工作流程
• 新的迭代工作流程
• 新的需求工作流程

• 新的代碼工作流程

解決新流程中的障礙

• 團隊溝通和協(xié)作的方式.
• 編譯環(huán)境的準備.
• 編譯時間的縮短.
• 自動化測試策略的制定,比如：我們放棄了原教旨主義的單元測試.

• 自動化測試運行的環(huán)境的準備.
• 自動化測試編寫時機與自動化的利用.
• 自動化測試用例代碼管理.

我和運維人員的對話(真實的場景再現(xiàn))

我：我們團隊想每兩周就部署一次服務 運維：不行 我：為啥? 運維：線上需要穩(wěn)定 我：每兩周部署一次,就不穩(wěn)定了嗎? 運維：原來的質(zhì)量太差,每次上線總是出問題 我：現(xiàn)在質(zhì)量很好 運維：怎么可能? 我：我們改變了工作方法,質(zhì)量優(yōu)先,你可以參加我們的站會.你有什么要求,我們都可以滿足； 運維：那也不行 我：為啥 運維：我沒有那么多時間.一次部署要涉及370多臺機器.原來三個月上線一次,每次前前后后要折騰兩天.現(xiàn)在每兩周上線一次,我還哪里有時間去干其它業(yè)務線的活啊?

怎么解決?

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

• 部署流水線的建立,要求一鍵部署
  • 運維人員負責編寫部署腳本,并做版本管理.
  • 開發(fā)人員在開發(fā)自測時使用同樣的腳本.
  • 測試人員在測試環(huán)境上使用同樣的腳本.
  • 運維人員在生產(chǎn)環(huán)境上也使用同樣的腳本.

作者：喬梁
20年IT老兵,騰訊公司高級管理顧問,敏捷和精益開發(fā)專家,持續(xù)交付領域先行者.曾就職于百度,國內(nèi)多個知名互聯(lián)網(wǎng)公司的企業(yè)教練. 歷年QCon技術(shù)大會的講師和專題出品人,相關內(nèi)容收集在持續(xù)交付中文站 http://www.continuousdelivery.com

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4167.html