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

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

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

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

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

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

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

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

2、軟件正在吞噬世界

這個(gè)是共識(shí)，這是全人類的挑戰(zhàn)和機(jī)遇，對(duì)我們從事工程效率和過(guò)程改進(jìn)的人來(lái)說(shuō)，不斷改進(jìn)軟件交付的方式和效率，沒(méi)有止境。

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

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

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

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

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

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

維度：

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

2. 環(huán)境

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

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

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

6. 方法

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

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

9. 持續(xù)交付

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

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

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

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

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

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

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

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

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

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

6.3 成熟度級(jí)別

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

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

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

6.4 改進(jìn)四象限

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

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

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

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

路徑一：

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

路徑二：

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

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

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

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

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

6.6 DevOps轉(zhuǎn)型策略

KK給出了自己的建議：

1. 識(shí)別試點(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)，我個(gè)人一直不喜歡考核，尤其是KPI。我希望的是一種能將工程師導(dǎo)向良性行為的評(píng)估方式。但是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. 特性開(kāi)關(guān)

2. 灰度發(fā)布

3. 微服務(wù)
   以上三個(gè)技術(shù)對(duì)發(fā)布和部署都有很大的提升，特性開(kāi)關(guān)可以調(diào)整應(yīng)用的運(yùn)用時(shí)狀態(tài)，灰度發(fā)布逐步的切換流量，微服務(wù)可以做到單個(gè)服務(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ū)動(dòng)整個(gè)持續(xù)交付和DevOps的核心組件。

8、DevOps 黃金思維圈

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

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

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

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

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

What：

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

- END -
 推薦閱讀 

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



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