请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 99|回复: 0

Jenkins 创始人谈DevOps与持续交付

[复制链接]
发表于 2021-12-19 16:25:22 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-20 20:26 编辑 6 c# `: |& |4 w% J2 s5 F
. l7 Y$ ^3 F2 [( \0 d
Jenkins创始人Kohsuke Kawaguchi(KK)于2004年开发了 Jenkins 项目的前身(Hudson),一开始就是为了解决他自己的关于自动化的需求。他自己也没想到15年后,Jenkins 成了软件交付过程中的核心工具,驱动着千万企业的持续交付与 DevOps 过程。
/ k( @' q1 o2 a
* o) f# n( d- o. A, J. \6 F6 ?
重点内容:
1. 持续交付框架分析
/ Z+ g) A- X2 D/ g7 E& l9 y2. 敏捷/持续交付/DevOps成熟度现状、级别划定、改进四象限与路线图等
! U7 ?3 X9 x, c$ @8 n: U  m( i3. DevOps转型策略) s' P  u0 w. U' [
4. 工程实践简介8 t+ o0 b* I( N1 c2 w8 y  l
5. 持续交付的黄金思维圈
* B, z  `, U9 t; N

* J2 v( N5 v8 U2 W6 o2 ~9 z1、流程线已经改变过一次世界
福特在引入流水线生产之后,Model-T 的组装时间缩短了8倍。1.3万名员工生产了30万量汽车,超过了300家竞争对手的总和,这就是效率的神话。
不过后来丰田超越了福特,在不确定性越来越突出的现在,单纯的效率已经不能满足企业的竞争,所以精益、敏捷、DevOps 才会出现,继续探索软件开发新模式、拓展效率和质量的新边疆。
粘贴上传202112191608146245..png
2、软件正在吞噬世界
这个是共识,这是全人类的挑战和机遇,对我们从事工程效率和过程改进的人来说,不断改进软件交付的方式和效率,没有止境。

8 {% H4 n  w) \0 u. \
粘贴上传202112191609418962..png
3、头号需求:业务连续性(不停机)
各大权威机构对 IT、DevOps、Continuous Delivery 的预测和评估。
粘贴上传202112191610284066..png

- n) D9 A: P) [( H3 y* l2 w! h2 D5 K- b1 G: R
认为业务连续性也只是其中一项需求而已,整体上来讲,我们要解决的两个问题是:Build the things right and Build the right things。
从 KK 的 PPT 里获取的信息是,他认为,持续交付和自动化是我们需要的答案之一。
粘贴上传202112191610505179..png
4、持续交付框架分析
粘贴上传202112191611175934..png

+ L. Q( F/ j' L

; O( r& [& O+ X% w( H' \- U3 ]
- K% A, L# V* E5 p' ?- R( d
KK 的持续交付相关内容梳理的很清晰。这张图也可以说是 DevOps 的管理与工程实践框架。KK 也强调了 DevOps 是一组文化方法和技术实践。0 \2 }3 `( l$ I. G8 X* N: @' w

& l5 c' o3 R' j4 I: A: W$ o
维度:
  • 阶段:产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控+ R" y) M- N3 \
    其中的构建和编译、单元测试并列,不清楚这里的构建表示什么?我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出(高质量)可以部署和测试的软件包。3 @# V5 H. U% {* z; m" Y; j
    另外,关于Place也没有找到对应的解释,有点像部署或者分发
  • 环境
  • 开发环境
  • 预发布环境(类生产环境)
  • 生产环境
    8 y0 s  q1 a# }& W+ y" Q, v$ |. p关键中缺少独立的测试环境,从图上的分布看,应该是包含在Development中的
  • 方法
  • 敏捷! l9 ~7 H7 G: q' u) P0 W2 }! T/ O- d3 q
    「对特性进行识别、排序、调整的增量开发方法」。不太理解,敏捷的具体方法框架有很多,包括Scrum,XP,Kanban(准确的说属于精益方法)。还有 SAFe,Less 等规模化框架。
  • 持续集成
    ( ~& X5 ]: a: ]- k* T; F持续集成是持续交付的基础,持续交付是 DevOps 的核心工程实践。非常重要。
  • 持续交付
  • 持续部署另外,红色框的逻辑没有理解明白,有高手请指点。
    1 P+ o7 L* D8 @* b5 l$ `9 C6 X+ g
7 B" x& g: I- q) Z
5、生存还是毁灭,你可以选择
; a/ `0 A) l2 ~/ n( W* h% E: [
每年的 State of DevOps Report 都会公布四个关键指标的数据:部署频率、周期时间、部署失败率、故障修复时间。高效能IT组织和低效能IT组织的差异非常大。KK的这两张图也非常形象的说明了这个问题。
粘贴上传202112191611452547..png
6、现状和方向
& v! a5 ~& [! T" j8 T& ]

( D$ y0 m; I  q, k
6.1 敏捷团队占比

6 r, y+ p2 P6 I& V$ f0 l' L  F
现状是上游敏捷(管理过程,比如Scrum)的团队占比33%,下游敏捷(持续交付)的团队占比13%。
这也符合国内的情况,很多团队刚开始做敏捷的时候都是从管理过程开始敏捷,大多从 Scrum 入手,但是效果一般都不尽如人意。
我认为持续集成和自动化测试是敏捷的两条腿,想要敏捷跑起来,此二者必须同时建设才能让敏捷体现其快速响应变化的价值。
粘贴上传202112191612289963..png
6.2 非敏捷团队占比
1 I0 }9 N  }, s4 I1 u7 S! s
根据 KK 的数据,目前有87%的团队,依然没有实现下游的敏捷,即持续交付和持续部署的实施较少或者不成熟。这会导致价值的交付依然长达数月之久。
粘贴上传202112191612557018..png
6.3 成熟度级别

% @, }. b; [3 L% N
KK 将敏捷(CD、DevOps)的级别划分为团队级,跨团队级,企业级。这个和 DevOps 之父 Patrick 的 DevOps 5个精进级别颇为相似。
粘贴上传202112191613175250..png
企业级的敏捷和 DevOps 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。

1 _( t% @/ o& Q% d2 L+ g% g
6.4 改进四象限

+ C' _! I4 P- R( K
KK 基于团队级、跨团队级、企业级以及上下游阶段,将改进方向划分为四个象限。
" L: |' \1 Z- O! Q
粘贴上传202112191613472411..png
$ W8 h# a# J+ z- @% R/ V& ~; E1 c

5 @5 A7 w. m# u. Q3 e) `& Y/ p
: D3 G4 O0 f3 U- x
1. 团队级的敏捷
0 P: I1 Z9 D5 ^! Z5 s
6 C2 k- A% R7 T; ]
2. 团队级的CD
& ]( C4 T; D* A  A% s! Z9 Q7 D
3. 企业级的敏捷
8 X! l0 O& w4 w% r0 T; U
4. 企业级的DevOps(我相信2017和2018年,国内企业一定会迈进企业级的DevOps转型和落地)

$ }( q) i+ b3 l' M1 C5 j. |
) z8 ?* t( c0 P6 M& ^, S
6.5 改进路径与模式

. c$ m  ~4 n- L- n8 b( z3 G
KK 基于四象限将改进划分为2条路径和2种模式
6 S/ e; q# h0 W& {) |5 g
路径一:
3 o8 W5 g4 M+ t* ^
从团队敏捷到企业级(组织级)敏捷,再到企业级 DevOps
粘贴上传202112191615253345..png
& t" s) j/ }9 H) h/ z3 a/ G0 l2 x: x
2 q1 [; v5 i8 M" e8 E/ n

4 U6 h3 v4 L, s( ?* h, \
" f" r; K( K, S6 J4 d- e
路径二:
团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps
粘贴上传202112191615474915..png
我所了解的企业,偏向于类似第二种的路径,一开始都在团队级别进行敏捷和持续交付的尝试,逐渐成熟推广复用,规模化。
/ h9 e3 Q+ ]- |1 f/ W1 z  x
· 自下而上的改进
这种模式应该是比较常见
粘贴上传202112191616182204..png
· 自上而下的改进
粘贴上传202112191616442537..png
  n2 T- G& P2 }7 Q2 ^
6.6 DevOps转型策略KK给出了自己的建议:
1. 识别试点项目
  Q  ]# J5 f5 w% ]  F5 I# {2. 组建跨职能团队
# L; r  T1 S) I9 b2 S+ }" Y+ A, X1 J3. 采用统一的技术
, w# |8 z3 b% o: a4. 基于可度量的KPI和里程碑制定计划# r1 @. j7 o8 }6 r4 p8 m
5. Go
- f* {' H( B/ E6. 度量,文档化,改进( Z- F* u3 O+ U* S
7. 规模化实践

2 R  c/ ~3 p- m$ `
关于第4点,我个人一直不喜欢考核,尤其是KPI。我希望的是一种能将工程师导向良性行为的评估方式。但是KK提到的可度量,是一种可取的方式,可度量意味着可执行,有目标。
但是度量一定要慎之又慎。一句话:度量改变行为。
7、工程实践
/ P& f! b& Q7 \+ S$ Q
粘贴上传202112191618472855..png
' q! T4 L" ^( V; I: z3 q/ w; N7 m: m/ w! k
# v- n) D* E- b; Q, ?! W: U
关于持续交付,KK重点强调了:A straightforward and repeatable deployment process is important for continuous delivery.
$ Z' b$ S/ r  Z# v
7.1 架构与实现技术
  • 特性开关
  • 灰度发布
  • 微服务
    6 U/ m! a3 ?3 c5 \! V以上三个技术对发布和部署都有很大的提升,特性开关可以调整应用的运用时状态,灰度发布逐步的切换流量,微服务可以做到单个服务的独立发布和部署。
  • 基础设施技术
  • 蓝绿部署
  • 金丝雀发布
  • 凤凰环境
  • 不可变基础设施

    # V$ C  r+ r8 m2 z
7.2 基于Jenkins的CD/DevOps生态系统
. a3 P* G9 r" `1 A% J5 M$ ]2 s
粘贴上传202112191619154620..png
0 b3 m' S$ L, f0 i' q
Jenkins是驱动整个持续交付和DevOps的核心组件。

: s3 a! v' @, b$ t% b- c  `, e9 j/ k3 G0 d
粘贴上传202112191619356444..png
' l1 S. v1 b, w/ h$ b+ y

0 {  k7 t& M# C) v: s/ J
8、DevOps 黄金思维圈
以上就是我在研读 KK 的 PPT 过程中的思考和记录,没到现场,所以感觉很零散。恰好最近刚接触一个概念:黄金思维圈,如下图所示:
粘贴上传202112191619554339..png
黄金思维圈帮助我们认知世界,当然也可以帮助我们认知持续交付,尝试分析了一下:
Why:
0 @  z/ P3 c1 s0 j) f持续且快速、可靠的自动交付软件给用户:
[size=0.85em]1. 实现价值的持续交付,赢得市场竞争
/ A; ~# X1 @  e$ @6 T* I2. 提升研发(增值活动)的时间,极大化增值活动产出
How:
( K+ {" M: j5 Y/ e3 y1 {建设自动化、可重复、可靠的持续交付流水线(IT服务供应链)$ ~; E; Y: s( w4 b) o! E
主要包括代码管理、持续集成、自动化测试、自动化部署、基础设施自动化管理等方面的工程能力。
What:
1. 每次代码提交都需要经过流水线验证
2 b% B+ F& A2 N  O, I6 s
2. 每次部署的版本都经过多环境验证
7 X2 v* ^$ s; r# a$ p9 i! {
3. 部署频率可以得到提升

( n; @' x7 Y4 w: e# \5 r4 f2 f, c
4. 周期时间(从代码提交到部署上线)的时间可以到分钟级
5 `5 e2 Q9 [: h; ~+ J: }8 d) }
5. 部署失败率低
( l0 g+ I3 s1 {" q' t9 b
6. 部署失败的修复时间短,影响小

3 r; k' \6 ~6 B+ i
4 M1 _- A" N2 K7 d0 e2 ?4 K- |! X
(转自DevOps持续交付)
! Z; L6 Z, e0 U. t. B( L* Y+ {# m; d" U( q, D
粘贴上传202112191610107822..png




上一篇:陈飞老师《DevOps溯源》21年11月3日晚八点直播!艾拓先锋专家微课堂第426期!
下一篇:华为质量流程IT总裁陶景文:任何不涉及流程重构的数字化转型,都是在装样子 | IDCF
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 18:09 , Processed in 0.107384 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表