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

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

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 147|回复: 0

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

[复制链接]
来自- 广东广州

参加活动:0

组织活动:0

发表于 2018-10-19 11:02:45 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-10-19 11:12 编辑 . [) |. q# {! x7 m% y5 g: _- F
: M5 Y' |. P: U9 B% t  P, @7 c
0 P# I  C- t9 |
这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! 「敏捷软件开发」,「增长黑客」,「持续集成」,「DevOps」,「精益创业」,「持续交付」,「大数据」... ...; |# ?! p& Y( K+ n' j/ _

" o( R$ T/ H! S8 {1 d/ U: x
/ F( o1 L" M9 c! z
OK,就这四个啦:

# E* w; J' X% ^! Z
! g& P4 W* `7 d  R8 f
「敏捷软件开发」,「持续集成」,「DevOps」,「持续交付」,; D! L) i. z, q+ ]- c6 h
4 }" I) k3 Z4 Z( n2 x; ^3 p
2 u/ I5 X; d& O9 V/ V
先让我们在 Wikipedia 上验明正身。

7 R! n. |3 G; s7 T+ s
- ~# ]+ K9 B9 \4 ~3 _
敏捷软件开发
% \6 I/ H: j9 L% S! S

0 X) I0 s4 M, M- X* ~! ~
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.
* a$ v! c  G* T1 L& K! n" H

$ a/ o+ e: N0 _: x6 ^: r, b
持续集成

2 `' N' C2 w, ?/ Y" N% d' J
& {5 V. Q) i9 b& V' q0 z
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.3 l/ T2 ?* Y2 o
% N1 m% h- P' G. E3 Y
( N& t6 R5 V: n6 Y- x) C
DevOps
; ?5 P5 d' _* D4 [% Z+ F* i

! z0 |! m( w4 Y4 f7 G, x
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( c" a! t$ T

, [9 |: p% ~; i  V
我的解读

4 z. }9 X) O8 w) D; c
. x7 m1 |( f2 Z  G  U
1. 敏捷软件开发方法

0 B' I* J- P. X7 j- O0 T

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

5 O7 D- D$ T2 F: V; l# s5 e
2 Q6 f2 K% h$ D7 r5 ^9 q
在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum 及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调「敏捷宣言」和「十二原则」了,只在培训课堂上还能听到。

- P# E& \$ w, O
, q! m$ s  k  t1 Y' z& k% w
2. 持续集成
  Z' B! G. Y+ `* v5 w9 O

$ z, Q0 V* V+ }4 @! W
早在1999年 KentBack 的《解析极限编程》一书中,对「持续集成」这一概念就有提及,它是极限编程 XP 方法中的十二最佳实践之一。在2004年,Martin Fowler 发表的一篇博文上,给「持续集成」下了一个定义,并一直沿用至今。即:「持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。」这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫「极限」二字了。
& I6 l' \3 ^5 w+ y7 w$ t: {: W

5 b8 s: p& ~7 ]0 U  t
3. DevOps
3 c% M( x9 L. w/ B- ^

, k9 }# `3 E9 i0 X/ W
在2008年的一次敏捷大会上,运维相关人员就「敏捷基础设施(Agile Infrastructure)」展开讨论,并在2009年以后逐步发展成为一场大规模「运动」,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让 DevOps 多了一些发力点。

, N  g3 ]2 g6 M. u! G# A
' m- E3 X  n% O4 r8 V. l* {
4. 持续交付

5 x7 E' V- Y; N* K1 u

+ K, m6 T/ F" q$ U# Q4 P; W
Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。
5 i5 }& |) P+ i7 v& i4 `5 r
, r+ Q+ c# |8 N6 p3 V4 e- g
它们的关系

# X8 l- |. }1 f* c6 x7 ?

( Q0 `9 m1 z& K- {
1. 空间与时间维度

6 U& _+ q: a0 j  g1 i
- j, x! s* I% n% y( D/ l- f# n% ^
根据以上的信息,我认为它们在空间和时间维度的关系是这样的:
1.png
2 Z8 O' a8 b( j
3 \# G1 K, \1 v' v" l- P
$ G7 J% @( d  {/ o* H
上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?
! ]/ E0 U9 P/ v- E/ S) \7 Y
  A- |8 d7 }2 J" f
2. 人或组织维度
. l8 H  w. v5 X8 x1 w

/ P! ^# s" B4 j& J$ G. B0 f
我的微信签名是「别提概念,只解决问题!」。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里「所有的问题,都是人的问题」。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?
1.png

1 J, z4 I( h% L
+ m2 Z0 C/ Y0 N* [/ Q3 J5 Q& M6 |' s
持续集成,有助于打破开发人员和测试人员之间的「墙」。

3 h9 m1 q; T" l4 U
/ U* y% M1 P, m% w7 R. i
敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的「墙」。

* N- [8 D/ K8 m$ w
) c4 O$ o  R# N* u7 C  m  F# u$ j
DevOps,有助于打破开发团队与运维团队之间的「墙」。

, R* |  [/ U8 m( u) N) o* _

. _* k  Y. S; v/ S+ _$ v4 e
为什么从「人」开始
" H# f2 j) u0 W) m+ R

) ?3 t9 r5 p. G1 q4 J( y% E2 d
在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与「人」相比,技术实践并不需要太在意,即:最好还是先从「人」的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。
: a' Q+ _9 O8 Z& W5 ~

* \$ y2 w- r+ q1 I* E
从哪里找问题
0 C: I! @. e8 y9 V9 Y7 E. G

4 L9 |% u) t1 H- ~( n
从参与者的问题陈述中找问题。比如:

- m2 f# b/ C, z2 D. d
8 f3 a+ E/ [9 J/ N1 k
老板:

  {5 B; @; s! ~, D- p+ w9 s
  • 「项目经常延期」「做东西太慢」

    , e' Z. Z! H+ j  m9 D2 ?) c  Q3 G3 t

7 A$ d0 G: |8 A1 l1 C  G9 b( E" Z
产品:
1 S6 X" i+ P7 [/ M9 s
1 U! W% ~9 [. Q. |) U( N+ d
  • 「老板的想法总变」
    9 z$ `9 X& `( }: n4 ?

) \; ^% g( Y! `! R8 I: v
  • 「事情太多,忙成狗」

    : Z2 v7 e/ c* b, d
% r# b9 ?# `* }( F1 M
  • 「开发说这个实现不了」
    # v' k, m% ?/ p

7 [0 Q# B1 k$ |, G3 X' A1 o/ t3 ?: Q
开发:

: ]) U- F( k. D, d: E( J" q: }
  • 「需求总变」
    9 z" I& a1 @$ |  _. n/ G  o
( V  }" c4 m8 L1 T1 p1 v# ~
  • 「UI 方案给的太晚」
    % v- L, t, d/ L, ^2 h1 j5 V# \+ B# M

9 R6 j# m+ `: W7 t4 Z! ?' k

9 t/ u3 `, J7 C2 x5 U: b5 W
  • 「活儿太多」

    ! V9 s2 Y8 _* g# D4 _- Y) e* Q

* ]- X. v' n8 ~( f
测试:
8 i9 |0 G' }$ @

9 |0 t2 S# u4 \4 U
  • 「需求变了没提前通知」
    4 _" ]& p8 ~7 _3 Z9 |5 {6 R4 I
' |/ F, s/ }1 r
  • 「测试时间总被压缩,还要背锅」
    3 G; l  ?) I) `  E3 y8 v
3 Z) T, F1 \, \7 t5 v" o2 A) w
: C. |  o$ d0 h
  • 「重复测试太多遍」

    ( @4 h  ]& ~8 q4 E3 G- z

( m1 v+ N* B2 h% k) q7 m4 G
运维:

# ~. x6 h6 i7 Y

% R3 L9 o  h2 b% S4 Q8 X
  • 「每天这么多版本上线,活干不完,出事儿第一个背锅。」

    ( z0 O2 ^- N4 J

2 Y. f7 J5 u; W0 h- Z8 [
每句话的背后都有很多含义。开挖吧~~

# C/ q  U% l  V* V

7 K  X! }0 N/ _# Y
提问题的人是问题的创造者,也是接盘侠~3 i* k6 k+ V( E: s! @
7 P) Z$ G& R1 _5 a
4 @8 P5 Y% K) |7 l$ B1 s, A
从哪里找解决方案
; Y: x6 c3 K" `# g0 M
/ V& h+ x/ c; Q4 f* P) q
在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:

* h, X$ l9 B9 j/ M6 Q0 l
" v0 u  Q& c( t  Z) s3 }, l
  • 构建管理和持续集成
    ' k1 P" x- `1 z( A$ B
+ y5 I: ~5 {7 C+ x& {- }

3 b4 X- k; I* C; `* Y1 g( \
  • 环境与部署
    . S) |) [: `9 W7 j( v& Q' C7 P
/ M: A+ C0 y5 n& s& N0 e
  • 发布管理和和符合性

    9 w  O. h8 A. Z, j# E- l2 {
) }2 N# T. ~* d# S3 E: k; G
  • 测试
    . Z* h9 {# {6 Z
' U. G! I9 e* m* X% n; W
  • 数据管理

      w3 e/ B9 Y& s9 W' x" m

! }4 T% h# R& @% r+ }
  • 配置管理

    6 ~9 m  v, [* E5 @/ X
% w" c0 c1 ?1 g6 g  f" [8 g
通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:

3 U! @6 \& G6 K+ }% d, Q8 c: w
1.png
( l, X, v4 L. y7 b# G
我也没有称其为成熟度模型,而是「持续交付七巧板」。
: m* ?" [! r: R6 N6 h3 S2 O. g
" A+ w$ [" w" U2 D8 l
是的,中国的传统玩具「七巧板」,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。

1 j2 b2 i$ K3 [8 T
! P4 |- k; d* Y, J; g2 ~
找正确的问题去解决
" n$ Q5 L' U8 P+ s- m" T5 I( M

. J3 p' m. p1 p) @
上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

. q9 k& X, g/ n4 q5 m$ U3 u% g1 I
- R$ j7 l+ r+ p* K* j3 {0 O  m1 T
  • 怎么做持续交付?
    ) ~. \. L, n+ U! e# j4 n! Q
+ L( `7 `  o* t) ^2 `
  • 怎么做持续集成?

    8 O+ J% s/ q1 m( ]" o
# Z$ \  z4 V" y! N8 j
  • 怎么做敏捷?

    ) _6 e, J" f, o4 L5 S2 }% E/ x

5 y0 z' [/ G  ?4 s* A& _4 x
  • 怎么做 DevOps?
    5 `! y% \* Q3 c
5 w! h6 I5 j' o: k6 w* ^! g2 y3 K$ T
我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种「捷径」
# H% H+ h$ L5 m. e% Z9 Q, G

& ~, y% H! b4 C) M; x! k* c. d
  • 我们做的是敏捷吗?
    1 b. H3 U# _0 x, h& r% K7 |

, @6 \1 |  `' W/ f1 Z- v& c
  • 我们这么做持续交付,对吗?

    / E/ Y5 i# R" d& n9 j' {

2 W7 n" g& N* z' R
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?
/ x. Z. P/ C' o7 V9 N6 B2 T  V* J

. f! \8 j5 [2 ^* {6 N8 z2 u
  • 你这不是敏捷?
    9 h9 R! L8 v2 H; R) H( U

8 A& f/ o9 S( s/ N1 s2 Y% r" b
  • 你这不是 DevOps?
    1 B3 ]1 n& I0 N

, R, X" O$ e5 N6 C+ K3 D
  • 你这不是持续交付?

    - V. j3 o2 C6 q' L6 j8 g" A
; a6 s* m" W( W/ T
  • 你这不是持续集成?. D  x# b. t+ m+ _
    ' A9 M0 d; m3 o# I8 v! X+ f
) ^( e1 @* d. p+ c3 S6 p
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~
, l, j; B: _+ ?1 i5 Y- ~. r
' ]6 R# ^4 V& Z* P0 w
再炒一炒冷饭

" ~& K) n& r2 n. ]

* ^* {1 D' S- N5 Q% _
2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:
+ ~6 Z' j" b* C) M5 q5 S5 w8 s
1 B, F1 j3 V$ i% e$ V
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
7 B4 U0 f8 W$ _' h5 t9 ]
( ?8 D, [  l4 ^0 E% s( ]
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。

5 m- ]3 U9 \6 r! C' t0 L. |
& Q) n4 _5 o. I$ d6 h
2. 标题党啊
) [: T% {! Q0 P1 R4 N

  b* G' ^. L+ U. i$ ]2 q+ E
好吧,我承认在那个很少有人提及「DevOps」的年代,我就做标题党吧。

+ K/ z, P4 g( S7 _
/ O8 y1 Y# @( `* ?0 T. O0 W
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。

3 M$ q& j& {/ Z0 @9 F
; j6 j/ g+ _, F$ @% Y+ }9 A! h
一、了解环境背景

' K$ J$ T+ D0 a( O
2 A# J" \5 d( G  ^: y! L' x; l
当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

& P: Z9 w$ ~" e0 V* ]
1 D8 a+ A8 b: n# O- n# S) B
几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从 Google 跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。
! Y( \$ [" @2 G8 u" g% u
' e# x$ I: _/ q. U  ?1 r& a
团队间接管理者

/ [6 ]9 M" l3 }$ x6 u9 k/ z

9 w# k* U% U* W- a0 J& D
  • 项目交付不太可控:
    7 P! a! B- H/ G* f: Z

4 N+ d2 X" K+ k
         我们一直在做计划,但计划性非常差。

  c8 H' g/ I6 ?& E# ]6 P
. r4 e' f  R& r2 c
         经常有各种各样的情况发生,总会让项目改期。
$ o1 G0 s2 @, k

6 K9 {" t) |# v: v% D
团队直接管理者

, N, O8 k3 {, n0 {& R; D3 t/ O
+ |8 ]- I$ F) U/ ^. v4 ~+ y
  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。
    3 }! j5 H: B2 q, ]9 X% d, E
5 c  n1 y2 {. Y3 [# W3 g9 E% [
  • 这个项目中,有一部份需求必须在XXX时间点完成。

    & \- x2 B) ]3 s; V, U% F
7 y% d1 w% e. a% n- J0 h0 F3 l
团队Lead
! e# O8 a; W; L  n2 D/ t

2 V% @$ q' A# p2 C
  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。

    + S/ _4 y+ g( A8 t

8 f1 L! B% h6 A
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。

    ; ^( v9 i0 ^# M* J5 o; F6 E

& b/ c- g, k1 c
开发人员

* R3 b/ p  h* O

/ F4 G( p/ z5 a
  • 领导说试一下,就试一下吧。

    : W$ z. Y& j( x, c- l

    0 G6 Q! h7 r% [7 q% [
测试人员
- K& M. Q) b7 I% P' V

4 K) H, Y9 t2 x5 h0 o
  • 工作经常被打断。

    4 z) m: z0 R, P

! W/ Y; L& i& Y2 e9 D+ C
1 B) A5 X$ q& e) t$ [
  • 提测质量不高,经常浪费精力。
    " ]( ^$ _! l1 N0 q" F& A
) K: q0 [8 c# l8 _: ?8 Q0 {( O6 S
  • 出了Bug,影响太大。

    + z6 ~2 \+ \% F3 n; M

' m4 }/ {8 t- X8 s0 o
  • (这里省略一千字)。

    $ Z' y/ M8 a# d/ D, c5 U9 u% s

5 t& v! D  q& y9 ]9 K
二、找到正确的问题来解决(目标)
3 p& T! ?' w' y& o  B

1 m2 I* m; f3 E  K: o
三个月内:

- b: A% T8 k% o6 w& b$ {

& Z) y& a- q- f: ?6 J  p
(1)该项目交付时间可预期。

# ]6 w& s! ~+ l( E8 v$ s

( F/ r1 K- r/ K4 q* g; i; g
(2)建立新的软件开发协作方式。
/ p6 p2 P3 a2 L. J8 l- W7 ?4 c

/ H( e( H9 k* c/ P" ~; J
(3)建立必要的基础设施,以支持后续的持续发布模式。

. K" Q8 [3 J5 O/ G

6 M. T% X) y' B& J5 a6 J: t
三个月后:

. ~3 a& k3 x+ f% h. j2 Z1 P) }6 A

' e: S. V7 `0 M- a8 K+ k
(1)需求的周期时间缩短,可以短周期上线。
0 I! |4 S. a$ E3 d
6 A+ a7 Z( y7 F9 T, Y) r6 q
(2)生产环境的质量不降低。
  \- m+ M; O+ p% Q2 z7 _3 Y6 G6 a
& U& U- V2 F# Z; [" L  o. C
(3)测试人力总投入降低。

# K( D! i; p3 X

% S+ ^' z7 s) A. v9 ?
在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)
9 h/ C2 }8 K2 b  o4 s
  a0 I5 U3 S9 `2 `1 X% y# n) `
1.通常行为的改变,需要一个半月的时间;
6 l. n0 k3 M+ @

" D2 e; ^4 h% A
2.带来强烈可感知的收益需要三个月的时间。

0 ^$ u/ u# v- v( M9 h! L

7 N; ^5 ]' u4 Z# x* m9 M
三、承诺是必须的
1 L3 Q: |2 K) Z) t
. |' P8 {! c. k. m
上面的问题(目标)找到了,也要一并承诺。
. c- s2 }( E; x1 `3 N2 |3 u/ Q% u

+ f* d: O5 G6 x' U$ N( e3 _
要想让团队和你走,你必须站在前面。
! n7 O8 y% C- ^9 z* `2 ?
0 d, k/ Y9 {. P! S* U$ e# l
四、培训及过程指导

/ z; |* K; x) A' I

- Y1 h" f4 a8 u% |8 j
需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。

* x% o6 i( @" D1 p( P  a
2 a& ~4 E) Z) G: k& X0 `0 T2 V! m5 s
启蒙培训(1小时)

0 k4 E' s' J, D3 O' J  C

' C; K5 j/ j& d( i( i
对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。2 N1 q$ G# c9 d8 c0 \- \( |+ a

9 {7 Y2 u* u# E; @; V( B. H9 z
& {- ~, u+ O8 c, \, h% y
重新定义工作流程

0 F( G/ }# _* ~$ u. a- {; T6 m6 Z9 v! a, o
  • 新的项目工作流程
    2 Q5 [4 A7 s5 {. O5 d
5 g- a7 W8 M" H$ C6 d8 x
  • 新的迭代工作流程
    2 ^1 [2 `- Q3 s0 _1 Y6 K. X/ }
% `2 j! F( s0 {5 D4 m" e0 w" d& ?
  • 新的需求工作流程

    0 f; e2 j* K5 f: `* ?
1.png

. T3 e7 z  V0 s: ?% J; j
/ X* S* B3 p- O. q6 j8 u8 Y
2 N0 k# s( `, c! R. H
  • 新的代码工作流程

    9 c0 V/ [; C  _4 R! p( H% Q. N/ N/ X
1.png
9 s3 @, m, m, L5 i$ s* x/ h

2 L7 q# q. C$ N0 B
8 `% B# n" X* v. D/ D2 k
解决新流程中的障碍

3 a  D" p! V$ u& g5 S7 H& @
7 t# i7 {7 v2 {& q# K! v6 e% V% v
  • 团队沟通和协作的方式。

    ; b! j. c/ |/ x2 `- e$ \
- m3 x9 H2 r$ Q" ?2 _8 q& u" M+ j, C
  • 编译环境的准备。

    4 ]3 z3 @* w) r  l8 d

3 U% e. n6 m& I: G* K* @) ^; c: ?
  • 编译时间的缩短。
    2 z, @3 H' K6 b+ }4 F! o2 w

/ y2 k  Z, ~+ W8 {- _3 K
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。

    ' i6 _* M* I; V# A! z+ S- d9 v

    " c) O0 c3 e$ P" y8 _4 j5 w, b+ P
1.png

' T9 G: e# b$ \& i

; I" N; E" n" N0 K6 b
  • 自动化测试运行的环境的准备。
    / l8 h  D- b# E4 m

" ^, D1 z+ H+ d$ u4 A
  • 自动化测试编写时机与自动化的利用。
    $ \7 g5 h% T4 o+ M

0 c+ d9 T; U4 g* T
  • 自动化测试用例代码管理。
    & ]( {# n! a" t# v0 V

! r; J1 J- C' U% f  z9 \9 U4 B' C
我和运维人员的对话(真实的场景再现)

* L! S4 A9 e! B+ n' F* e1 B, q

! i3 f3 S! w$ G9 a
我:我们团队想每两周就部署一次服务

$ C# g; d7 z( C( U9 m
+ n7 S8 j) I+ P4 P9 G. |, b& C! W
运维:不行
- O( x9 q8 H3 v, _6 K! Y9 V

: J1 ]7 Q3 Z3 r" n0 o# O% X& C0 d1 b
我:为啥?

  t% r& b1 E. q
  W0 i! _( `2 c$ B
运维:线上需要稳定
+ `2 X8 L/ `" K0 [. M

" O0 \- j" C: m9 }5 X
我:每两周部署一次,就不稳定了吗?
: b5 l) S4 c+ |: E4 @3 Q  ?
. H0 a5 v8 K- |# |* Z. ~
运维:原来的质量太差,每次上线总是出问题
: l1 y9 R; F, m& u0 L2 r9 W
5 L: c$ [$ T' h7 r; d1 h+ a9 S4 ?2 o
我:现在质量很好
' u0 z% @& k% b/ B

: K2 J; J- g6 ?- p
运维:怎么可能?
5 p. L- E8 @% d  p6 y% o# _2 c6 O

7 ]/ T& l& L  p6 r& p
我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足;

/ C% S7 V0 p$ `6 j
# N  p; `, y: A) x
运维:那也不行
- Q8 \6 ^0 I) n4 Q; i$ l& E8 `/ Q" W
. s$ o' K9 L, ?8 ~6 x8 T
我:为啥
9 r, g# a/ M4 o- f

; s5 p1 e3 C& r- ]( q
运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?
2 P) x+ ?, ^( }* r5 l. m* r+ X( Y

# Z1 c; m" B. j' a
怎么解决?
% m3 [% L# \8 i% e( i: _, L7 P* W
7 J5 T: C; N4 y0 e9 |. `

( L$ P" m8 n+ G. ]$ _. l  c
改变部署方式,让他的工作生活美好起来吧~~~~~

$ y3 _0 h" w* w( G2 l. `2 u( v  W
1.png
3 r# w, E6 U( l5 k1 k9 G
部署流水线的建立,要求一键部署

+ m8 c& _# B3 x5 r; [
' h5 j2 R' N7 U! o# G* l4 P
运维人员负责编写部署脚本,并做版本管理。* o$ j4 F' K; L# f3 H+ ^3 D
; Z* ]8 R0 S. N( E
' ~- ^, I" w1 B7 I! n- M
开发人员在开发自测时使用同样的脚本。
) |9 m! B* E6 p6 T0 O& P0 ]2 s

; }. J7 v% e5 O1 u0 _8 i& C0 V
/ m! s9 K6 Y+ j: O: B
测试人员在测试环境上使用同样的脚本。
" a8 A2 A' g! L- ]6 f9 h/ w  ]

1 \0 T$ O% V- p
# Y5 X( M* |3 N! E/ F7 S2 [* e
运维人员在生产环境上也使用同样的脚本。
6 {9 s8 M% o4 n6 Q6 x
* X% s. @: o4 M' `2 ^+ ^* d

, d8 W: Z, @4 R$ a' _. f5 a
  • 原创:乔梁
    - H7 d% V9 ?8 o5 i) q

5 M& k8 B2 c. d/ @/ p
3 ~+ |/ ]; `3 s% s7 [* w
1.png

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2018-12-15 20:36 , Processed in 0.288523 second(s), 33 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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