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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1068|回复: 0

持续交付的实践与思考

[复制链接]
发表于 2020-8-3 15:07:02 | 显示全部楼层 |阅读模式
本帖最后由 陈小宝 于 2020-8-3 15:10 编辑
4 z+ q" a# P; Z+ [+ D" u! S
3 ]# N, _* z8 T+ y3 p9 u4 h
  ^( ^0 H% Z2 S- v# V# n% m0 T& ~" Y
粘贴上传202008031504209120..png
3 P4 b2 @  u: i7 ^" E
开始以为这本书会有一些偏理论,然后读过之后才发现有一种想见恨晚的感觉,作者在项目管理中遇到的很多问题正是我们也经常遇到的。
首先引用敏捷第一宣言:“我们的首要任务是尽早持续交付有价值的软件并让客户满意。”
5 u; ]# K6 L4 o: X( Q2 O# b) s$ T& u( C

2 h& n( o" W* H% s' ?! R* P2 _% t" p
5 F5 D, }# u3 R! L, L
常见的发布反模式
  • 手工部署软件
  • 开发完成之后才行类生产环境部署
  • 生产环境的手工配置管理
    + H9 N: Q' F8 d* x

    7 l7 @8 T  r' l* S! O5 x7 V
; p& f( n/ `$ `# S8 \; ]
配置管理
/ B  p7 B+ U7 T/ E. T
   
9 w0 U  H8 O7 \   版本控制
" U0 x) b% O* N* Q) E; ?! {, m7 D
  • 对所有内容进行版本控制/ i9 X) |' C" W- V7 Y0 Z
    • 不只是源代码管理,每个与锁开发的软件相关的产物都应被置于版本控制之下
    • 不推荐将编译后的二进制文件纳入版本控制,
      - A7 ~8 _8 N& h
  • 频繁提交代码到主干, 为了确保提交代码时不破坏已有的应用程序" h" X& r4 N2 ?2 @, [
    • 一是提交代码之前运行单元套件
    • 二是增量式引入变化,建议每完成一个小功能或一次重构之后就提交代码。
      9 v; v+ x; T! {" P
  • 使用意义明显的注释,注释中最好包含一个链接,可以链接到项目管理工具中的一个功能或缺陷。
    % Z5 B# m8 Q8 y4 }
; P, `- G2 u! [! m. |: v
   5 N8 a* |  U4 {! u, C! d
   依赖管理9 u1 n8 d$ W* l; A1 Z* w
  • 外部库文件管理 * 应该始终指定外部库的确切版本
  • 组件管理
    * d$ U' q) K6 W0 n5 D3 d
: _+ B5 ?+ c0 n) u# M! _. A' @2 c, O
   
- n# D8 `0 r6 [! w: q# O   实现持续集成3 A8 w$ Y- M1 r1 C# A' n  y- p
  • 准备工作
    1 |$ z; ?4 F( ~4 a; O7 K
    • 版本控制(git,svn)
    • 自动化构建(fastlane)% B4 Y& h3 ^' n) `$ G7 z% r* r6 P
  • 持续集成的前提条件
    3 B) A3 t, i4 H7 l2 V
    • 频繁提交
    • 创建全面的自动化测试套件
    • 保持较短的构建和测试过程
      8 H" {3 T& a7 F  }
  • 必不可少的实践
    . F; c( K  g' O6 y7 @0 A
    • 构建失败之后不要提交新代码
    • 提交前在本地运行所有的提交测试,或者让持续集成服务器完成此事
    • 等提交测试通过后再继续工作
    • 回家之前,构建必须处于成功状态
    • 不要将失败的测试注释掉: R' ?, Y  j. a/ \; a. g' ~5 }$ c

0 h1 X/ ]  G( K; H+ V+ j

9 W3 }- q- ^/ n7 d+ {

1 ?/ w  P; z1 m4 e. D- X# |   自动化测试中的测试替身
+ @. j- W% x) j0 F
  • 哑对象(dummy object)指那些被传递但不被真正使用的对象,它们通常只用于填充参数列表。
  • 假对象(fake object)是可以真正使用的实现
  • 桩(stub)为每个调用提供一个封装好的响应。
  • 模拟对象(mock)是一种在编程时就设定了它预期要接收的调用。
    + L6 s2 I! A- B+ V: O" e6 M

4 ]8 ?! W. D; q6 n% ]% z/ B

( z/ h. b5 m& h3 x/ j4 U: u
5 R/ o7 v9 P/ O+ H; a; g1 m
   提交阶段
$ q/ m1 Q7 }, H: b8 V
! Y* \! ?: |6 e1 {提交阶段是怎样工作的?' o8 ^+ y4 x; Q! p  ~4 M+ B
  • 编译,并在集成后的源代码上运行提交测试。
  • 创建能部署在所有环境中的二进制包
  • 执行必要的分析,检查代码库的健康状况。
  • 创建部署流水线后续阶段需要使用的其他产物。(比如数据库迁移或测试数据)
    5 D3 ~4 K0 x* i3 L" l/ k

" I9 o! `5 f- P" f
) F) l4 g  t  W5 @

8 D6 l& _( D8 L' E0 u+ j  x/ t提交阶段的首要目标是要么创建可部署的产物,要么快速失败并将失败原因通知给团队。" W8 c, \, S) w  d# a

      A7 z- Z# E- V7 Q. O
  • 提交阶段比较有用的度量项
  • 测试覆盖率
  • 重复代码的数量
  • 圈复杂度
  • 输入耦合度和输出耦合度
  • 编译警告的数量
  • 代码风格
  • 提交测试阶段测试套件的原则与实践
  • 避免用户界面 测试困难,耗费时间和精力 速度慢 * 可以放在验收测试节点处理
  • 使用依赖注入
  • 避免使用数据库
  • 在单元测试中避免异步 * 解决方法就是拆分测试,将异步操作拆分单独的单元测试。
  • 使用测试替身 Stub, 常常需要额外写很多代码,我们不需要关心桩是如何被调用的 Mock, 一般通过Mock框架模拟对象,我们需要验证代码是否以期望的方式与模拟对象交互。
  • 最少化测试中的状态
  • 自动化验收测试
    * u$ @5 W% P+ T- V8 ~3 I. z
  • 窗口驱动器模式,也就是分为测试实现层和窗口驱动层,这样使测试实现层抽象层次更高,只有窗口实现层才与具体的GUI打交道。
  • 我理解的自动化测试是:为了验证用户故事是否满足业务而编写的一系列操作过程,与单元测试不同的是,它是面向业务,而单元测试是面向开发人员的。
  • 如何实现验收测试
    4 ~' F$ q6 H+ m9 k1 S
3 [$ u. H6 m6 _
' C/ q% }/ j8 C% S9 {% j4 h3 Y0 z% m

- W/ K! E$ ]( y   分支与合并
, |$ |7 f: k6 Q# B
( ~3 ]2 v  |/ `% V  q5 d几种常见的分支发布策略:, I& W8 Q& B1 j1 I  F8 z
  • 主干开发;说白了,就是所有开发人员都往主干分支上提交代码。
  • 按发布创建分支;即当软件准备发布的时候,才从主干创建分支。
  • 按功能特性分支;应该是当下很多公司比较喜欢使用的一种策略。
  • 按团队分支;比较适合大型团队,为每个团队都创建一个分支。. f# {* R& `% d; i3 w2 }

, C) |" e& ^& \  n; K+ G

  H& s4 {' y) v4 X9 Z( ?) F6 ?

9 h- r' p( z7 f1 }! `" h' I5 h* u基于主干开发的三个好处:
" u/ ^5 ?5 D. W8 ^$ p
  • 确保所有的代码被持续集成。
  • 确保开发人员及时获得他人的修改。
  • 避免项目后期的“合并地狱”和“集成地狱”。
    % O. F5 _/ L; g$ r1 x) Y

2 m/ ~" D2 q/ f3 w# |
# T0 \) O4 D* V4 W
! i0 H( a9 F7 B# O( @) O- p. l1 q7 ~

9 ]/ x; h2 ^- B  H) i. o文中指出,“创建分支”与“持续集成”往往是背道而驰的,意味着说创建分支越多,就越难实现持续交付,因为开发人员都在各自的分支频繁提交代码,而“分支”上的代码往往在几天之后(甚至更长的时间)才会合并回主干,这样会导致在后期才会发现因合并代码导致的种种问题。(DevOps时代)




上一篇:10个最受欢迎的DevOps面试问题和答案
下一篇:实施 DevSecOps 的 10 项方法,看完这篇就够了
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

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

GMT+8, 2023-1-28 00:50 , Processed in 0.105211 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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