Jenkins 創(chuàng)始人談：持續(xù)交付與DevOps

Jenkins創(chuàng)始人Kohsuke Kawaguchi（KK）于2004年開發(fā)了 Jenkins 項(xiàng)目的前身（Hudson），一開始就是為了解決他自己的關(guān)于自動化的需求。他自己也沒想到15年后，Jenkins 成了軟件交付過程中的核心工具，驅(qū)動著千萬企業(yè)的持續(xù)交付與 DevOps 過程。

這次主題演講KK系統(tǒng)的分析了持續(xù)交付與 DevOps 的體系、現(xiàn)狀、路線圖和模式，和 Patrick 在 DevOpsDays · 北京站的演講一樣，大神為我們點(diǎn)亮了命星！

整理的重點(diǎn)內(nèi)容：

1. 持續(xù)交付框架分析
2. 敏捷/持續(xù)交付/DevOps成熟度現(xiàn)狀、級別劃定、改進(jìn)四象限與路線圖等
3. DevOps轉(zhuǎn)型策略
4. 工程實(shí)踐簡介
5. 持續(xù)交付的黃金思維圈

1、流程線已經(jīng)改變過一次世界

福特在引入流水線生產(chǎn)之后，Model-T 的組裝時間縮短了8倍。1.3萬名員工生產(chǎn)了30萬量汽車，超過了300家競爭對手的總和，這就是效率的神話。

不過后來豐田超越了福特，在不確定性越來越突出的現(xiàn)在，單純的效率已經(jīng)不能滿足企業(yè)的競爭，所以精益、敏捷、DevOps 才會出現(xiàn)，繼續(xù)探索軟件開發(fā)新模式、拓展效率和質(zhì)量的新邊疆。

2、軟件正在吞噬世界

這個是共識，這是全人類的挑戰(zhàn)和機(jī)遇，對我們從事工程效率和過程改進(jìn)的人來說，不斷改進(jìn)軟件交付的方式和效率，沒有止境。

3、頭號需求：業(yè)務(wù)連續(xù)性（不停機(jī)）

各大權(quán)威機(jī)構(gòu)對 IT、DevOps、Continuous Delivery 的預(yù)測和評估。

我認(rèn)為業(yè)務(wù)連續(xù)性也只是其中一項(xiàng)需求而已，整體上來講，我們要解決的兩個問題是：Build the things right and Build the right things。

從 KK 的 PPT 里獲取的信息是，他認(rèn)為，持續(xù)交付和自動化是我們需要的答案之一。

4、持續(xù)交付框架分析

KK 的持續(xù)交付相關(guān)內(nèi)容梳理的很清晰。這張圖也可以說是 DevOps 的管理與工程實(shí)踐框架。KK 也強(qiáng)調(diào)了 DevOps 是一組文化方法和技術(shù)實(shí)踐。

維度：

1. 階段：產(chǎn)品定義、計(jì)劃、編碼、編譯、構(gòu)建、單元測試、分析、集成、集成測試、打包、Place、壓力測試、驗(yàn)收測試、發(fā)布、部署、監(jiān)控
   其中的構(gòu)建和編譯、單元測試并列，不清楚這里的構(gòu)建表示什么？我理解的構(gòu)建時編譯、打包、或者在加上單元測試、代碼分析的整體。自動化構(gòu)建的目標(biāo)就是要輸出（高質(zhì)量）可以部署和測試的軟件包。
   另外，關(guān)于Place也沒有找到對應(yīng)的解釋，有點(diǎn)像部署或者分發(fā)

2. 環(huán)境

3. 開發(fā)環(huán)境

4. 預(yù)發(fā)布環(huán)境（類生產(chǎn)環(huán)境）

5. 生產(chǎn)環(huán)境
   關(guān)鍵中缺少獨(dú)立的測試環(huán)境，從圖上的分布看，應(yīng)該是包含在Development中的

6. 方法

7. 敏捷
   「對特性進(jìn)行識別、排序、調(diào)整的增量開發(fā)方法」。不太理解，敏捷的具體方法框架有很多，包括Scrum，XP，Kanban（準(zhǔn)確的說屬于精益方法）。還有 SAFe，Less 等規(guī)?；蚣堋?/span>

8. 持續(xù)集成
   持續(xù)集成是持續(xù)交付的基礎(chǔ)，持續(xù)交付是 DevOps 的核心工程實(shí)踐。非常重要。

9. 持續(xù)交付

10. 持續(xù)部署另外，紅色框的邏輯沒有理解明白，有高手請指點(diǎn)。
    

5、生存還是毀滅，你可以選擇

每年的 State of DevOps Report 都會公布四個關(guān)鍵指標(biāo)的數(shù)據(jù)：部署頻率、周期時間、部署失敗率、故障修復(fù)時間。高效能IT組織和低效能IT組織的差異非常大。KK的這兩張圖也非常形象的說明了這個問題。

6、現(xiàn)狀和方向

6.1 敏捷團(tuán)隊(duì)占比

現(xiàn)狀是上游敏捷（管理過程，比如Scrum）的團(tuán)隊(duì)占比33%，下游敏捷（持續(xù)交付）的團(tuán)隊(duì)占比13%。

這也符合國內(nèi)的情況，很多團(tuán)隊(duì)剛開始做敏捷的時候都是從管理過程開始敏捷，大多從 Scrum 入手，但是效果一般都不盡如人意。

我認(rèn)為持續(xù)集成和自動化測試是敏捷的兩條腿，想要敏捷跑起來，此二者必須同時建設(shè)才能讓敏捷體現(xiàn)其快速響應(yīng)變化的價值。

6.2 非敏捷團(tuán)隊(duì)占比

根據(jù) KK 的數(shù)據(jù)，目前有87%的團(tuán)隊(duì)，依然沒有實(shí)現(xiàn)下游的敏捷，即持續(xù)交付和持續(xù)部署的實(shí)施較少或者不成熟。這會導(dǎo)致價值的交付依然長達(dá)數(shù)月之久。

6.3 成熟度級別

KK 將敏捷（CD、DevOps）的級別劃分為團(tuán)隊(duì)級，跨團(tuán)隊(duì)級，企業(yè)級。這個和 DevOps 之父 Patrick 的 DevOps 5個精進(jìn)級別頗為相似。

企業(yè)級的敏捷和 DevOps 還有很長的路要走。企業(yè)級的改進(jìn)需要組織、文化都要共同變化。

編者：之前在參加敏捷培訓(xùn)時，老師提到諾西在敏捷方面做的很早也很深入，摩托做 CMMI 和 6 Sigma 也做的很好，但是這些企業(yè)現(xiàn)在都不在了。組織、戰(zhàn)略、文化的敏捷至關(guān)重要。下邊的人玩兒的很嗨，只是用正確的方法在做錯誤的事情而已。頗有感觸！

6.4 改進(jìn)四象限

KK 基于團(tuán)隊(duì)級、跨團(tuán)隊(duì)級、企業(yè)級以及上下游階段，將改進(jìn)方向劃分為四個象限。

1. 團(tuán)隊(duì)級的敏捷
2. 團(tuán)隊(duì)級的CD
3. 企業(yè)級的敏捷
4. 企業(yè)級的DevOps（我相信2017和2018年，國內(nèi)企業(yè)一定會邁進(jìn)企業(yè)級的DevOps轉(zhuǎn)型和落地）

6.5 改進(jìn)路徑與模式

KK 基于四象限將改進(jìn)劃分為2條路徑和2種模式

路徑一：

從團(tuán)隊(duì)敏捷到企業(yè)級（組織級）敏捷，再到企業(yè)級 DevOps

路徑二：

團(tuán)隊(duì)級敏捷—>團(tuán)隊(duì)級持續(xù)交付—>企業(yè)級敏捷—>企業(yè)級 DevOps

我所了解的企業(yè)，偏向于類似第二種的路徑，一開始都在團(tuán)隊(duì)級別進(jìn)行敏捷和持續(xù)交付的嘗試，逐漸成熟推廣復(fù)用，規(guī)?；?。

· 自下而上的改進(jìn)

這種模式應(yīng)該是比較常見

· 自上而下的改進(jìn)

6.6 DevOps轉(zhuǎn)型策略

KK給出了自己的建議：

1. 識別試點(diǎn)項(xiàng)目
2. 組建跨職能團(tuán)隊(duì)
3. 采用統(tǒng)一的技術(shù)
4. 基于可度量的KPI和里程碑制定計(jì)劃
5. Go
6. 度量，文檔化，改進(jìn)
7. 規(guī)?；瘜?shí)踐

關(guān)于第4點(diǎn)，我個人一直不喜歡考核，尤其是KPI。我希望的是一種能將工程師導(dǎo)向良性行為的評估方式。但是KK提到的可度量，是一種可取的方式，可度量意味著可執(zhí)行，有目標(biāo)。

但是度量一定要慎之又慎。一句話：度量改變行為。

7、工程實(shí)踐

關(guān)于持續(xù)交付，KK重點(diǎn)強(qiáng)調(diào)了：A straightforward and repeatable deployment process is important for continuous delivery.

7.1 架構(gòu)與實(shí)現(xiàn)技術(shù)

1. 特性開關(guān)

2. 灰度發(fā)布

3. 微服務(wù)
   以上三個技術(shù)對發(fā)布和部署都有很大的提升，特性開關(guān)可以調(diào)整應(yīng)用的運(yùn)用時狀態(tài)，灰度發(fā)布逐步的切換流量，微服務(wù)可以做到單個服務(wù)的獨(dú)立發(fā)布和部署。

4. 基礎(chǔ)設(shè)施技術(shù)

5. 藍(lán)綠部署

6. 金絲雀發(fā)布

7. 鳳凰環(huán)境

8. 不可變基礎(chǔ)設(shè)施

7.2 基于Jenkins的CD/DevOps生態(tài)系統(tǒng)

Jenkins是驅(qū)動整個持續(xù)交付和DevOps的核心組件。

8、DevOps 黃金思維圈

以上就是我在研讀 KK 的 PPT 過程中的思考和記錄，沒到現(xiàn)場，所以感覺很零散。恰好最近剛接觸一個概念：黃金思維圈，如下圖所示：

黃金思維圈幫助我們認(rèn)知世界，當(dāng)然也可以幫助我們認(rèn)知持續(xù)交付，嘗試分析了一下：

Why：
持續(xù)且快速、可靠的自動交付軟件給用戶：

1. 實(shí)現(xiàn)價值的持續(xù)交付，贏得市場競爭
2. 提升研發(fā)（增值活動）的時間，極大化增值活動產(chǎn)出

How：
建設(shè)自動化、可重復(fù)、可靠的持續(xù)交付流水線（IT服務(wù)供應(yīng)鏈）
主要包括代碼管理、持續(xù)集成、自動化測試、自動化部署、基礎(chǔ)設(shè)施自動化管理等方面的工程能力。

What：

1. 每次代碼提交都需要經(jīng)過流水線驗(yàn)證
2. 每次部署的版本都經(jīng)過多環(huán)境驗(yàn)證
3. 部署頻率可以得到提升
4. 周期時間（從代碼提交到部署上線）的時間可以到分鐘級
5. 部署失敗率低
6. 部署失敗的修復(fù)時間短，影響小

- END -
 推薦閱讀 

K8s運(yùn)維架構(gòu)師實(shí)戰(zhàn)集訓(xùn)營【多個企業(yè)項(xiàng)目】 
Linux 這些工具堪稱神器！
為什么說Prometheus是為云原生監(jiān)控而生的？
Prometheus+Granafa構(gòu)建高大上的MySQL監(jiān)控平臺
12年資深運(yùn)維老司機(jī)的成長感悟
快速入門 Ansible 自動化運(yùn)維工具 | 16張圖
運(yùn)維的工作邊界，這次真的搞明白了！
最強(qiáng)整理！常用正則表達(dá)式速查手冊
60道常見的 Kubernetes 面試題總結(jié)
不管你是開發(fā)還是運(yùn)維，微服務(wù)這些你得知道！
搭建一套完整的企業(yè)級 K8s 集群（v1.20，kubeadm方式）



點(diǎn)亮，服務(wù)器三年不宕機(jī)