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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1577|回复: 0

了解「持续交付」和「DevOps」的前世今生

[复制链接]
发表于 2018-10-19 11:02:45 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-10-19 11:12 编辑 , b2 I5 p6 Q9 V+ _

* O' N/ ^( M0 O2 o; y
; O0 n4 i8 \3 E
这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! 「敏捷软件开发」,「增长黑客」,「持续集成」,「ITILxf.com" target="_blank" class="relatedlink">DevOps」,「精益创业」,「持续交付」,「大数据」... ...
1 {; i/ q$ U6 n  P, n
/ y) B% X6 F) S  J3 q
7 O: b% R0 X8 |; ?2 K" S
OK,就这四个啦:
+ @, K1 ^0 d5 m
$ e7 \( l3 a$ T- v7 S
「敏捷软件开发」,「持续集成」,「DevOps」,「持续交付」,
9 F$ J3 B8 z: I' Z/ C) A, R

( g% b" Y% A1 L* ~( a6 J

/ J* Y5 o2 u; }% w5 s& \
先让我们在 Wikipedia 上验明正身。

# L8 O6 n% I5 j  ^* h2 p3 R

9 {: s( v9 b2 F: k: `9 `
敏捷软件开发
" p9 i" c4 N" n
6 _: J, W5 @  B5 r
Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.
1 Q  @. `4 Q3 n

/ ]( i# }  o4 H
持续集成
) g) q( L; e; c- v1 J1 J

  U# o* {4 ]* H0 l4 ^" j9 |' D3 q
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.
4 F" n6 c0 S$ s# W; A* b$ w, H
0 M8 I( j+ v# Q# a
' L0 P2 @- _$ \! }( z8 E8 a
DevOps
1 T. q0 |# b7 d4 G9 x

$ g) g' l% k; H* i  ]
DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.
& J! F/ n  C* @3 P2 A9 H

. U  z# K6 ?2 }& n" t
我的解读
' ?3 ?8 p5 K# }1 ]
' r/ J9 \+ z1 f+ q6 g6 t2 n  A  ?/ u  ^
1. 敏捷软件开发方法

1 U: @8 h/ O1 ~: v6 ]$ I( D1 y

- _( Z: a# C% Z: _. s
从来就没有一种方法,叫做「敏捷软件开发方法」。因为,IT行业中的「敏捷(Agile)」一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议)。目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线。

+ s/ p( P6 @! c6 N0 k) Y
4 g/ \6 u6 [& P1 X6 M, a; G# H
在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum 及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调「敏捷宣言」和「十二原则」了,只在培训课堂上还能听到。

# \9 p  J" x. |2 v

0 B3 d/ A% x: F0 d
2. 持续集成
8 L+ h4 P2 a# A

# M$ A% W0 c; ^% E4 M. P. z
早在1999年 KentBack 的《解析极限编程》一书中,对「持续集成」这一概念就有提及,它是极限编程 XP 方法中的十二最佳实践之一。在2004年,Martin Fowler 发表的一篇博文上,给「持续集成」下了一个定义,并一直沿用至今。即:「持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。」这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫「极限」二字了。
9 w/ I; d. v+ b
, P& ]3 S, B/ D) T
3. DevOps

5 V6 u0 U  B5 L$ ^$ e7 S+ ^
  [/ ?5 S) c0 z2 z. c
在2008年的一次敏捷大会上,运维相关人员就「敏捷基础设施(Agile Infrastructure)」展开讨论,并在2009年以后逐步发展成为一场大规模「运动」,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让 DevOps 多了一些发力点。

: k; `- k8 s- n: [1 E% }  d
$ C) R% d* N; y- f* ~
4. 持续交付
; o8 G, B/ n$ E, h# d5 |: b! }

5 u0 E: N! H7 k1 x9 _7 E0 y% |
Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。

6 x" U. ~2 y0 b" q. R# \- C8 H
4 h! E! t  q/ A1 X" r
它们的关系

- b" G5 v# ^+ t
1 T" M# o% V# v$ p9 h
1. 空间与时间维度
2 `' j2 {. x* M
0 D* z7 r0 v+ F7 F8 j3 R
根据以上的信息,我认为它们在空间和时间维度的关系是这样的:
1.png

6 }# N5 l+ Q+ R

( ~2 B/ o+ m, v
& V. a$ L! q8 V
上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?

1 H  P7 T4 z  b. Q0 T

' S* `- T* Q% ^: l0 u2 @
2. 人或组织维度

$ k+ [+ a8 ^- F9 o/ u. l& |
6 M# }: v" S, ]! s7 _
我的微信签名是「别提概念,只解决问题!」。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里「所有的问题,都是人的问题」。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?
1.png

- w: n3 s$ P3 r/ t9 i- o  M, r9 E' s
! Z2 v9 \2 P8 a$ l, v
持续集成,有助于打破开发人员和测试人员之间的「墙」。

& X+ L  L- `& [! V- l' X

" I- v* `: ~! ^3 _
敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的「墙」。

/ C8 @9 o3 I& K- d) b. W7 K

8 o, q$ z: s# v" n8 D1 X
DevOps,有助于打破开发团队与运维团队之间的「墙」。

6 J0 C/ E! y5 i' K) r1 q

; t7 {5 Y. n/ j$ N, S8 Y* ~( K
为什么从「人」开始
6 c8 a# e0 {# h- g& J
) q4 k$ c0 r* w. l" ~$ q' D
在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与「人」相比,技术实践并不需要太在意,即:最好还是先从「人」的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。
5 o2 O; t+ \7 X( r- F# @6 M4 H

$ {4 T, Z: f2 R( E: B. p" j
从哪里找问题
' n9 c( S6 O0 V1 ~; n- H

; k/ ?6 b' p3 J0 l" I
从参与者的问题陈述中找问题。比如:

) l* n! C& F( Y' o, T) x

8 w8 L( d" {1 J- H7 v$ M
老板:

, |; U& n. D$ b7 |
  • 「项目经常延期」「做东西太慢」
    8 q$ X( g* `( O5 n5 V6 X0 q: G. T; b
; _- U. A, G# |% {
产品:
* Y1 ?  c/ R* H7 J( w

' t% G8 g$ l, m* H! U) X
  • 「老板的想法总变」

    $ w7 N+ u5 f+ d- K5 D3 ?
9 j+ B0 T% Y9 @+ X1 K# w9 h+ T
  • 「事情太多,忙成狗」
    5 j( Y, i4 u/ I+ H9 {
- }. F- x0 ?2 ]: U
  • 「开发说这个实现不了」

    3 [; h+ _! R! M5 g* I

4 M/ R6 q8 Y  s7 b
开发:

0 l# T4 y; S. E
  • 「需求总变」
    ( n1 T* i7 m2 }+ P% h% Y" H, _6 i
4 W6 L! E8 Y! w; y4 l+ Z
  • 「UI 方案给的太晚」
    7 P- }1 i6 H# `7 O8 j: n4 e- |# k
; W5 Y' N$ j. h5 g) x4 m' j- x7 j
) Y# u8 V9 [# p& {! y
  • 「活儿太多」

    $ ^# }# m& r# o; B/ ^8 `+ K, F) c
  ?4 L* y: ]2 i3 c0 W% V, [, Z
测试:
$ W) C' H! ]4 ~4 g4 L8 F" @* Y
+ X  J. V& [; B% c9 R! e7 ^+ ]* E
  • 「需求变了没提前通知」
    # d" ]" `+ h  f7 u5 Y% S5 z5 z

8 D2 _- ?3 C5 p! Y$ r' C
  • 「测试时间总被压缩,还要背锅」

    1 o4 Z, v9 m+ e) Z0 B

6 d4 u6 L) U) }0 ?- L
# ]- `% |6 @; R7 I
  • 「重复测试太多遍」
    ' h1 _2 S* R/ w( _
/ F, e8 v7 M' F4 t# k6 _
运维:

: j+ b! [2 S$ v5 h

$ G: _  q9 X: b0 H# j0 N7 i
  • 「每天这么多版本上线,活干不完,出事儿第一个背锅。」
    # S0 C. S& U# w& U  h# a& n2 O1 `+ ^

. l( S7 k- Y8 D2 j' Z
每句话的背后都有很多含义。开挖吧~~
0 d, [/ ]( a0 Y+ ]! H' E

5 b- D) J( W2 G8 U2 ^2 ]& @: e
提问题的人是问题的创造者,也是接盘侠~
7 G% E+ Y. O4 d4 p9 Q5 U% ]

' M' V* C8 e& v1 d: B; I( [
1 N) H, w2 l# U( t4 q/ p' o& h
从哪里找解决方案
5 p6 D6 Z" I% N# Q+ y9 f& z
! {1 d4 j- g/ J0 S& d' s
在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:
; \) ^; N) p3 Y

, l6 o( `) V  d! u# q# l  d
  • 构建管理和持续集成
    5 l( z6 g3 T, ^% H% `

- q& V0 d, `* N% D3 q, @- N
, C: C; d' E" r( i
  • 环境与部署

    " y+ A. C# U- f! W5 z7 U

& B) j  H% U0 H' n# p
  • 发布管理和和符合性

    $ X4 q/ R+ z& Y6 B
6 C7 r% D1 S  [/ k
  • 测试

    & N+ L- L) \  r7 H( l/ ^8 i
& E1 s0 n, L2 {0 P* z8 _- \: X
  • 数据管理
    " o6 h6 i; O- C5 l

, c4 V# x0 d4 ^
  • 配置管理
    % E; l4 t$ s. E' k
5 Z/ Q: s1 A0 k
通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:
5 u0 ?1 K0 D# M
1.png

/ v" [( k6 Q9 @/ j/ ]' M1 M
我也没有称其为成熟度模型,而是「持续交付七巧板」。
( |4 v+ M1 i" O, Z# `
9 C; a5 G/ k  L% w' w' V  N
是的,中国的传统玩具「七巧板」,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。
$ p8 [5 W! A. y/ G& C3 j
7 N% `5 s5 k6 I% W
找正确的问题去解决
% u! k' O! H5 n6 j8 |

; H" n# ?+ N# h% I& x
上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

6 X+ z4 Y4 @& E) ~
) o" C0 b8 O$ b9 G& C3 z3 K6 x- z. O
  • 怎么做持续交付?

    % o  N) u9 `) p+ r

- ]+ g3 B3 s8 }
  • 怎么做持续集成?
    . q9 k: C& _" o: P  x9 ]

; @- g+ J6 D: \9 X9 n- u" o
  • 怎么做敏捷?
    7 ?' l' [  b) X( w$ m/ ~7 B

8 [& b! H8 P8 M5 B: T. @% y9 y: z
  • 怎么做 DevOps?
      u, m  t+ g. ?+ ?; N. L9 S, A. f

0 q5 y! q9 [/ X# R0 C! i
我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种「捷径」

4 V$ E$ t1 }8 J: O7 k: N# c
3 k) Y8 N: @4 {5 M% y. k
  • 我们做的是敏捷吗?
    $ C: o/ ]( H, \; X: V
& T& A, |8 \3 j0 X/ P8 U9 r3 X" Q4 |
  • 我们这么做持续交付,对吗?
    ! ^3 U# U% z9 v7 P; S
. _" v5 S% S; U6 i/ X4 n
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?

2 ]) S- y" Z' L( Q7 Q4 f4 v
: _5 z# t- a! e: A6 c! F
  • 你这不是敏捷?
    8 }  E, A7 x7 H- X$ q$ N9 _
2 Q, ^2 c9 D1 n
  • 你这不是 DevOps?

    . {* M+ P, A! B7 D9 f% l

! Z& o. x! u  i9 D, F( J: ?  t
  • 你这不是持续交付?

    - ^: \& k% u. D) P$ g& u

& _- r# N5 P1 ^) N
  • 你这不是持续集成?1 F( A  j0 \1 N

    * C$ C2 {9 ^# G. o# R/ G' E

/ B2 ]; d) i1 w% `5 d: y1 p
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~

* O! S9 y4 Y) X' Y4 k; l+ @( O8 W2 Y
( g- ?4 U! [; i' l
再炒一炒冷饭
2 S& h2 N6 \5 Y3 f

8 ]- D. r1 J0 ]- R
2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:
1 f, |! ]; ^( ^0 G2 K) m

; k$ x9 f# X; X2 W- @: I" x% `
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?

* e3 l2 c- p2 Y  [. P1 m: r9 J+ Y
3 @( [# l* F4 R- Y  O' E' E
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。

; z' ]8 J- z& K7 L

. ~  E( }; _9 G4 W
2. 标题党啊

! j* u5 G) Z9 f; I9 r

( s" e8 H* E% {" v- L
好吧,我承认在那个很少有人提及「DevOps」的年代,我就做标题党吧。

1 B: S7 R! F2 A5 ?
1 h" e1 a: m4 c' e2 W+ Z4 V
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。
/ j) d; t/ u* X6 U; ?. Q! l

9 s# w5 b& n$ s& f  t: i
一、了解环境背景
" N3 ?2 C1 U0 f* h) s/ V
( ?9 E0 d3 D0 I3 x  \" ^! X) K
当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

" i( V& i" p& g

: T) v: u6 m  v/ p8 u6 Q
几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从 Google 跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。

; ~: r, b2 V9 S. a; B/ \4 S
- a# q% z( ?0 ?. v) ^
团队间接管理者
! Z! x/ Q4 T- {1 K* q) P) u! D% S
3 G( D0 V: A8 ?
  • 项目交付不太可控:

    " |( b' T8 @* }% \! W7 u

; B' w3 T7 Z  \9 V, A
         我们一直在做计划,但计划性非常差。

# |4 @/ v+ c7 f3 u/ k# x4 E  L
& U) w3 h" K8 Z  O; E
         经常有各种各样的情况发生,总会让项目改期。

6 H4 R! T3 T* U0 B5 f

+ _, L6 f- G2 k, Q4 r
团队直接管理者

0 Q. |+ [) e. O! P

* L# K& }  p$ Y( H% n, l
  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。
    / Y) G( z/ ?3 n9 |: p
7 N" v1 i1 P7 \8 A! O6 m( I
  • 这个项目中,有一部份需求必须在XXX时间点完成。

    6 M. M; w( L4 E3 i
- H8 o. r* S) h) }9 [# u' E& Z
团队Lead

: m8 J; @$ i0 L$ }+ c

  @! G  G2 x9 _$ a6 |3 E' G0 s
  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。

    6 I' ?0 r( }8 [+ l
0 G" V' K. Z0 T) L
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。
    & S1 ]5 d2 [+ E2 g

, L3 W1 U+ b/ H9 Z0 B1 e
开发人员

. r  j. J/ A& J$ W* m5 N

& z! k" y# {0 Q4 J4 o) d
  • 领导说试一下,就试一下吧。

    ( j" j. E; a: L4 f& e1 T: j. c
    6 ]; w; i4 d6 a, ?2 a( }* J
测试人员

) c4 E( e4 Q; P  x

( o% Z8 o8 V  F* z
  • 工作经常被打断。

    , M' M0 H" X" p+ o7 h, E. u
( ~7 d1 o4 w1 n; u$ h$ S% S

2 `) J0 N$ e5 o  X$ G8 W
  • 提测质量不高,经常浪费精力。
    " P6 ^/ ~6 f0 e; l1 s. G: z

$ W, n: P! A* R# D7 c9 Y4 \
  • 出了Bug,影响太大。
    # k  D' D) q. r- H

$ W4 b& T/ _$ Z( U  D. O( ~) a# B
  • (这里省略一千字)。
    ; o# U  }. d3 D  O% m" b
0 U) t1 n( z9 k- P% A
二、找到正确的问题来解决(目标)

  d& u/ J7 Y6 r! E: P% u( G! R

/ R5 G# w. `/ z( x8 V5 Y
三个月内:
7 X" m2 h) d9 w5 W
4 v4 f8 s$ y8 r$ E! C' [
(1)该项目交付时间可预期。

8 Y, t! |( w$ `/ p) C

$ k0 B5 w; h( }8 b
(2)建立新的软件开发协作方式。
; K2 z( i9 _) Z' T. F0 G3 u+ f

  e7 ?. G- C1 f2 p" o% H; ]5 G# x! `
(3)建立必要的基础设施,以支持后续的持续发布模式。
" X5 I+ p7 @& X6 H8 p

+ ~$ q2 T/ _0 N: F% z
三个月后:
1 u+ A. N/ O+ _

) u5 p% a5 U& d9 u3 ^6 g, [) M
(1)需求的周期时间缩短,可以短周期上线。

& V, y' G1 B: |) q, z" j
' j% {4 r3 ]' y2 U1 J; O. C
(2)生产环境的质量不降低。

* t+ W; A3 y0 N8 B% n+ E. C/ ^7 ^

' _3 m% D! p$ ~1 C: j) {/ u
(3)测试人力总投入降低。

! Z5 G8 V# ^+ G% k( v

4 ~7 N( L3 k& x7 j/ l0 V
在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)

( v0 a% M( D3 c# x& D

8 j+ r* E2 R# K. ?1 V+ |7 k9 }
1.通常行为的改变,需要一个半月的时间;

% P( ~/ L: I) ?2 ?# n
) [9 M+ Q  @+ I, P4 R; s  w% N* F
2.带来强烈可感知的收益需要三个月的时间。

/ A1 x' \% ^$ m0 B9 n

% C) c5 e" K% `
三、承诺是必须的
' ]. h3 l/ B7 I' \3 g! y
( g$ N1 |1 X1 G9 C( }
上面的问题(目标)找到了,也要一并承诺。

* B' B0 b1 C; P1 D0 L5 T4 l/ W: X

( N" F$ k( [, l
要想让团队和你走,你必须站在前面。
/ T  p7 Z  s( H1 @! v: {

  N8 b0 a6 t1 F+ }, f& @
四、培训及过程指导
& ]( S9 R" b  u! |: ?

" ~' Y8 O. U+ {& x
需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。
. T; j. ?4 ?! e* O

1 B" z4 c6 }9 k0 ?8 x& |
启蒙培训(1小时)

; C3 |% N) a! w6 ]

' E+ R* u$ v& X+ @0 {, o
对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。/ b  I. I& R* M! i3 V

" Z  I/ J6 N3 ]9 x5 V  ?

: u& m# ?  ]$ O  g, `
重新定义工作流程

3 q, @& B: W7 ?4 |  W, e
6 S( q! U, o+ Y/ [
  • 新的项目工作流程

    1 q/ y; R, ^) m  d4 L& t; U

% ]4 ~* J: v4 E' ~! }* L, u* `* T, b
  • 新的迭代工作流程
    5 v, L# k, S$ }+ \$ e7 P

$ I" j" D" x5 c  X! ?
  • 新的需求工作流程

    ! ~! Z1 _7 Z1 y0 {  m9 G7 \
1.png

. [4 k) _) i9 W- [

" m- [: I6 L) l0 A2 |

  j5 ]  O4 L  ~* B
  • 新的代码工作流程
    0 n- b, H2 h2 |- p
1.png
0 |% \; o/ H; R6 F$ m" n
7 Z1 K8 U* D! n9 C8 k7 z
4 s  ^5 p- m7 i5 V$ V8 P
解决新流程中的障碍
0 z6 @' M  B7 l/ g, j+ J9 X
* d7 K2 w; ]) T' N: Q. l
  • 团队沟通和协作的方式。

    5 g/ X; T5 _! L5 ]2 ~

0 m0 Y6 R) V0 v5 _0 Y2 c* @9 w
  • 编译环境的准备。
    : Z( |' q9 k; |
0 |* s0 o) H" a; S6 P2 U% U
  • 编译时间的缩短。

    - f0 d; ^! a5 @- g8 {5 Z1 t

' G' q8 u% l$ a
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。

    , L" s! l2 g3 G

    ; y1 f* c  ~+ s" O2 A
1.png
/ V, Q( a  T& E

$ x. T; f" B, C' w
  • 自动化测试运行的环境的准备。
    + p! u: O* o$ S# P
! L+ A. h) o4 _& o2 ?1 {1 [+ s
  • 自动化测试编写时机与自动化的利用。

    0 I) _+ u0 b' w+ W$ C

' Y* Q; b. Q- Q( X5 H
  • 自动化测试用例代码管理。

    : X. @$ g1 s7 W# L$ `4 q6 |
9 C! F. ~  Q( v$ U4 \
我和运维人员的对话(真实的场景再现)

# [; g3 }. f) H' D
: D! V$ j8 o# V  Z. z3 L
我:我们团队想每两周就部署一次服务

/ q3 J5 n! R* }  q/ J5 r' K
, p8 ^: v% @9 A( M$ t- `
运维:不行

& f0 W. J: `7 n; Y- T/ L

* A5 ]0 M1 c' c1 c9 f& O2 M
我:为啥?

7 S9 q% G7 v, ?8 g  V. n) a
# W8 q+ g# |+ t1 B# f
运维:线上需要稳定
' K' s" u4 L6 V2 R# z

% a& ?4 h* ?% @% J
我:每两周部署一次,就不稳定了吗?

" L4 E- V5 w  j) t+ d! S

) |$ k0 G' l4 D5 i
运维:原来的质量太差,每次上线总是出问题

  n# F/ k6 N" W* L6 }/ v: w
' y3 Z9 n3 [1 q$ @4 L2 M  `
我:现在质量很好

* U3 L5 h! [! d3 G/ Q0 }) D' n
2 a9 Y# i" r: \) u$ |
运维:怎么可能?
6 ]2 U  ]) ~3 U6 \
5 r/ z/ H3 d3 U2 V9 a1 W+ M
我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足;
1 P. u5 Y! Y& w# S1 U4 z
0 H5 v: A2 Z" _
运维:那也不行

. l. h; @2 U( t- \2 w
  Y0 ^/ `4 p$ k5 v9 H
我:为啥

: h1 q1 K; h% s8 F

: U1 @4 h9 F5 X+ Y8 H- Q# p3 v
运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?
% T, a' f: h+ Y3 z
8 B: H' S( \* b( S, |
怎么解决?# p/ _1 I2 F2 @- L1 d
! I" s( o6 }: [. s0 e
3 W. A5 r. b& A( u0 {4 j1 G
改变部署方式,让他的工作生活美好起来吧~~~~~
( `# V6 G3 z' V) H$ D# K
1.png
0 a6 g- O- t" O) W/ \
部署流水线的建立,要求一键部署
1 w# N  O: ]- J( q/ v( S$ b

- ^$ I% ]- F; P; M* t1 N3 |& r$ u
运维人员负责编写部署脚本,并做版本管理。: o6 p  r/ p" |: K& E  u' r+ H9 H& f
/ l! P- [# I6 o, h. a* u: l

% O( y7 K$ V2 O+ k% T* Y开发人员在开发自测时使用同样的脚本。

! N: {" Z+ ]# h0 r) N: ~7 W- c; R: C+ c5 @, g

  t& [# `3 w$ ?$ I7 \! t5 Y; P! d测试人员在测试环境上使用同样的脚本。
$ A9 {% J2 A2 j# l
" ?% `% B7 K6 C% c  t

+ [# Q9 ?9 `+ C运维人员在生产环境上也使用同样的脚本。

& X3 F& J6 l$ n  h0 D  D% \7 t# P9 z1 h% z- r) \! u9 X
5 N, ]- A2 @5 J6 u' I
  • 原创:乔梁& v% v  j/ N. s
; f6 R9 F7 A/ a% }8 p- s. [) {* u

. ]8 M, w- W, A% W; c+ r* s8 e
1.png




上一篇:Capital One (美国第一资本金融公司)的DevOps案例
下一篇:DevOps 理念的私有 PaaS 平台实践经验
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、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-5-23 04:37 , Processed in 0.179810 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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