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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 656|回复: 0

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

[复制链接]
发表于 2018-10-19 11:02:45 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-10-19 11:12 编辑 , d  N  n& U( g) C  ?6 a5 s+ v2 S

% p$ i. X, @, v. U
, `8 V8 T2 @( w7 B: r$ `5 _- R
这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! 「敏捷软件开发」,「增长黑客」,「持续集成」,「DevOps」,「精益创业」,「持续交付」,「大数据」... ...
7 ?* R; g. `1 _0 k2 o
$ F9 Q( f7 s$ [+ T6 T
8 J* z9 N" e! j2 B  @) T
OK,就这四个啦:
' `" ~4 y+ B; f! P% \- ~" f7 q) M# c
6 V4 z* f$ {# R  ?$ o
「敏捷软件开发」,「持续集成」,「DevOps」,「持续交付」,
: C5 i8 u( _/ q

) P$ N0 v5 N6 V1 ]" K

; K( P7 H: E5 @7 O6 A. A2 j
先让我们在 Wikipedia 上验明正身。

; P1 r6 A7 Y9 H
# U1 k# f+ W4 \% L! T
敏捷软件开发
! k) x& H% L) J; U& ~  |

' O5 `9 V8 A: ?. f% z
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.
0 g+ \( j( m/ ]8 K9 m9 w
: x4 R- `# H6 j) P
持续集成

, y$ m: }. _$ y4 N% c/ X. g1 F4 ~' [2 K

* \. B4 n4 O; W0 ]1 w
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 `! ]9 i$ P$ O2 j; U, B
& C9 V3 ^' E5 P: Y1 L; T5 S1 N2 I0 @
% G# d; y! ~$ J% S
DevOps
9 w2 R( ~7 D: `: n4 U) F. z* f% i7 A
! I! j9 U3 F$ ^/ m+ Y6 B
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.

7 g* D: [4 ?0 G2 N5 J2 f
' X9 X/ B0 s5 x
我的解读

( ]4 h0 c4 j5 P

, t; b+ |- L$ [7 c* m5 E
1. 敏捷软件开发方法
" d0 f8 M8 I! S

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

' w+ I; Y2 N; `, L
8 K) z; s5 E' y$ m# O: S
在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum 及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调「敏捷宣言」和「十二原则」了,只在培训课堂上还能听到。

1 x, K% q3 C% s# V
/ I5 K+ |5 ~2 G
2. 持续集成
" D- i6 H9 }- v& ]' b' b, y
" }$ V% q" G7 h1 x, s
早在1999年 KentBack 的《解析极限编程》一书中,对「持续集成」这一概念就有提及,它是极限编程 XP 方法中的十二最佳实践之一。在2004年,Martin Fowler 发表的一篇博文上,给「持续集成」下了一个定义,并一直沿用至今。即:「持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。」这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫「极限」二字了。

- P8 \' j' z! i: i* t! Y4 l
8 P, Q0 w4 T/ }9 I
3. DevOps

5 X- c" A: B! g% b

7 g1 D: O7 ^$ c4 k3 H, L3 ?
在2008年的一次敏捷大会上,运维相关人员就「敏捷基础设施(Agile Infrastructure)」展开讨论,并在2009年以后逐步发展成为一场大规模「运动」,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让 DevOps 多了一些发力点。
5 m( `1 `8 y! g$ `$ y& ^

3 W  C0 U/ ^! d% m
4. 持续交付
% F& J, D) j- L3 V9 X
. z0 d( Z5 A" D* I' A) h, }/ R
Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。

( u$ E3 m# ^2 s) C

# o% P7 U! o8 s. ~
它们的关系
2 k% Q) R5 ~3 t
* ], y+ g( _9 a* s; L1 Y. t- _# A
1. 空间与时间维度

; S9 {6 ]0 S8 k8 Y1 {) [

. z, t4 |" x+ Y2 ?
根据以上的信息,我认为它们在空间和时间维度的关系是这样的:
1.png
9 i4 n4 h, R! ^& }' P
7 |" f4 j5 P* |' G- o
$ y) r7 K0 ]  R" u; t, F1 n
上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?

4 r' x- b9 a) P, H' x# i

0 O9 X4 C* O- S5 G3 W/ y& X
2. 人或组织维度

( f% x1 }9 q" o4 S: b& p5 L7 b( T: b' i

. p& R' U0 r) g% |9 x& M0 q
我的微信签名是「别提概念,只解决问题!」。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里「所有的问题,都是人的问题」。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?
1.png
7 l# ^* @2 a% A

7 s, N$ E: m( V! C# z: }' a2 @
持续集成,有助于打破开发人员和测试人员之间的「墙」。

2 G( d8 L6 Q" M! x' T

7 @- t/ g" B: d
敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的「墙」。
; M( _! s. R& n/ _/ K

  f/ n, L: J# r3 I
DevOps,有助于打破开发团队与运维团队之间的「墙」。

5 o. S2 ]$ I# d5 W$ h, W9 v, ?
7 g# _: e5 s( Q- _
为什么从「人」开始

- r" i6 s, P8 ]' h

" b. W4 L) j9 O1 j' J4 q
在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与「人」相比,技术实践并不需要太在意,即:最好还是先从「人」的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。
: f" O$ N$ t5 Z
( o& _( k5 p" X5 B- d% I7 O
从哪里找问题

* k) K0 t9 Q) e! |

3 I9 R/ s& G- ~
从参与者的问题陈述中找问题。比如:
; R7 S7 V# J6 J+ C9 y9 x& H

1 E% R2 T( }# a- X" ]7 o5 y
老板:
# e# @* P3 |/ R: p; s. @+ e! _
  • 「项目经常延期」「做东西太慢」

    : v; S8 z# M3 S% w8 C* |+ C, m! T

$ t! B2 L: X5 m" y5 Q% h% K
产品:

7 P+ x6 I: N) t" z

0 |4 }( \# j+ f; q! K+ ?
  • 「老板的想法总变」

    , y$ U0 O) ~/ Y5 D7 l0 t5 X

; M) t* ?3 [/ C9 H+ U) e5 z
  • 「事情太多,忙成狗」
    * ^9 k! l5 {% E/ R; p" i! y: b
1 \% U3 u- ~7 r2 e0 E5 R
  • 「开发说这个实现不了」

    ( R, o" {+ {( p1 Y
. |, o$ I* N' _$ m) Y
开发:
5 d& c& `) g; O" K& w( X1 }
  • 「需求总变」
    0 \2 {; D. ]- P" {5 P
" o+ b2 U# S/ s
  • 「UI 方案给的太晚」
    , J+ @7 z0 _0 {) }6 y3 V

) y# ]  `" O' f4 B, P

/ p' f5 A- j6 c8 s, U
  • 「活儿太多」
    5 ?2 f# d9 `' F$ n1 N
) G- y/ x8 m# z! @/ |
测试:

$ x9 l9 Y# x, L' D

3 L2 w/ r7 I" A5 ?
  • 「需求变了没提前通知」
    + U: c  p* ]/ \$ C
6 q! b$ c; A3 L, K  m. N$ ~' ~' v1 }
  • 「测试时间总被压缩,还要背锅」
    ) N+ i# @2 j0 u/ q" A5 ^
. t/ n; Q% V) Z

9 D3 X: P8 v2 t- P
  • 「重复测试太多遍」

    ) q3 j- {+ l6 m& p  {0 g

5 K9 J7 O2 O+ @+ _: i, z
运维:
1 W0 d/ l7 \7 N; G1 l$ V$ n
+ a! W$ v  h% b, X
  • 「每天这么多版本上线,活干不完,出事儿第一个背锅。」

    8 N8 H3 E9 x  Y  }( [% ]9 Y& E

6 L0 t* x+ n  J) l
每句话的背后都有很多含义。开挖吧~~
, L: B2 {1 D/ @+ R
  |" p$ ^0 U! E( ]8 D
提问题的人是问题的创造者,也是接盘侠~
% W( q. [; y+ p! k
: i$ o0 w6 }$ `
  m. b  G+ Y) n8 r+ k' B
从哪里找解决方案

. j4 H3 }& _3 S! {' ?" y

6 f! O# T. J* n4 b
在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:
4 Y1 n0 I: i# e( q" i
! c: x9 }/ L& h, o0 R
  • 构建管理和持续集成

    0 V! i1 t; f  R& `, v

4 f; ?! [# G1 N0 _

; V, y0 z' b0 q  b$ X- [* t7 E
  • 环境与部署

    . D3 [9 L  X, ]$ g% A

1 Q5 _; B" K6 q
  • 发布管理和和符合性

    ) {6 {# Q* a3 `; C

7 D# l# K- y+ `) b( E/ h
  • 测试

    7 l+ N! L" h2 n: m, c) {( x* {& ]

! \" O# @( [+ O
  • 数据管理
    - |; V+ l: S  x3 D1 s* H

& Z' }( Z8 t' m5 ~# m( G6 t
  • 配置管理
    ' V2 O/ Z: }0 Q: w3 n* d9 [

0 K" F! V2 B1 B: M- m' k7 z3 P, P/ E
通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:
" Y2 n/ y( O8 T8 P5 I4 C
1.png

  r  k( `8 j: N# }% S
我也没有称其为成熟度模型,而是「持续交付七巧板」。

7 |/ l# q; p5 Q# E. `$ W4 ?

$ B( _# E& B1 O! x' l# C
是的,中国的传统玩具「七巧板」,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。
+ }) G* [: g" X6 G7 F' _  Q
2 m% Z+ k2 O/ ?7 Y7 R* J& ?) q; ]
找正确的问题去解决
" A7 `9 A0 O& p4 B* r
7 m' h$ r! E8 ]' A
上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

  R& y8 q9 Z+ Z0 x; ]$ M$ l3 G* j" t

8 i% B7 P1 X; D8 ^
  • 怎么做持续交付?
    ( d# b- s& Y) b

/ Q- E) z. A! D! B2 c
  • 怎么做持续集成?

    / o' a7 L' d( E% C. U5 [4 c

8 x! ^4 K8 ?3 b2 `3 H7 e
  • 怎么做敏捷?

    $ j9 b, ?2 b/ R. n0 ~' i# R
/ E) `, {) R2 g2 C6 K9 ~
  • 怎么做 DevOps?
      x3 [, f" W1 E5 H7 h0 f" |

; E' }' t2 ]- u6 }6 B5 X
我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种「捷径」
2 j; r& F7 E0 t/ G" X$ M; P4 i

4 X+ q5 U5 e9 r1 ^4 N. e, v
  • 我们做的是敏捷吗?

    6 y" u8 ~: [- g) r! n( \+ ]

, E( g4 C! e9 @. j0 C
  • 我们这么做持续交付,对吗?

    ( E9 s+ t6 k& Y3 i, @+ V7 Z7 B* [) t

8 g7 W. H( r2 U+ x3 G
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?
/ `3 O2 ^4 j( K, h& V1 ?5 p

7 [, k5 |" j+ [+ C
  • 你这不是敏捷?

    $ f+ x5 {6 J- Q9 P1 R

8 O# Z* T0 U; i- e( ^
  • 你这不是 DevOps?
    + }7 `( t8 ?! {# l* U) i6 Z0 p3 H
  G4 G" q1 R7 a: g$ Y# o" N
  • 你这不是持续交付?
    , K# e% w# V. l: E* _7 P

2 a; w" B+ D" ~* S% @$ j
  • 你这不是持续集成?, N4 ?. d8 ?2 Q
    : k2 d, @* e, c! Y5 ~
$ j" h4 v- h# u* g& ]
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~
' ?9 V% _4 M& l/ v" t1 a& e; O5 y5 R

* q! u- n: F  ^1 c
再炒一炒冷饭

2 _' _8 Q. Z" V- g

  n7 `% A3 k1 I4 L
2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:
0 K$ i& ^& K$ j& y& p
8 [: o. g  B% I" y- G2 x. N
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?

" O# g  L5 S; i8 z

# Q  D$ R8 ], r- h' j
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。
! w) I$ G" u- r& Z5 K1 L

2 ?" z  t  R2 A; _: o) Z6 o5 f
2. 标题党啊

; {7 I4 M6 L7 @: U% i

: G3 k' n  h$ T& E0 ^7 i! V
好吧,我承认在那个很少有人提及「DevOps」的年代,我就做标题党吧。

( X! A3 D" b& }3 ~2 O- M1 F! t) }  [

2 A. t6 r. q) H1 F) s+ r
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。
% M* u' p& }' _7 z0 R- }
& S. r" i+ D$ _" @. o
一、了解环境背景

8 A6 B& F7 @% p! t2 i

8 k: |/ W  M; G& s" H6 x  X
当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

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

: g8 Y, F5 E1 S2 E
3 C5 A$ }/ n6 Y& t1 w
团队间接管理者
9 P* p& T% d; R$ S

$ W1 d* p: X4 m! i8 x" @! }
  • 项目交付不太可控:

    0 I  D0 r! h) ?! C3 v
7 _3 i) q2 [* K/ s, S
         我们一直在做计划,但计划性非常差。
) y5 J3 |; @- \& ]
+ s7 Q& O; Y" J. q! f5 Z/ N; o
         经常有各种各样的情况发生,总会让项目改期。
! k4 d5 q; V) E: P- P( R) J6 A

8 N$ {& n9 Z, W3 V5 M' ^
团队直接管理者

) h% @" \  p! x
# }( _3 a7 ~- N! n% F+ O5 n. D
  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。

    . Z( ]. P! p; b6 I
7 p8 @$ k6 ~1 G8 K6 N$ X
  • 这个项目中,有一部份需求必须在XXX时间点完成。

    7 A* ?# {9 [- Q* p5 e
' i, }/ ~' J- K  N1 Q! L- O
团队Lead

: s" P1 o( M) U0 v

3 J2 H* c/ @& T# i- ~! o
  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。

    ' K! v$ `/ ~6 k' i  c  c

+ W$ z  z3 n8 ?. ?
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。
    * @) |4 }4 v; S8 f7 x8 h, ?
. D- m1 n  W0 t9 E. e. v0 _
开发人员
9 a: \) T2 N0 y! |/ D
' R, K4 z* `2 S2 B
  • 领导说试一下,就试一下吧。

    + V$ f9 _* P0 [/ Z; y1 ^) O
    + L) T, [3 G* K: i  C$ l, Q
测试人员

- {& M3 P& R* S: s* X

. c3 n4 @$ ?0 m
  • 工作经常被打断。
    7 c" a6 L# x) [2 D

2 h" W* p$ @- y. \' N

, h) Q( A0 i  Q4 z
  • 提测质量不高,经常浪费精力。
    $ Z9 s  N& @$ l" m

5 o! Q2 H! H9 a/ g- S1 n4 q. |7 C
  • 出了Bug,影响太大。

    - \' e3 i2 J5 P

, v/ q3 L, j' {6 L' T
  • (这里省略一千字)。

    , T. k1 _: P* i
4 n6 @& P( W* ~3 l
二、找到正确的问题来解决(目标)

$ Z7 `+ s& g  h9 {% ?

; k' a% I0 z' M5 s$ T0 v
三个月内:
! }' |6 M( S  k. @# C0 Y0 [7 D
6 w/ S6 _9 T5 \3 @; Q" i' C5 A
(1)该项目交付时间可预期。

7 ]4 a1 k: v7 i& }  z+ J

6 d' U2 A4 p: q9 T2 m, v* A; F
(2)建立新的软件开发协作方式。
5 Z% {; |# l6 ^4 M! @+ K
/ t: g1 K+ |  R: N9 N2 y( L0 u
(3)建立必要的基础设施,以支持后续的持续发布模式。
3 e) F4 ?) |$ _/ B

4 |9 e% g, t! w
三个月后:
0 w9 F, z8 ?& ]* `. e
# P8 v# H. ^1 L# [0 n
(1)需求的周期时间缩短,可以短周期上线。

( k4 H4 D6 j" J& Q
4 K1 e3 E8 b. G5 b# c
(2)生产环境的质量不降低。

, k/ w% J) z+ z+ N( j2 k
( i7 J2 s4 E8 V! R! |. b1 P
(3)测试人力总投入降低。

( b: O  k7 j) m0 s3 V/ [

* J: q3 b& R! t- [# n  }- p2 b" F
在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)

7 r9 o* O8 g6 v/ V: }# a6 y  g

" M3 Y; @, O0 g) l0 t
1.通常行为的改变,需要一个半月的时间;

! V8 f$ ]% @9 b! J

' u/ j9 Z% Q, p: L8 a
2.带来强烈可感知的收益需要三个月的时间。
1 p0 n2 J2 r, i! W
4 r8 d8 l* p: J" j$ c- w: ?) i% V
三、承诺是必须的
  R$ d* @! j/ j6 x$ b

! F2 q6 `8 U- z$ X+ |
上面的问题(目标)找到了,也要一并承诺。

  g! a9 d' ~1 d- S" N- W0 ?
% d6 p9 ^8 m. y0 p5 W
要想让团队和你走,你必须站在前面。

% H! C9 n$ G$ h1 }$ Y1 B8 j: j

1 e% n+ S* w5 D0 ?6 t6 [
四、培训及过程指导
6 ^5 l' \; B" i# a$ H
9 T/ f5 X4 m- N" U6 G/ ~8 w4 i
需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。

  X7 `" X$ j- L8 d

0 o+ E* X, b* o* d* R
启蒙培训(1小时)
6 ?1 x2 [9 Z+ |, t% d

- d* g1 L1 T3 I4 S' c3 m
对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。
) @$ M3 |) y' N+ _* i( d. }

! j$ d" u9 `% S0 H- n
2 c# t" }* {$ y. \: U
重新定义工作流程

7 l0 V% G' b+ n6 l1 Y8 g
8 |6 z  i: u: J9 v" ?
  • 新的项目工作流程

    0 E( _+ L+ X# l8 F3 L% |4 a. U

, H( }0 w( c* K. }9 R
  • 新的迭代工作流程

    + @' @# W% n; d2 g8 H3 H: |

# ^, j) {$ O$ q9 z- P7 _
  • 新的需求工作流程

    ( n7 v0 T9 j! _# M% O+ L2 w
1.png

' {: a) D8 @/ x( ~' U. I

. d7 n8 E/ ^, t1 X3 L

1 V% H# P) `, j( `
  • 新的代码工作流程
    6 W' ]* f0 ~( w( z4 j
1.png

" E' `" U: N2 a9 c

" l! j. x6 ]. {1 b: @% j
( Q, \- l8 @0 l1 z. O
解决新流程中的障碍

3 N1 _# V/ s6 H- @- ?1 D- X

: ^& T5 N6 F; s: b8 g2 C3 Z# l# Y
  • 团队沟通和协作的方式。
    4 y4 F3 ~# j* T6 W& K

) B1 X# u6 `# G% D  M
  • 编译环境的准备。
    ( O. V" E' F  s. @) w

# V: U2 J5 ^9 Q& A
  • 编译时间的缩短。

    ! }# y3 M( I6 l; A2 J3 A$ j, S  v* p
- C$ `5 R0 a4 j) ^* O% [$ T# j
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。
    " {! d% Y7 _- j) g; }& m- G

    ! ^1 @# W$ l. U' S5 w, G
1.png

! c% T7 x# S  l7 h' h% O( X
) B! i( p+ D- R* a2 G1 z# _& Z
  • 自动化测试运行的环境的准备。

    # m% I0 ?$ L- @- d. {4 m7 `3 a
; z5 K  a/ D/ y- r8 y$ M
  • 自动化测试编写时机与自动化的利用。

    4 t; C, w5 S7 m5 m' d6 f% Z! w

" [) d: h( O8 G* ~! v" }7 a
  • 自动化测试用例代码管理。
    ' o! K0 w, h' o7 J  Q  _* y

7 ]- U9 e5 s8 A; a$ B  t# E  j
我和运维人员的对话(真实的场景再现)
& {8 h+ d+ \  a5 ~

2 H1 }* X' F  A* T
我:我们团队想每两周就部署一次服务

6 _% r3 K  l' L

, N9 B' m0 F  n+ q1 f
运维:不行

6 L/ N1 r1 i3 M1 m9 m3 z8 {

. ]" X$ `) q- c2 }3 {# }5 {  S- i
我:为啥?
/ S$ G7 l& v$ }, g% e! {( R2 }

5 H5 b: ?- u( m8 `- v
运维:线上需要稳定

0 ^; s% B* T" A" r. s. m3 a

4 V7 A2 |9 w; g) h
我:每两周部署一次,就不稳定了吗?

) Z8 l/ c; ?+ W6 }
3 N* d) o) q8 {
运维:原来的质量太差,每次上线总是出问题
. m! ]$ X+ @! u5 p. c! X( g& o3 p
  S4 J; s1 H9 R' r
我:现在质量很好

6 Q8 W. U7 N" M$ {. p2 `; k/ S* E& `

  A  s, u' N  T+ ^
运维:怎么可能?

4 u! U6 k, u1 t5 _% c/ E; n

4 v- Y6 k' o; |& i' I& ?% Q* E  X
我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足;

3 ?# P/ @- X$ m. e

* m: d; b% ^1 n8 W  b& q0 \
运维:那也不行
% O7 ?4 y9 X( S- {) [6 L

9 d1 B/ q% D9 A
我:为啥

3 {; }- i: c+ C9 M
! c1 k. l8 n1 `: F. I- t2 N) R
运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?
, E* ^: x6 C) y- t( b% Y, C

& e3 Z: l4 h4 ~) Z
怎么解决?
: |4 v* |0 f! m) }8 O

! T/ l! V* ^1 `
8 f8 O/ r$ Y3 s! p) S( n6 `& n
改变部署方式,让他的工作生活美好起来吧~~~~~

3 a. d7 b8 }3 B* _
1.png
  k8 g7 T7 q; S) U6 T
部署流水线的建立,要求一键部署

/ A# R" e/ v  v6 `3 H4 B2 S# o# l4 Z
6 m: f8 T3 j" I2 |; n
运维人员负责编写部署脚本,并做版本管理。9 C, E9 |% J7 u; \9 h! R
4 l2 h4 d5 ?! [8 I

  f: ~/ l; L4 e$ c! d- j2 D+ r开发人员在开发自测时使用同样的脚本。
: k/ g8 C* q2 h4 z' @

8 d+ D4 {" S" q( K
, V+ z7 ~8 U6 ^) g
测试人员在测试环境上使用同样的脚本。
7 {  O3 y! O8 L

0 Z1 p' l7 z, M' u

  o% S# _* l+ B% b运维人员在生产环境上也使用同样的脚本。
0 w6 Q" m  H( b# o0 Q* T/ o

. T+ z6 i' s" C$ I4 s
8 X( Z8 m# L- q4 j8 g- A5 T+ y
  • 原创:乔梁3 i  |7 l/ o- s* ~
; e4 ]8 X; B2 m3 ^$ M; Q
" N3 D  J) Q, o0 X" ]
1.png

本版积分规则

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

Baidu

GMT+8, 2019-9-23 07:19 , Processed in 0.156637 second(s), 24 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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