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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

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

参加活动:0

组织活动:0

发表于 2018-10-19 11:02:45 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-10-19 11:12 编辑
; h* E2 R+ P$ H" U
1 W* f* Y/ I! R6 W& V
$ r3 D' k. k5 X' P" j
这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! 「敏捷软件开发」,「增长黑客」,「持续集成」,「DevOps」,「精益创业」,「持续交付」,「大数据」... ...) x2 n% E4 ^6 U5 A- B! S# s

/ y: U3 C0 G7 o" b
, I- H+ u* t+ U) u8 E
OK,就这四个啦:
8 b1 _2 J( F  B5 o4 a4 n

% A% p0 ]! I4 d* A1 r" }
「敏捷软件开发」,「持续集成」,「DevOps」,「持续交付」,
+ m2 ^5 K+ G2 a* L% D8 ^

- Z0 ~7 D. y% l

* }$ d- r: N! s" V$ I8 F1 v  r
先让我们在 Wikipedia 上验明正身。
- \0 U6 M3 s) O5 L( i
- a! h- V0 h' P5 M  X1 S' ]) n! i
敏捷软件开发
7 X" i  J9 ^* ~  O, A! u$ ~
+ ~# N; T* c# g/ H& 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.

7 [( Q) D: Z0 @

6 }' R1 b. y+ N9 b0 X4 ]4 P# y' q, V
持续集成

, m  q0 d3 T3 ~, _

3 I2 O% P2 K* h- b+ E
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.: y' M& J' m3 |; p4 v$ c. N

; D* {" l$ M, O# P9 y

- L, b' E5 v+ y# m: I& n: X+ w& {
DevOps

- d/ N+ Q' `! ^, {
  X5 h3 ^$ X2 W) r! Y5 ]
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.
2 F% b! \/ c" t8 k* ^, g
6 q- ~1 }% G5 `1 T2 L
我的解读
5 \2 A. k6 p1 U/ C3 X
- c1 D* G5 u5 I6 `9 R  J
1. 敏捷软件开发方法

! R4 V3 Q% ?7 a$ \1 k( \' x9 g
5 B4 E1 i6 V8 a0 X' _" t& f
从来就没有一种方法,叫做「敏捷软件开发方法」。因为,IT行业中的「敏捷(Agile)」一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议)。目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线。
8 L2 T8 H0 o" y  A7 k

, Z$ o8 |7 S2 r/ w4 l- b7 S
在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum 及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调「敏捷宣言」和「十二原则」了,只在培训课堂上还能听到。

# C& b, `' R' d% k9 n0 C3 V
- n- I! p: s4 s; I7 O; h
2. 持续集成

9 i# F8 x6 O7 A

0 ?! F( @7 @' ~' T( z) X! Z% ]
早在1999年 KentBack 的《解析极限编程》一书中,对「持续集成」这一概念就有提及,它是极限编程 XP 方法中的十二最佳实践之一。在2004年,Martin Fowler 发表的一篇博文上,给「持续集成」下了一个定义,并一直沿用至今。即:「持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。」这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫「极限」二字了。
( g* Q+ j7 S% F5 A
( [: o" l& w$ Z- l9 B  i! D, g9 u
3. DevOps
4 j9 c7 ^# v5 J1 O$ c+ h) Q
. X3 O- U3 z9 {9 E/ s
在2008年的一次敏捷大会上,运维相关人员就「敏捷基础设施(Agile Infrastructure)」展开讨论,并在2009年以后逐步发展成为一场大规模「运动」,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让 DevOps 多了一些发力点。

, g9 o7 g+ K/ F0 N% y5 ~$ b+ g9 D

7 `6 m6 D8 x2 t8 A0 ~6 b
4. 持续交付
3 V* G- N2 Q6 z
- V( V* W% z6 n# {% M( f  Y
Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。
+ [* c% `+ z$ T, ~) A0 G
* s/ H- F( U$ M
它们的关系

2 J: a! S# R# I& {3 ~
3 ~4 \$ K0 E6 t! H
1. 空间与时间维度

2 s4 N* M1 S2 j5 g! a& ?

! K6 x: S. S" c) f6 Y* |0 C
根据以上的信息,我认为它们在空间和时间维度的关系是这样的:
1.png
2 i6 c6 H& T& _) _; c  |
, \; q$ j$ i" R# g
, z. p. f7 H+ D" L
上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?
6 s6 B1 t$ B: Z) \1 L3 j& q
. |# \8 s, }7 x7 b
2. 人或组织维度

$ U9 G; W# d: T2 X* m! f9 K
9 z+ c  }" z7 V+ G% P
我的微信签名是「别提概念,只解决问题!」。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里「所有的问题,都是人的问题」。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?
1.png
3 ^; s& x1 \$ z$ P

0 v* G4 h* r+ p* y+ m# ^1 [
持续集成,有助于打破开发人员和测试人员之间的「墙」。
: B( e, A5 C" u

# j5 J$ {+ a# w: G, s
敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的「墙」。

! u/ p) T  n1 s- W, _  K4 m

* ~; N1 U6 E8 E/ N, Y/ F- J3 K
DevOps,有助于打破开发团队与运维团队之间的「墙」。

5 A* \9 E0 i' Z, m2 ~. J
8 U8 |& W6 L" \2 H
为什么从「人」开始
0 j9 h; U6 M  E* X$ e

2 }4 y5 G3 \$ X: F4 j8 B2 O2 A
在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与「人」相比,技术实践并不需要太在意,即:最好还是先从「人」的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。
. G0 o& _: ^2 i& P  o% N, u  u

. M. }% P. `, n+ x+ ~' I
从哪里找问题
+ v& ^! I6 r! r7 E- C( `, ]& V

' M3 ]" X0 f* y; [( J% Y5 u: n
从参与者的问题陈述中找问题。比如:

  C, u+ ?0 i% B/ t
, o% f9 j* t& ~& q$ B5 `
老板:
, \4 N# c' S. T0 s9 x# T/ M
  • 「项目经常延期」「做东西太慢」

    , I( |- D  S0 @: Y3 b+ _4 k8 s

. ]! j7 D3 y; v; }
产品:
9 }- i# w- s7 U# ]8 ?
  N2 ]5 _3 V, \& Z- }  ^
  • 「老板的想法总变」

    4 o/ M5 c( ~, U( a& s

) ?) P/ {3 T, \
  • 「事情太多,忙成狗」

    4 t% r& b# e3 G
' @# M7 w" n5 [9 W$ g" g
  • 「开发说这个实现不了」

      S" C9 l3 l9 B8 k( T- f

# p0 [; i% L( W/ Y
开发:

; E9 L* N( i# E2 j% m( l
  • 「需求总变」

    / y- }* P( E: ?$ J& R& g) G& W6 _6 X

! {9 ]0 Y* m2 w  Z, E. d. _$ j; |4 L
  • 「UI 方案给的太晚」

    0 W8 Q& z% ]$ d/ U4 ]2 @

8 ^% `: l+ v2 w9 f. V# K! l: h, Z
4 \' y6 e! _* ~' w. N' z. H
  • 「活儿太多」
    + F9 [: H6 f) z
4 m/ B0 M0 }/ a1 ?" P  w
测试:

% ]2 s" f% t& N$ L

9 F' ]" p& l& q$ m# T: c2 y
  • 「需求变了没提前通知」

    2 x; j6 J4 E8 u0 @+ Q; b

; \: E% F; Z; V) \6 J, P
  • 「测试时间总被压缩,还要背锅」
    3 z& Z4 z0 j3 T, ^
7 x7 T& H/ m6 a, T
/ _5 n+ \* h9 @3 V- T
  • 「重复测试太多遍」
    % M  _( b* Q+ }# V5 a5 a
& O3 ~9 D5 h: h4 y8 {5 d
运维:
- f1 ]  D0 n. h* y4 @6 j1 h/ X& X

% Y8 @0 ~0 y6 g2 Z! A0 c- {( W' k" L
  • 「每天这么多版本上线,活干不完,出事儿第一个背锅。」
    4 N/ i% W" C* T& K
1 A5 A' `' M2 I: V
每句话的背后都有很多含义。开挖吧~~

  y9 q4 f  o6 K4 w
* O' K2 S  ?5 Z
提问题的人是问题的创造者,也是接盘侠~
: Z/ l8 P3 E0 r* ^# @% r: J
8 _7 J* `6 a- S- w% L" \4 e

8 |2 ~' V6 j/ h3 @
从哪里找解决方案
, [! E% d4 N# U1 f6 {  _+ j" B
- K7 o$ X6 J. G$ K; `. B
在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:

! `- U% W( [" [
( d5 I: ~+ L3 ]7 g( V! ^
  • 构建管理和持续集成

    - |( U6 Z  W1 J

% @' H* M' Q7 M2 Q& U1 ]& W& h/ d, t
, \* ^$ ]% o. J2 F( k
  • 环境与部署
    ( e: Q9 `4 Y2 F) G) T5 N1 f0 }  e
* d" S5 {9 ^# ^! a/ E2 x
  • 发布管理和和符合性
    3 A- `/ l" J3 ]3 H8 u% M+ O

( w  S( B) ~$ _9 g: l8 Y" {
  • 测试

    2 `1 g! w. w$ \, [# t1 v

( w% T+ H1 w& Z4 B9 P* o" |- \
  • 数据管理

    : {% K( r0 J5 p# x6 C7 R* V% a4 _

4 i9 o0 H+ w7 Z; t
  • 配置管理
    & v, ~5 `3 e5 d- l: ^; w5 Y  Z4 }  B

7 [" n. i, f9 m7 p3 t
通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:

# x9 R7 \) e+ [% i5 ]3 K2 E6 C
1.png
* Z! t; D# `+ X
我也没有称其为成熟度模型,而是「持续交付七巧板」。

* M& B! j: R  q& J1 v5 t! L

* D0 e7 i- {9 @" |, h
是的,中国的传统玩具「七巧板」,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。

% Q5 V" P: ?% a
/ l7 I4 P" B% g
找正确的问题去解决

7 a8 c  c, t: u: A  v1 |
& D# d9 v3 y% j8 d! M: f
上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:
& x% ?2 ^9 ]! q9 L3 {3 a2 O

7 k2 W6 k8 G  b2 Q9 Y4 S3 b! z/ k
  • 怎么做持续交付?

    ; r! h; I  v* ^  C& \7 X6 V! R

2 t/ V8 n. a) o. V
  • 怎么做持续集成?
    $ s1 S- ?5 k" H# H! {- ^

! }  |: l$ Z7 }  ?1 @8 G
  • 怎么做敏捷?
    1 J3 @" h: h  B( B! _$ O

. }0 Z9 k  A, O' f
  • 怎么做 DevOps?
    / }# l* l# x' c! }) J

0 Z/ L& p2 y8 K2 \9 f  j4 G( N, d
我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种「捷径」

5 S: f% X( v% |7 y& Y: W4 `/ N

2 E7 W' C: w6 l7 k; c8 X  B
  • 我们做的是敏捷吗?
    2 h7 q( U6 u7 P% V( z) V5 R
* D; Y+ E. t: q7 ?" B7 m0 [1 b) J3 I# n
  • 我们这么做持续交付,对吗?

    8 q  U/ s, e* n. |* k8 J( Q
' M. `* J/ V- u- `
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?

$ T: U% e0 \! b" j: V
( i9 H6 g' o7 K0 z! h6 f
  • 你这不是敏捷?
    8 ^$ e9 o$ V- f1 e
( A- M, y- B5 M6 f2 p
  • 你这不是 DevOps?

    + o3 \9 l9 `2 H

7 B3 _  |/ ^# X8 R3 d
  • 你这不是持续交付?
    3 _0 i4 C+ P* [& X7 Y
' H/ c) k/ x) {& V- s3 Q9 A
  • 你这不是持续集成?$ E" u* u& I8 N) y1 t2 \

    : n8 s4 b- Q7 r4 z) ^6 j
1 \" M2 w7 c$ E
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~
; o# |3 h- y) B; ?2 h/ r( ?
! f8 z+ X: l; a& x
再炒一炒冷饭
! l, k0 X) d: V# V
0 z9 @3 R  i! M$ I( d
2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:

1 l# A3 Q) F9 D2 I& y

. }7 p) a+ ~$ l6 t0 h
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
. ]* ~$ h5 T6 k+ C7 L
) W6 J% q# U5 \2 X+ g9 P9 s) q$ C
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。
( X; i+ D' P: C3 L, g( `
2 v; R3 H, |3 v5 B2 l: E/ O8 C7 o& @' P
2. 标题党啊

% O; l7 b7 W- p8 [
6 [# U! ^1 t* W* ~
好吧,我承认在那个很少有人提及「DevOps」的年代,我就做标题党吧。

% j. {- \) V2 C- _+ C  i* l
7 `& Q& a0 m2 P5 i
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。

1 F; y/ a: N$ U& x/ n2 m+ h
% ?, I2 A9 ^2 Y; k8 n" b9 {6 x* R
一、了解环境背景

1 L8 p: h8 @- y2 Z
) o5 |+ F$ A" T7 {( g( E
当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。
! u, M8 \# C. Q- z8 C/ W9 W6 }
9 p5 s0 X& U1 T3 y8 a
几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从 Google 跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。
# r4 m$ x  p6 k3 k3 J8 T

3 l4 C' K1 ]6 I- O) a! t
团队间接管理者

+ g+ P5 S3 W9 u/ Y
9 B5 L3 K0 f/ D/ V) |3 h! B
  • 项目交付不太可控:

    / x5 _3 u5 p& |, n1 I5 V7 d
4 g3 R6 q& S6 V) T5 ?9 D
         我们一直在做计划,但计划性非常差。
' }* q) J, O; I% k' @. M

* O' z- ]! U( C
         经常有各种各样的情况发生,总会让项目改期。
/ l6 h# X$ o" Q; q6 l8 y  R% d- m

) s7 r1 P: v! X4 X3 d: D5 I$ D& P
团队直接管理者

$ m  w* @' [/ }' B1 y
4 ~2 p( n% m& `3 c
  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。

    + a) H" {/ d& h! Z: i. U
: g' Y/ P! ?0 J/ t! z0 I
  • 这个项目中,有一部份需求必须在XXX时间点完成。
    4 q9 F* [6 w1 C9 H' z6 g% N, {

" ]& H$ \7 y8 O! V* t* P
团队Lead

) N9 K4 R' o6 M1 o
, Y/ o9 f4 A' V) Y# L. e
  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。
    % Y, v7 ~  V( k! C  y6 R
4 M0 \( w1 y9 R+ e( [9 G* U
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。
    6 g. S/ I4 O- O
9 _, ]3 s* P* u4 W( ~4 t- T; \
开发人员

1 b* n: M* l1 U+ c  X8 T7 N

7 O/ \3 W/ O" \4 v) i4 ~* k7 `7 ]( e5 o5 ]
  • 领导说试一下,就试一下吧。
    $ h2 U1 E; i7 V. i9 c# E

    1 }! L1 m* m( Z) b4 a0 u
测试人员
3 I, w1 W% I8 C' \( B* S
6 O, O( z1 U  H9 ]7 Y+ X! Z
  • 工作经常被打断。

    6 ?2 f/ ?" _3 z' f

% }) L4 z0 ?6 I

! L1 G: A6 r! S
  • 提测质量不高,经常浪费精力。

    " @# f8 Z6 E) A/ }$ z- L, M3 I
+ A3 ~- j! x! p) N# I+ ^
  • 出了Bug,影响太大。
    ' X& G( [$ [. M5 ]' A# \5 o

, m; ]/ t2 u# J. }8 [5 |' P
  • (这里省略一千字)。
    6 Y! u8 r! Z4 G
: i" S3 N6 J8 M8 e) F" O
二、找到正确的问题来解决(目标)
6 X5 O) |) Q$ u3 m/ J5 `
; b3 O: J: H1 R" Z6 p
三个月内:

; T0 Z, D, X4 C; b

1 f4 Z& k6 K2 R3 e+ [5 n
(1)该项目交付时间可预期。

$ z, o3 J, V. M. ^0 {
4 t  ]+ i' n/ S) x& e$ O
(2)建立新的软件开发协作方式。

) [8 o6 ^' u7 t
1 s  c0 J7 p0 N6 \
(3)建立必要的基础设施,以支持后续的持续发布模式。
2 T7 n- v8 K- b  Y
( {' a8 p0 G. I) ?3 I, J: F
三个月后:
% E( }/ d* ^, |( s- ?  Y' t

2 ^$ W1 N! E6 p- b8 K; ~# ~
(1)需求的周期时间缩短,可以短周期上线。
6 d0 |5 l. j& c2 ?6 [2 f# Z
! C  n. z2 |( Z
(2)生产环境的质量不降低。
7 n3 M, L1 M* d  E
+ ^+ m& l! ^$ ?! X9 n- Z8 d3 k2 a
(3)测试人力总投入降低。
8 Y% r* h, d* I5 e: _" g  T% c' u$ ~

% c' f0 o: G( l& K* b
在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)

8 A, G/ K9 ^+ ^4 {  u3 F

. n" u  A0 P" k& a+ ~$ _" H
1.通常行为的改变,需要一个半月的时间;
& Q( Q/ F- G  ]$ Q7 D# x
: @% N/ p, z! b, s( I
2.带来强烈可感知的收益需要三个月的时间。
  X5 O$ X  h. v8 x9 M1 a" r

$ B: z9 Y4 _, H
三、承诺是必须的
$ x/ W3 {& j% _% r" _7 t

- r& L# \! D& c# J
上面的问题(目标)找到了,也要一并承诺。

& O7 R7 H6 U+ d* x

; y* J% L* t5 R4 @( ?2 A% p
要想让团队和你走,你必须站在前面。

) [! E0 {( f; B' R' E4 w" J6 ~
/ d$ v- n# ?! `* L  X3 o* D' I3 V
四、培训及过程指导
2 U9 }5 f7 ~! Y+ [9 o" l" H
/ P0 P. z; G. C1 G+ e
需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。

0 R: W8 \' d3 D( }

% u" h1 u1 A  o5 P  P% u& K
启蒙培训(1小时)
/ y) Z5 k* Y/ E$ t% A/ c. b7 ]- H' J, ^- a
1 h+ c2 ?) U. N' ]7 G
对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。& I6 l/ ~* Q! ?  A$ {+ ~- u

3 d$ a2 n" c4 c5 n6 B. R( `# M

* E; ]% I% L5 }( t& ^7 h
重新定义工作流程

7 m% \$ h6 v* H9 x, n
" }7 W! \1 O; q* h7 d
  • 新的项目工作流程
    % @; B* f& z- T; [2 Y

( E; _, ^  M  Q" z# z( A) S  e; ]
  • 新的迭代工作流程
    ( J$ K4 f" I7 W" ~; p5 e* H

8 j) b! `) a' @2 v& W
  • 新的需求工作流程
    9 Q) B6 ]: z3 r2 S; e
1.png

  y' O. s* U4 H( a2 [: ?0 q; Z* c5 z

) r7 a" r2 S4 K; @

0 k2 l, T% Q. m+ c8 U" D
  • 新的代码工作流程
    # Y. ^  A8 A7 l
1.png
7 ?* u4 h" y) A3 J

/ C! |# D* X& [- [1 `! M8 E5 I

% ?4 }9 c* t2 W/ L& D* k# F' Z
解决新流程中的障碍

' H. V* i& j' N6 z! q

% ?  ~+ m, q2 ]5 p; u- a
  • 团队沟通和协作的方式。
    + Q# Z$ P' i( I! _3 \) P9 X

+ V& J9 s" u+ x6 m  |! D$ [
  • 编译环境的准备。

    ! r; x! H# `( ?! b+ n0 B+ v0 \

  m( q. b/ J# t- ]: o7 W
  • 编译时间的缩短。

    2 p+ B" o0 T$ r
* q, C  \( V" Y* f9 l
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。
    & k; {; G3 ~/ _  D% ~) L
    , `7 \2 x+ c0 ]  @0 q+ r
1.png

0 v/ v, i3 f5 _
4 v+ ~6 ^6 s  \0 G; ~. U  Q) ?6 i
  • 自动化测试运行的环境的准备。
    ' d, x! l4 t+ `2 u4 L9 O1 V
+ p: A6 C: H9 \/ c
  • 自动化测试编写时机与自动化的利用。
    ( o- x' g; y1 z4 x

0 d6 g6 h1 P" Z7 o
  • 自动化测试用例代码管理。
    ( e7 s: n# o, S* B. \7 K+ A
, E  i* e; V: `6 y0 e$ s3 J
我和运维人员的对话(真实的场景再现)
8 j9 @5 _6 u' F8 C" }: O/ f
& @4 z6 o/ ~& L% E4 f
我:我们团队想每两周就部署一次服务
2 E8 [1 n+ }( V: M
( g4 d  \' s1 ?% b
运维:不行

, T0 v) C/ g- `, A7 u
3 @& t: I2 l% N& J- j; j: e3 i
我:为啥?
" g, X7 G4 c. i, N/ O& l, l

( E9 r2 l+ [) K( J
运维:线上需要稳定
3 l, l3 Z# `+ c5 ^2 ]# X6 E
6 |  v7 W# Q/ B* E& T: h, ?9 H3 V
我:每两周部署一次,就不稳定了吗?
$ ^% _& V5 ^, c& C0 Z4 ]

' s+ a) P# j: i* v
运维:原来的质量太差,每次上线总是出问题
. J/ l0 k0 ?1 v
2 N% z7 W" O+ o1 F- ]6 d
我:现在质量很好
  u' p! M* Z9 c6 y6 h7 i- H

  H" f7 L/ u2 _& M6 Y# _3 o& y
运维:怎么可能?

5 q$ m* N' J9 w( H2 g! o

5 t1 r% u- C* J$ F3 L" F
我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足;
7 ~" E! f9 H& r: c8 g

7 F. N: S# S& S, C5 @* b8 v
运维:那也不行
( x. `- w7 S# W! c- p5 }

5 v0 G: h( x- q
我:为啥
) Q* x) M# u- e. A: i4 T9 B% p

' W- n8 ?# ]2 v2 U6 \
运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?

* H2 J5 f9 h0 ^; C7 ^& q

0 z6 B8 V. I% S$ I; H9 i3 a
怎么解决?5 R# W) h* z; f; o. b0 X! T; o5 Z

/ l: Y+ [1 ]3 b. X% a* l0 [
4 b& l+ Y0 w% ~* G" M- ]
改变部署方式,让他的工作生活美好起来吧~~~~~
5 m: F$ F0 f0 Z: ~
1.png
$ b$ y' G- B$ e1 B
部署流水线的建立,要求一键部署

, @2 S- D$ O+ f+ X$ d/ O& O8 v: D; |
4 s/ Q: T& w- h3 n9 w$ f8 F8 S$ w
运维人员负责编写部署脚本,并做版本管理。
5 G' F# u# a: _, e; H! D

9 q4 }$ [6 i6 C6 v
% }) f8 G4 U) F" i开发人员在开发自测时使用同样的脚本。

. l! t& n6 c; h" x" s
. `" t$ F$ z8 A) D  Q( O5 X0 q

: a* v7 O/ b3 E( [# d测试人员在测试环境上使用同样的脚本。
9 Q5 f) K# h3 y+ _% D( Q

2 t; q* ?2 P, r. k1 e7 s
. r( M6 W1 J7 d7 D6 G0 z
运维人员在生产环境上也使用同样的脚本。

' t8 u8 k9 ^* q5 q  v1 ?( J) K7 s+ j9 b+ j" \

5 N/ z5 a5 z$ B/ x; s' h4 _
  • 原创:乔梁
    4 G1 C4 w3 ?  R  o/ f2 ^8 p

$ x/ F; I5 ?' R& e2 x( f& Y: Y. ~- ~6 F$ p! {
1.png

本版积分规则

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

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

Baidu

GMT+8, 2019-2-24 14:10 , Processed in 0.266656 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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