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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 668|回复: 0

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

[复制链接]
发表于 2021-12-25 22:59:47 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-25 23:02 编辑 1 Z, j- T' ?% ^
- z; [& x; E: W9 ?. L1 l7 E
整理的重点内容:
6 n$ X9 \4 y5 O# e0 m) g' {1 i
粘贴上传202112252249497105..png

2 n* {* u+ X: ~; p
1、流程线已经改变过一次世界
福特在引入流水线生产之后,Model-T 的组装时间缩短了8倍。1.3万名员工生产了30万量汽车,超过了300家竞争对手的总和,这就是效率的神话。

7 K+ l0 u7 A0 V) L* A
不过后来丰田超越了福特,在不确定性越来越突出的现在,单纯的效率已经不能满足企业的竞争,所以精益、敏捷、DevOps 才会出现,继续探索软件开发新模式、拓展效率和质量的新边疆。

6 F3 {" U# _4 I4 g. R
粘贴上传202112252250125346..png
7 N: u. M, B, H6 m5 Q: e& Y) S
2、软件正在吞噬世界1 ]/ c% [; b. d( B. K
这个是共识,这是全人类的挑战和机遇,对我们从事工程效率和过程改进的人来说,不断改进软件交付的方式和效率,没有止境。
粘贴上传202112252250392192..png
9 ~: I; T7 F6 f9 W1 X3 j
3、头号需求:业务连续性(不停机)
- G4 v6 I# V% u) L
各大权威机构对 IT、DevOps、Continuous Delivery 的预测和评估。
- i1 z! S+ N$ N$ e/ X
粘贴上传202112252251028347..png
) X' _0 d% E* A& x) {* W
我认为业务连续性也只是其中一项需求而已,整体上来讲,我们要解决的两个问题是:Build the things right and Build the right things。
0 B; m: D  w. v% @6 \
从 KK 的 PPT 里获取的信息是,他认为,持续交付和自动化是我们需要的答案之一。
9 A0 n- T5 I8 s& f' h
粘贴上传202112252251545129..png
3 }9 ]/ @4 N$ O( W# P
4、持续交付框架分析
  c% v) S4 K. h0 L6 L( a) s& r
粘贴上传202112252252187919..png
+ Q* k# M+ A8 Z
KK 的持续交付相关内容梳理的很清晰。这张图也可以说是 DevOps 的管理与工程实践框架。KK 也强调了 DevOps 是一组文化方法和技术实践。- {; I7 k9 z/ f" H- B$ Q' C

- w8 ~* ]8 k) @
维度:
$ i9 D6 w- |7 [, G1 U2 t; O
  • 阶段:产品定义、计划、编码、编译、构建、单元测试、分析、集成、集成测试、打包、Place、压力测试、验收测试、发布、部署、监控- e  _( a' t- j& {; I
    其中的构建和编译、单元测试并列,不清楚这里的构建表示什么?我理解的构建时编译、打包、或者在加上单元测试、代码分析的整体。自动化构建的目标就是要输出(高质量)可以部署和测试的软件包。
    6 ~1 T1 ]" V/ N9 f: F) `另外,关于Place也没有找到对应的解释,有点像部署或者分发
  • 环境
  • 开发环境
  • 预发布环境(类生产环境)
  • 生产环境
    & Y7 G2 B' ?' B6 a2 q7 c关键中缺少独立的测试环境,从图上的分布看,应该是包含在Development中的
  • 方法
  • 敏捷2 s7 L, H7 |) @; G! Z
    「对特性进行识别、排序、调整的增量开发方法」。不太理解,敏捷的具体方法框架有很多,包括Scrum,XP,Kanban(准确的说属于精益方法)。还有 SAFe,Less 等规模化框架。
  • 持续集成
    8 M/ \; |5 m% |& h/ G$ {/ T持续集成是持续交付的基础,持续交付是 DevOps 的核心工程实践。非常重要。
  • 持续交付
  • 持续部署另外,红色框的逻辑没有理解明白,有高手请指点。% o8 o( C! w; u% D( k* T

    : f1 l; q4 b" s1 A

    ! L* Y1 H* b2 p; ~
5、生存还是毁灭,你可以选择
) c4 u5 M% Y- v+ P' e) m
每年的 State of DevOps Report 都会公布四个关键指标的数据:部署频率、周期时间、部署失败率、故障修复时间。高效能IT组织和低效能IT组织的差异非常大。KK的这两张图也非常形象的说明了这个问题。
5 l* B+ ?9 P3 ^! u
粘贴上传202112252252473618..png
粘贴上传202112252253128404..png
6、现状和方向6.1 敏捷团队占比$ r2 B' O0 Q7 Q2 N) _* o; s
现状是上游敏捷(管理过程,比如Scrum)的团队占比33%,下游敏捷(持续交付)的团队占比13%。
这也符合国内的情况,很多团队刚开始做敏捷的时候都是从管理过程开始敏捷,大多从 Scrum 入手,但是效果一般都不尽如人意。
9 M8 h. r) U( ?: M) k" B3 Y
我认为持续集成和自动化测试是敏捷的两条腿,想要敏捷跑起来,此二者必须同时建设才能让敏捷体现其快速响应变化的价值。
% W% V# |6 ?+ h) M; |; ?+ ^
粘贴上传202112252253422276..png
  V8 u) K8 J- ~+ r# L
6.2 非敏捷团队占比

6 J! j. f! S# N" V# B* K
根据 KK 的数据,目前有87%的团队,依然没有实现下游的敏捷,即持续交付和持续部署的实施较少或者不成熟。这会导致价值的交付依然长达数月之久。6 q% w: D3 i5 o* c' o
粘贴上传202112252253577050..png

0 Y  U! {6 v# d( Z4 x5 [+ S6.3 成熟度级别
  s& u4 E9 P; {1 o* H
KK 将敏捷(CD、DevOps)的级别划分为团队级,跨团队级,企业级。这个和 DevOps 之父 Patrick 的 DevOps 5个精进级别颇为相似。
粘贴上传202112252254172085..png

0 c0 ~  r, z" W+ L7 L
企业级的敏捷和 DevOps 还有很长的路要走。企业级的改进需要组织、文化都要共同变化。
" ~& ?% R+ X% {
编者:之前在参加敏捷培训时,老师提到诺西在敏捷方面做的很早也很深入,摩托做 CMMI 和 6 Sigma 也做的很好,但是这些企业现在都不在了。组织、战略、文化的敏捷至关重要。下边的人玩儿的很嗨,只是用正确的方法在做错误的事情而已。颇有感触!

1 W* h" J5 p( g+ H" u7 ?  l
6.3 改进四象限

3 f% L/ s) t+ C/ R6 v
KK 基于团队级、跨团队级、企业级以及上下游阶段,将改进方向划分为四个象限。
粘贴上传202112252254489690..png

# l6 T2 s; l2 G2 Q7 U" g3 e3 t
粘贴上传202112252255031969..png
+ l0 E8 }- |$ }9 u3 N; u2 v
6.4 改进路径与模式

+ o+ n5 r% v9 Q& z1 q3 U% D: S, d. z
KK 基于四象限将改进划分为2条路径和2种模式
" O+ V" E. V, R0 q) L
路径一:
从团队敏捷到企业级(组织级)敏捷,再到企业级 DevOps
粘贴上传202112252255263398..png
# k$ m& r5 ]# N3 Y
路径二:
团队级敏捷—>团队级持续交付—>企业级敏捷—>企业级 DevOps+ u& t" w) F7 m# h! N8 U
# J- _7 z9 l" f- Z6 ^+ o
粘贴上传202112252255495956..png
; S+ ~5 F0 x  O1 d  P- I
我所了解的企业,偏向于类似第二种的路径,一开始都在团队级别进行敏捷和持续交付的尝试,逐渐成熟推广复用,规模化。
2 A& L6 j& G8 ]

: S7 @- f- o5 H0 j( M0 l% S· 自下而上的改进
这种模式应该是比较常见
5 u8 U9 V( e9 @
粘贴上传202112252256075822..png

! k0 f6 R% M; Q4 Q· 自上而下的改进
粘贴上传202112252256234501..png

6 A; G- F: R  n7 L2 B# S( {( HDevOps转型策略
3 I% z) l/ B) p6 }
KK给出了自己的建议:
粘贴上传202112252256415056..png

5 J( u+ c5 g& g9 Q
关于第4点,我个人一直不喜欢考核,尤其是KPI。我希望的是一种能将工程师导向良性行为的评估方式。但是KK提到的可度量,是一种可取的方式,可度量意味着可执行,有目标。
但是度量一定要慎之又慎。一句话:度量改变行为。
7、工程实践
粘贴上传202112252257071680..png

- [8 K6 `0 G7 t# `
关于持续交付,KK重点强调了:A straightforward and repeatable deployment process is important for continuous delivery.7 D( n, E) o/ G+ d* l2 D. N
7.1 架构与实现技术
  • 特性开关
  • 灰度发布
  • 微服务% G/ t" n% I9 N& }6 F' S" r0 p- O! R
    以上三个技术对发布和部署都有很大的提升,特性开关可以调整应用的运用时状态,灰度发布逐步的切换流量,微服务可以做到单个服务的独立发布和部署。
  • 基础设施技术
  • 蓝绿部署
  • 金丝雀发布
  • 凤凰环境
  • 不可变基础设施
    ; @" o, D; |9 V7 ^7 C! C; S/ G6 C; A! U

    5 t& d" j. P0 F) T9 N( ]
7.2 基于Jenkins的CD/DevOps生态系统3 z$ n% O9 e; C5 m
粘贴上传202112252257276723..png

7 k2 V# y! \8 V! KJenkins是驱动整个持续交付和DevOps的核心组件。。
! G3 f% i8 M' z. d! F# J- L
* i. Q- s6 G% K! K& z2 A
粘贴上传202112252257517075..png
( V/ m0 \1 K4 n$ `: U" ?0 h. B( P
8、DevOps 黄金思维圈

0 p- i: n) U0 \& G1 `
以上就是我在研读 KK 的 PPT 过程中的思考和记录,没到现场,所以感觉很零散。恰好最近刚接触一个概念:黄金思维圈,如下图所示:

4 b% W0 e) Z9 n/ `6 x2 F4 J$ S
粘贴上传202112252258146829..png
8 W0 F9 T* n- w$ r6 |
黄金思维圈帮助我们认知世界,当然也可以帮助我们认知持续交付,尝试分析了一下:
5 p$ H2 t0 c! X  o
Why:- }" ^- b2 V* V" s% z: J9 P
持续且快速、可靠的自动交付软件给用户:
粘贴上传202112252258345269..png

" }7 `) \! h/ g; Q1 j
How:
+ }! O' i5 r6 e建设自动化、可重复、可靠的持续交付流水线(IT服务供应链)
, B2 Q, m) o' E9 C. a0 j主要包括代码管理、持续集成、自动化测试、自动化部署、基础设施自动化管理等方面的工程能力。
- M4 v% y6 r: G& w5 _
What:
粘贴上传202112252258597917..png

1 l" p6 G- b  C' S(转自景韵); a. U% ~9 B  C$ V! x/ X

. q3 N8 I) I0 [1 B" J
! n7 Z  c# L  v  ~7 o& F8 l9 j+ b4 F2 V

& u& y9 [! S# h$ M! T( \
6 K- p. P6 Y, r* C# b




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

本版积分规则

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

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

GMT+8, 2022-10-4 13:57 , Processed in 0.103472 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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