《Jenkins 創始人：持續交付的 What、Why 及 How》要點：
本文介紹了Jenkins 創始人：持續交付的 What、Why 及 How，希望對您有用。如果有疑問，可以聯系我們。

本文首發于 JenkinsCI 公眾號,源自 Jenkins 的創始人 Kohsuke Kawaguchi (簡稱 KK)在 QCon 北京上的主題演講：「Why,What,and How of Continuous Delivery」.沒聽到現場演講,仔細研讀PPT之后,整理筆記如下.

編外的話

KK是一位攝影愛好者,所以PPT里會有大量精美的圖片,這 PPT 看著多舒心呀!筆者有幸在北京和KK有過一次親密接觸,并和KK暢聊 Jenkins 及 DevOps.

真的不是我矮啊,只是KK太高了??

Kohsuke Kawaguchi(KK)于2004年開發了 Jenkins 項目的前身(Hudson),一開始就是為了解決他自己的關于自動化的需求.他自己也沒想到13年后,Jenkins 成了軟件交付過程中的核心工具,驅動著千萬企業的持續交付與 DevOps 過程.

這次主題演講KK系統的分析了持續交付與 DevOps 的體系、現狀、路線圖和模式,和 Patrick 在 DevOpsDays · 北京站的演講一樣,大神為我們點亮了命星!

整理的重點內容：

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

1、流程線已經改變過一次世界

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

不過后來豐田超越了福特,在不確定性越來越突出的現在,單純的效率已經不能滿足企業的競爭,所以精益、敏捷、DevOps 才會出現,繼續探索軟件開發新模式、拓展效率和質量的新邊疆.

2、軟件正在吞噬世界

這個是共識,這是全人類的挑戰和機遇,對我們從事工程效率和過程改進的人來說,不斷改進軟件交付的方式和效率,沒有止境.

3、頭號需求：業務連續性(不停機)

各大權威機構對 IT、DevOps、Continuous Delivery 的預測和評估.

我認為業務連續性也只是其中一項需求而已,整體上來講,我們要解決的兩個問題是：Build the things right and Build the right things.

從 KK 的 PPT 里獲取的信息是,他認為,持續交付和自動化是我們需要的答案之一.

4、持續交付框架分析

KK 的持續交付相關內容梳理的很清晰.這張圖也可以說是 DevOps 的管理與工程實踐框架.KK 也強調了 DevOps 是一組文化方法和技術實踐.

維度：

1. 階段：產品定義、計劃、編碼、編譯、構建、單元測試、分析、集成、集成測試、打包、Place、壓力測試、驗收測試、發布、部署、監控
   其中的構建和編譯、單元測試并列,不清楚這里的構建表示什么?我理解的構建時編譯、打包、或者在加上單元測試、代碼分析的整體.自動化構建的目標就是要輸出(高質量)可以部署和測試的軟件包.
   另外,關于Place也沒有找到對應的解釋,有點像部署或者分發
2. 環境
3. 開發環境
4. 預發布環境(類生產環境)
5. 生產環境
   關鍵中缺少獨立的測試環境,從圖上的分布看,應該是包含在Development中的
6. 方法
7. 敏捷
   「對特性進行識別、排序、調整的增量開發方法」.不太理解,敏捷的具體方法框架有很多,包括Scrum,XP,Kanban(準確的說屬于精益方法).還有 SAFe,Less 等規?；蚣?
8. 持續集成
   持續集成是持續交付的基礎,持續交付是 DevOps 的核心工程實踐.非常重要.
9. 持續交付
10. 持續部署另外,紅色框的邏輯沒有理解明白,有高手請指點.

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

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

6、現狀和方向

6.1 敏捷團隊占比

現狀是上游敏捷(管理過程,比如Scrum)的團隊占比33%,下游敏捷(持續交付)的團隊占比13%.

這也符合國內的情況,很多團隊剛開始做敏捷的時候都是從管理過程開始敏捷,大多從 Scrum 入手,但是效果一般都不盡如人意.

我認為持續集成和自動化測試是敏捷的兩條腿,想要敏捷跑起來,此二者必須同時建設才能讓敏捷體現其快速響應變化的價值.

6.2 非敏捷團隊占比

根據 KK 的數據,目前有87%的團隊,依然沒有實現下游的敏捷,即持續交付和持續部署的實施較少或者不成熟.這會導致價值的交付依然長達數月之久.

6.3 成熟度級別

KK 將敏捷(CD、DevOps)的級別劃分為團隊級,跨團隊級,企業級.這個和 DevOps 之父 Patrick 的 DevOps 5個精進級別頗為相似.

企業級的敏捷和 DevOps 還有很長的路要走.企業級的改進需要組織、文化都要共同變化.

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

6.4改進四象限

KK 基于團隊級、跨團隊級、企業級以及上下游階段,將改進方向劃分為四個象限.

1. 團隊級的敏捷 2. 團隊級的CD 3. 企業級的敏捷 4. 企業級的DevOps(我相信2017和2018年,國內企業一定會邁進企業級的DevOps轉型和落地)

6.5改進路徑與模式

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

路徑一：

從團隊敏捷到企業級(組織級)敏捷,再到企業級 DevOps

路徑二：

團隊級敏捷—>團隊級持續交付—>企業級敏捷—>企業級 DevOps

 

我所了解的企業,偏向于類似第二種的路徑,一開始都在團隊級別進行敏捷和持續交付的嘗試,逐漸成熟推廣復用,規?；?

· 自下而上的改進

這種模式應該是比較常見

· 自上而下的改進

 

DevOps轉型策略

KK給出了自己的建議：

1. 識別試點項目

2. 組建跨職能團隊

3. 采用統一的技術

4. 基于可度量的KPI和里程碑制定計劃

5. Go

6. 度量,文檔化,改進

7. 規?；瘜嵺`

關于第4點,我個人一直不喜歡考核,尤其是KPI.我希望的是一種能將工程師導向良性行為的評估方式.但是KK提到的可度量,是一種可取的方式,可度量意味著可執行,有目標.

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

7、工程實踐

關于持續交付,KK重點強調了：A straightforward and repeatable deployment process is important for continuous delivery.

7.1 架構與實現技術

1. 特性開關
2. 灰度發布
3. 微服務
   以上三個技術對發布和部署都有很大的提升,特性開關可以調整應用的運用時狀態,灰度發布逐步的切換流量,微服務可以做到單個服務的獨立發布和部署.
4. 基礎設施技術
5. 藍綠部署
6. 金絲雀發布
7. 鳳凰環境
8. 不可變基礎設施

7.2 基于Jenkins的CD/DevOps生態系統

 

Jenkins是驅動整個持續交付和DevOps的核心組件.

8、DevOps 黃金思維圈

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

文章來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/3755.html