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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 609|回复: 0

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

[复制链接]
发表于 2021-12-25 22:59:47 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-25 23:02 编辑
; @* r0 F( c: o9 z' G5 W* {0 ^! B! W6 ~+ }/ }8 `# y5 A8 W
整理的重点内容:

2 Z4 X0 ?) x; E0 o
粘贴上传202112252249497105..png

  W$ O. q- i, c- P
1、流程线已经改变过一次世界
福特在引入流水线生产之后,Model-T 的组装时间缩短了8倍。1.3万名员工生产了30万量汽车,超过了300家竞争对手的总和,这就是效率的神话。

' a2 }: ~$ @7 Q* Q
不过后来丰田超越了福特,在不确定性越来越突出的现在,单纯的效率已经不能满足企业的竞争,所以精益、敏捷、DevOps 才会出现,继续探索软件开发新模式、拓展效率和质量的新边疆。
  ?2 ~, H) a( R7 `' d6 W
粘贴上传202112252250125346..png

  }, D0 ^" P) T2 B; X8 J, ?' V
2、软件正在吞噬世界5 S9 {! b( u( }# x* E0 \
这个是共识,这是全人类的挑战和机遇,对我们从事工程效率和过程改进的人来说,不断改进软件交付的方式和效率,没有止境。
粘贴上传202112252250392192..png
% |6 g# D# X: _
3、头号需求:业务连续性(不停机)
- {+ |$ t% L  n4 [  K
各大权威机构对 IT、DevOps、Continuous Delivery 的预测和评估。

; \$ D" U* C) L/ w
粘贴上传202112252251028347..png

* z  E" v" [: q: x, M6 j
我认为业务连续性也只是其中一项需求而已,整体上来讲,我们要解决的两个问题是:Build the things right and Build the right things。
/ {" k7 W* i  e; \
从 KK 的 PPT 里获取的信息是,他认为,持续交付和自动化是我们需要的答案之一。
! x+ L6 |. k, C
粘贴上传202112252251545129..png

6 f9 {+ a' A1 C  V8 a% k
4、持续交付框架分析
" E: ]: ~* s$ s7 l% |! f
粘贴上传202112252252187919..png

) Q. M0 ^! e* O- b9 Z' w8 d
KK 的持续交付相关内容梳理的很清晰。这张图也可以说是 DevOps 的管理与工程实践框架。KK 也强调了 DevOps 是一组文化方法和技术实践。! r+ O5 R) k& e' w' c7 m

5 v  M2 r, |) h* X3 l# W
维度:
' r" F2 g9 Q& r2 \: x0 _5 ]
  • 阶段:产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控
    2 S5 `# O9 i7 z" a1 w+ G其中的构建和编译、单元测试并列,不清楚这里的构建表示什么?我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出(高质量)可以部署和测试的软件包。4 B. s* C  s# P  V# U
    另外,关于Place也没有找到对应的解释,有点像部署或者分发
  • 环境
  • 开发环境
  • 预发布环境(类生产环境)
  • 生产环境
    % \! p: P0 K; s: a关键中缺少独立的测试环境,从图上的分布看,应该是包含在Development中的
  • 方法
  • 敏捷
    ! |9 ]2 _& m. K; N- |「对特性进行识别、排序、调整的增量开发方法」。不太理解,敏捷的具体方法框架有很多,包括Scrum,XP,Kanban(准确的说属于精益方法)。还有 SAFe,Less 等规模化框架。
  • 持续集成
    * d6 z$ ?7 J! ^& J& ^持续集成是持续交付的基础,持续交付是 DevOps 的核心工程实践。非常重要。
  • 持续交付
  • 持续部署另外,红色框的逻辑没有理解明白,有高手请指点。8 x4 }+ g( ^% \2 `) ]! o9 @8 G" ]: w

    9 s8 M9 s( F) F2 \8 r1 R
    ' n5 v+ w$ P" {5 ]# U
5、生存还是毁灭,你可以选择
1 @8 V1 W. v0 e2 @. d
每年的 State of DevOps Report 都会公布四个关键指标的数据:部署频率、周期时间、部署失败率、故障修复时间。高效能IT组织和低效能IT组织的差异非常大。KK的这两张图也非常形象的说明了这个问题。

  G8 {, z6 S* s: ]2 L- E9 y$ b( C
粘贴上传202112252252473618..png
粘贴上传202112252253128404..png
6、现状和方向6.1 敏捷团队占比
7 ]/ \$ X& S0 \* s0 J! G, U
现状是上游敏捷(管理过程,比如Scrum)的团队占比33%,下游敏捷(持续交付)的团队占比13%。
这也符合国内的情况,很多团队刚开始做敏捷的时候都是从管理过程开始敏捷,大多从 Scrum 入手,但是效果一般都不尽如人意。
$ ^3 m: e0 Y2 k& o, t/ Y8 M- e/ k* I
我认为持续集成和自动化测试是敏捷的两条腿,想要敏捷跑起来,此二者必须同时建设才能让敏捷体现其快速响应变化的价值。6 V5 \4 a7 s* v5 G& b6 Z
粘贴上传202112252253422276..png
1 F8 F6 O# Y% f* z& ~
6.2 非敏捷团队占比
0 ]" W# n) X1 m' ?2 S
根据 KK 的数据,目前有87%的团队,依然没有实现下游的敏捷,即持续交付和持续部署的实施较少或者不成熟。这会导致价值的交付依然长达数月之久。9 v3 _. A$ u4 |  C8 P
粘贴上传202112252253577050..png
6 ^) q8 v! b8 m7 ~1 n. \
6.3 成熟度级别

8 K4 F+ i# b: t; {+ Z4 J) o& [5 {5 f
KK 将敏捷(CD、DevOps)的级别划分为团队级,跨团队级,企业级。这个和 DevOps 之父 Patrick 的 DevOps 5个精进级别颇为相似。
粘贴上传202112252254172085..png
) X- z5 v9 c* j1 I3 q- F
企业级的敏捷和 DevOps 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。

, G! }$ y( m3 r" V. _! t; {( H
编者:之前在参加敏捷培训时,老师提到诺西在敏捷方面做的很早也很深入,摩托做 CMMI 和 6 Sigma 也做的很好,但是这些企业现在都不在了。组织、战略、文化的敏捷至关重要。下边的人玩儿的很嗨,只是用正确的方法在做错误的事情而已。颇有感触!
) o) i" e1 w# y& p! O1 x. I6 p
6.3 改进四象限

3 ^1 H* l/ q" w1 Z9 J* x& K2 a6 D
KK 基于团队级、跨团队级、企业级以及上下游阶段,将改进方向划分为四个象限。
粘贴上传202112252254489690..png
8 w. W' e# k1 C5 s8 x# E
粘贴上传202112252255031969..png

* e1 [5 |1 d" Z* r6.4 改进路径与模式
) F4 `( E* p! I6 Z6 }0 i
KK 基于四象限将改进划分为2条路径和2种模式
+ e  _' W" L% s
路径一:
从团队敏捷到企业级(组织级)敏捷,再到企业级 DevOps
粘贴上传202112252255263398..png

3 r! @) t$ C* ?* c6 c4 I9 m路径二:
团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps
7 q5 x, a$ [  n0 e' N! P: D

3 V! F; K: T6 J: W- o
粘贴上传202112252255495956..png
" h' j6 G1 a7 o& E9 F
我所了解的企业,偏向于类似第二种的路径,一开始都在团队级别进行敏捷和持续交付的尝试,逐渐成熟推广复用,规模化。/ \6 |: r) O( K1 H0 q4 G
3 G. H5 R% h4 H! p
· 自下而上的改进
这种模式应该是比较常见" z, U: k3 x9 e9 k5 E: @
粘贴上传202112252256075822..png

. N7 r4 ^% }% n· 自上而下的改进
粘贴上传202112252256234501..png
& E  f  q) |% q+ a
DevOps转型策略
6 E# d2 ~/ O8 B' Y/ t7 A4 {4 N
KK给出了自己的建议:
粘贴上传202112252256415056..png
1 K0 l9 P; z4 a4 P0 V8 \+ N
关于第4点,我个人一直不喜欢考核,尤其是KPI。我希望的是一种能将工程师导向良性行为的评估方式。但是KK提到的可度量,是一种可取的方式,可度量意味着可执行,有目标。
但是度量一定要慎之又慎。一句话:度量改变行为。
7、工程实践
粘贴上传202112252257071680..png

5 O  q; Q5 `8 H: R9 e
关于持续交付,KK重点强调了:A straightforward and repeatable deployment process is important for continuous delivery.
2 u, k! E/ I$ G5 a; X  f
7.1 架构与实现技术
  • 特性开关
  • 灰度发布
  • 微服务
    ; O. {) H0 K% f' a/ A3 O% }以上三个技术对发布和部署都有很大的提升,特性开关可以调整应用的运用时状态,灰度发布逐步的切换流量,微服务可以做到单个服务的独立发布和部署。
  • 基础设施技术
  • 蓝绿部署
  • 金丝雀发布
  • 凤凰环境
  • 不可变基础设施

    , u% C0 S& h; U
    1 y* r6 t+ x/ e" @5 A1 a3 z+ U
7.2 基于Jenkins的CD/DevOps生态系统
( b* ~/ l# e3 R1 `+ Z
粘贴上传202112252257276723..png

+ ?0 w  S# K" UJenkins是驱动整个持续交付和DevOps的核心组件。。
. k- G! P! X) a# n2 t
/ @% ~* k' K! M# f1 a% B
粘贴上传202112252257517075..png
! z- t6 i4 G$ ]- Y
8、DevOps 黄金思维圈

0 `1 I0 C) x4 j5 h
以上就是我在研读 KK 的 PPT 过程中的思考和记录,没到现场,所以感觉很零散。恰好最近刚接触一个概念:黄金思维圈,如下图所示:

+ k6 y0 V1 v  \9 H$ j
粘贴上传202112252258146829..png
7 |8 n; T9 k+ s7 v( i% V0 b
黄金思维圈帮助我们认知世界,当然也可以帮助我们认知持续交付,尝试分析了一下:

2 @7 j$ {0 k: S# K5 Z
Why:
3 p' X# {0 q" I. V5 b: N持续且快速、可靠的自动交付软件给用户:
粘贴上传202112252258345269..png
7 l, [# P; c0 W# b5 z6 L
How:+ c7 h" v, _1 G1 [  p4 l' {
建设自动化、可重复、可靠的持续交付流水线(IT服务供应链), U: K; X$ h& A0 x
主要包括代码管理、持续集成、自动化测试、自动化部署、基础设施自动化管理等方面的工程能力。
+ l4 j5 X& l0 V$ c% B
What:
粘贴上传202112252258597917..png

+ _) D9 ?. K5 |/ w% c/ b(转自景韵)
1 f. L: J5 [0 L! p/ R3 g/ i
5 T' z" E5 G- s4 E/ l
% ~. E0 D9 ?1 }- O
9 k' f4 [/ j2 B+ @: S+ `2 d/ G
3 r- I+ ~8 d2 E' y2 [$ \




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2022-8-17 09:34 , Processed in 0.101919 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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