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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 138|回复: 0

Jenkins 创始人:持续交付的 What、Why 及 How

[复制链接]
发表于 2021-12-25 22:59:47 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-25 23:02 编辑
# \" y5 k3 o* ~) `- L( X5 U" M% H9 x6 s
整理的重点内容:

& D9 W( U" m8 s( C# i3 s
粘贴上传202112252249497105..png
6 I- m& L& A- g* F0 R0 i! W
1、流程线已经改变过一次世界
福特在引入流水线生产之后,Model-T 的组装时间缩短了8倍。1.3万名员工生产了30万量汽车,超过了300家竞争对手的总和,这就是效率的神话。
. V3 O! J' q4 y0 z
不过后来丰田超越了福特,在不确定性越来越突出的现在,单纯的效率已经不能满足企业的竞争,所以精益、敏捷、DevOps 才会出现,继续探索软件开发新模式、拓展效率和质量的新边疆。

; d' K5 X4 D* f7 Y3 `$ z' R
粘贴上传202112252250125346..png

' V8 {/ d. `  p" i
2、软件正在吞噬世界
- ~7 v6 g2 _- z; d
这个是共识,这是全人类的挑战和机遇,对我们从事工程效率和过程改进的人来说,不断改进软件交付的方式和效率,没有止境。
粘贴上传202112252250392192..png

1 a$ S+ y/ q. x
3、头号需求:业务连续性(不停机)
) n" C( z. ?& e/ t: _. }# M2 T. q
各大权威机构对 IT、DevOps、Continuous Delivery 的预测和评估。

0 ^; {% [7 @0 h' w( e! C; {
粘贴上传202112252251028347..png

7 p9 y% W6 f! g
我认为业务连续性也只是其中一项需求而已,整体上来讲,我们要解决的两个问题是:Build the things right and Build the right things。
4 t4 d3 ?& N) z
从 KK 的 PPT 里获取的信息是,他认为,持续交付和自动化是我们需要的答案之一。

- n! p, o' Z. J/ ]2 c
粘贴上传202112252251545129..png

, o2 H, H0 j1 j
4、持续交付框架分析
* ?, M" r1 \* }" V- Z
粘贴上传202112252252187919..png
0 m+ e. F8 k1 b) i( o+ Y
KK 的持续交付相关内容梳理的很清晰。这张图也可以说是 DevOps 的管理与工程实践框架。KK 也强调了 DevOps 是一组文化方法和技术实践。
# c6 O9 z  E+ \! l
) f) l* i- N7 h3 j" l+ k
维度:
; z  V" A3 t/ M* `1 E& N
  • 阶段:产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控2 f6 m1 \) ]7 H/ j
    其中的构建和编译、单元测试并列,不清楚这里的构建表示什么?我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出(高质量)可以部署和测试的软件包。4 p  ?9 \8 K4 J/ ~6 J. ^( Q
    另外,关于Place也没有找到对应的解释,有点像部署或者分发
  • 环境
  • 开发环境
  • 预发布环境(类生产环境)
  • 生产环境
    2 h7 [% t" B; `. `  i关键中缺少独立的测试环境,从图上的分布看,应该是包含在Development中的
  • 方法
  • 敏捷& u2 l3 t& M1 l0 B8 D9 \7 y6 x$ j. |
    「对特性进行识别、排序、调整的增量开发方法」。不太理解,敏捷的具体方法框架有很多,包括Scrum,XP,Kanban(准确的说属于精益方法)。还有 SAFe,Less 等规模化框架。
  • 持续集成
    # A& P" u7 o4 o8 s* `) b5 Y- i: [* x持续集成是持续交付的基础,持续交付是 DevOps 的核心工程实践。非常重要。
  • 持续交付
  • 持续部署另外,红色框的逻辑没有理解明白,有高手请指点。$ w+ E6 I  g  f& F

    8 K& b7 ~$ w1 ]$ C1 @; U
    . o8 `& L' c- V
5、生存还是毁灭,你可以选择
( V* @& L! Q3 g
每年的 State of DevOps Report 都会公布四个关键指标的数据:部署频率、周期时间、部署失败率、故障修复时间。高效能IT组织和低效能IT组织的差异非常大。KK的这两张图也非常形象的说明了这个问题。
# Q* M& U& n- M1 L; A" n+ I# A: t
粘贴上传202112252252473618..png
粘贴上传202112252253128404..png
6、现状和方向6.1 敏捷团队占比
9 L: ~, t% [! N2 ?
现状是上游敏捷(管理过程,比如Scrum)的团队占比33%,下游敏捷(持续交付)的团队占比13%。
这也符合国内的情况,很多团队刚开始做敏捷的时候都是从管理过程开始敏捷,大多从 Scrum 入手,但是效果一般都不尽如人意。
6 [9 }" U! ]3 K  D' Q
我认为持续集成和自动化测试是敏捷的两条腿,想要敏捷跑起来,此二者必须同时建设才能让敏捷体现其快速响应变化的价值。- ~( b* W4 ]! T) U) e$ Q4 Y
粘贴上传202112252253422276..png

2 I8 a: ~7 O" i5 }6 r$ Y& [, J6.2 非敏捷团队占比

4 h# X: d. u# A2 D
根据 KK 的数据,目前有87%的团队,依然没有实现下游的敏捷,即持续交付和持续部署的实施较少或者不成熟。这会导致价值的交付依然长达数月之久。1 {6 _' M7 b' M# }% O1 T1 B- n3 k
粘贴上传202112252253577050..png
1 ^6 S! O' ~& L: [5 `
6.3 成熟度级别
/ f6 Q8 ?8 f1 \5 X5 ]/ v+ Z' z) l
KK 将敏捷(CD、DevOps)的级别划分为团队级,跨团队级,企业级。这个和 DevOps 之父 Patrick 的 DevOps 5个精进级别颇为相似。
粘贴上传202112252254172085..png

3 k5 Q# p/ n  M. F  Z* V; o
企业级的敏捷和 DevOps 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。

& [: x: a- o/ E! h5 ~; [( m
编者:之前在参加敏捷培训时,老师提到诺西在敏捷方面做的很早也很深入,摩托做 CMMI 和 6 Sigma 也做的很好,但是这些企业现在都不在了。组织、战略、文化的敏捷至关重要。下边的人玩儿的很嗨,只是用正确的方法在做错误的事情而已。颇有感触!

* {$ ?& S  H7 L  o) }  Y0 B' W8 @8 H: q
6.3 改进四象限
1 j: O6 E. x; m+ ]/ i* [
KK 基于团队级、跨团队级、企业级以及上下游阶段,将改进方向划分为四个象限。
粘贴上传202112252254489690..png
3 a! z3 `' _1 F0 @3 Z" v4 v- C; l" r
粘贴上传202112252255031969..png
  c$ M6 D8 J2 D4 g$ }
6.4 改进路径与模式

/ @0 x. [4 ]) M
KK 基于四象限将改进划分为2条路径和2种模式
9 _/ @" b& @  O- l6 I; \# ?: U2 y  S
路径一:
从团队敏捷到企业级(组织级)敏捷,再到企业级 DevOps
粘贴上传202112252255263398..png
9 H0 |! m8 B, ]# w. {
路径二:
团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps& r. T2 b# B6 x: @5 t$ L$ x
/ N; |& Y7 K" p7 i9 f+ \
粘贴上传202112252255495956..png

* f5 d- |0 O, s' F. v8 r6 X7 C
我所了解的企业,偏向于类似第二种的路径,一开始都在团队级别进行敏捷和持续交付的尝试,逐渐成熟推广复用,规模化。' P! O# |' p1 q

- t5 ?% E' R% k3 f( d& c· 自下而上的改进
这种模式应该是比较常见
7 G5 J6 D9 |* h6 \
粘贴上传202112252256075822..png
/ w3 ?3 H( t0 `$ b! b+ o
· 自上而下的改进
粘贴上传202112252256234501..png
% ~% _! J: k& \3 v
DevOps转型策略

6 m, F0 d4 {- s* [4 x
KK给出了自己的建议:
粘贴上传202112252256415056..png

1 z- @7 F) k* f: x, M* I& V3 `" R0 j6 s
关于第4点,我个人一直不喜欢考核,尤其是KPI。我希望的是一种能将工程师导向良性行为的评估方式。但是KK提到的可度量,是一种可取的方式,可度量意味着可执行,有目标。
但是度量一定要慎之又慎。一句话:度量改变行为。
7、工程实践
粘贴上传202112252257071680..png

$ M/ _% i) M- F% D1 v
关于持续交付,KK重点强调了:A straightforward and repeatable deployment process is important for continuous delivery.
7 v8 n6 \* ~% q' ~$ f1 D9 `
7.1 架构与实现技术
  • 特性开关
  • 灰度发布
  • 微服务
    / x  F" Z# E  F3 \以上三个技术对发布和部署都有很大的提升,特性开关可以调整应用的运用时状态,灰度发布逐步的切换流量,微服务可以做到单个服务的独立发布和部署。
  • 基础设施技术
  • 蓝绿部署
  • 金丝雀发布
  • 凤凰环境
  • 不可变基础设施

    ' m7 u$ v# Q5 ^/ G8 p7 n% A% _' {2 U7 S
    ! \/ B  D5 h+ V" F: [! _) R
7.2 基于Jenkins的CD/DevOps生态系统
3 c# r" m# g$ Q
粘贴上传202112252257276723..png
3 u  P: @/ v# i& E" [
Jenkins是驱动整个持续交付和DevOps的核心组件。。
$ c& a# d# m+ h# L

+ d- m- j  h* ?6 {* F6 g
粘贴上传202112252257517075..png

# X" a% T3 D8 _+ f. g
8、DevOps 黄金思维圈
& v# E! E) h4 m/ _
以上就是我在研读 KK 的 PPT 过程中的思考和记录,没到现场,所以感觉很零散。恰好最近刚接触一个概念:黄金思维圈,如下图所示:

9 g. Q# ]7 f  v1 }$ r
粘贴上传202112252258146829..png
9 ]$ {, d3 v3 R* i! e
黄金思维圈帮助我们认知世界,当然也可以帮助我们认知持续交付,尝试分析了一下:
- U2 i- W- [9 b6 N* z# d( T
Why:) _# }) W' y! m
持续且快速、可靠的自动交付软件给用户:
粘贴上传202112252258345269..png

+ |6 F2 J. g- g6 P2 a% a
How:
" J+ k7 p/ N& ~0 d$ A  R: }' B建设自动化、可重复、可靠的持续交付流水线(IT服务供应链)- U& G: [5 c5 d4 m2 d
主要包括代码管理、持续集成、自动化测试、自动化部署、基础设施自动化管理等方面的工程能力。

7 ?/ _: Q+ g: n, L6 w( h$ q. x
What:
粘贴上传202112252258597917..png
3 l, G2 K5 s* Z
(转自景韵)
/ ?1 x5 ]- d% O. E1 i4 h3 J% V. g% ], d

) L* A  z5 i/ a6 ~/ b0 P+ r

. ], a) ~) o9 o- X- V, f( o7 F% c
0 V' T) x  d) _" R




上一篇:【运维知识体系】运维人必备技能图谱
下一篇:中小企业 DevOps 从 0 到 1
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 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 19:12 , Processed in 0.164593 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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