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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 51|回复: 0

持续交付的那些事儿

[复制链接]
发表于 2021-12-25 19:12:16 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-25 19:17 编辑   b; a4 m3 o. B- `% g: g: c7 ^
! b' L+ B, `: Y. y% ]6 E1 ^
粘贴上传202112251727055242..png

7 D4 e+ G% i) ], J: h
持续交付指的是在短周期内完成软件产品,以保证软件保持在随时可以发布的状态。让每一个变更都经过一条自动化的检验流水线,来检查每一个变更的质量,通过就进入下一个阶段。其不是一种工具,而是一种实践!
6 S+ Y5 j& }9 ~持续交付的共识和管理机制如下:& @- I2 W3 ^8 J7 z1 M" U+ A
  • 不要阻塞开发人员,这是实现持续交付的本质理念
  • 为每个团队指定构建负责人或者发布工程师:优化交付流水线,提升交付效率
  • 项目状态应该对参与整个过程(包括构建、部署、测试和发布)的所有人都是可见的
  • 做好风险管理

    ) Y  k- y- _# d/ s- `7 o+ n
    • 迭代增量式交付是有效风险管理的关键
    • 手工测试环境、试运行环境和生产环境总是需要严格的访问控制
    • 让风险识别成为每日立会的一部分
        }+ f& p% Z9 J

9 `' n. K& i* g- K* w' f7 Q
  • 做好审计

    % R1 U/ k3 n/ M3 c
    • 手工测试环境、试运行环境和生产环境总是需要严格的访问控制:指定谁能够访问“特权”环境。
    • 要求每次部署都要进行审计,以确切知道到底修改了哪些内容。
    • 文档自动化、自文档

      , q) x% s$ w4 {  w1 `. W
* X9 D; X8 N/ M3 H# K* ]
接下来先说明实现持续交付的一些基础设施和准备工作,然后从本地开发和自动化构建/部署流水线两方面说明持续交付的具体实现。
4 h; ~" ]/ G" w! u基础设施和准备工作
0 w- C4 E" T: u* |: R2 U5 L# S
基础设施和环境管理
让所有测试环境(包括持续集成环境)都要与生产环境相似:! Q$ k* h( j/ n3 J) M- I
  • 开发人员要把运维人员当做重要用户
  • 切忌吞噬错误信息
  • 使用运维团队熟悉的技术:开发人员最早负责创建部署脚本,后面移交给运维团队负责维护
  • 把创建和维护基础设施需要的所有内容都进行版本控制
  • 以自动化方式进行配置和部署!
  • 像对待生产环境一样对待测试环境!
  • 容器化技术实现不可变基础设施

    , h& E+ G2 o; e) o/ N& B

, Z9 Q7 f% A/ |$ T/ A配置管理
版本控制、依赖管理、软件配置管理:7 l/ L# G' h3 {- J3 l4 U
  • 各个环境的手工配置 -> 自动化配置
  • 对所有内容进行版本控制
  • 指定依赖库的确切版本,不要用快照或者模式匹配版本
  • 配置文件与二进制文件分离

    - ]+ K/ g! q- [; v( @) ?7 Z3 |

/ S, L1 e5 {" [% r; R测试策略0 e3 l: c1 K% E- d# U4 W9 Y2 x
  • 创建全面的自动化测试套件:单元测试、组件测试、验收测试,每一种测试的代码覆盖率都高于80%以上
  • 每次修改都能运行一次自动化测试集合
  • 分层测试
    2 B4 ~% x! W2 Z  U2 k! y3 ~

& m/ g! F% v  Y& ^; J数据管理
1 U" a7 `. w/ j! L! Q
  • 把创建和迁移数据库全部变成自动化过程,是部署流程的一个组成部分
  • 让测试自己创建它们所需的状态,并确保每个测试都独立于其他测试
  • 对数据库进行版本管理,使用DbDeploy这样的工具管理数据迁移过程的自动化。
  • 在大多数据情况下,不要在测试中使用生产数据集的副本。?
  • 数据库回滚和无停机发布
    6 F/ S) S# y' i- y. k
    • 蓝绿部署
    • 大多数修改应该是增加操作(比如向数据库中增加新表或字段),尽可能不修改已存在的结构
      5 i$ Q$ E1 h+ a* J; L

( C% ~2 a  ~) B9 M& L0 e+ ?
  • 测试数据
    6 m7 ~# t. C3 p! y& X7 n
    • 测试的独立性、原子性
    • 其他类型的测试,一定不要使用生产数据库的一个dump,除非有特殊情况

      " c- p  ?! N, T. ]

7 R' t3 W7 h$ c% {9 g
  • 部署流水线中的数据管理

    4 [8 o- B( C& t  [8 q
    • 提交测试:快速运行,避免复杂的数据准备
    • 验收测试:后续阶段可以复用
    • 容量测试:为测试提供足够的输入数据,可以看做验收测试的重复利用

      , A6 x8 d. q) S$ O# }3 I+ M
      4 Y2 B7 ^* u3 B, A

% S: }( |  N  l/ L7 D; a主干开发
主干开发的分支模式实现持续交付最好的模式,但为了在主干模式下保持应用可发布,需要做到:- S- J2 S" k5 ?2 Q# d
  • 每次创建分支,都要认识到它带来的成本
  • 频繁提交代码合并到主干
  • 新功能隐藏:功能开关统一管理达到特性隐藏的目的(Togglz?)
  • 增量开发:将所有的变更都变成一系列的增量式小修改,而且每次小的修改都是可发布的。
  • 抽象模拟分支(无法使用增量开发):修缮者模式,使用门面模式隔离待改造代码。
  • 使用组件,根据不同部分修改的频率对应用程序进行解耦。
    . X8 j% {& j6 o/ \% Y2 I& E

      e. H5 m, F4 z
  h! ]! D: {- `% h# C8 ^) f
本地开发& _- r! P' e3 H( Z
让开发者不受阻塞、不受不必要的干扰 -> 持续开发

& S9 A3 w; ^" k3 z1 k
粘贴上传202112251727481734..png
! k  T# \; p0 X* E) v! f. F
  • 确保自动化测试、构建部署脚本都能够在开发机上运行
  • 本地自动化测试:预测试提交pretested commit/个人构建personal build/试飞构建preflight build【保证本地开发所有验证方式与流水线上的验证方式一致,提高开发人员在本地发现问题的能力】
  • 提交前在本地运行所有的提交测试,等提交测试通过后再继续工作
  • 在可控的环境上部署开发的应用程序
  • 修复破坏应用程序的任意修改是最高优先级的任务,构建失败后不要提交新代码

    7 J* z9 u2 C! m* j% v
# v5 `9 w, p6 F  d/ c5 Z: s
六步提交法
0 q7 f: q1 p9 q8 f" J5 w规范开发习惯。主动提前集成;小步提交、完整代码、不影响已有功能;关注代码规范、动静态扫描问题:
8 d3 r2 F6 m1 \) p# l. E7 u" }0 R
  • 检出最近成功的代码
  • 修改代码
  • 第一次个人构建
  • 第二次个人构建:拉取主干代码集成后本地测试
  • 提交代码到主干
  • 提交构
    ; ^9 T# D, e2 y

' Q! G3 S3 G$ h- W( T" P提交不影响已有功能!!
# J! f8 M, r8 B
  • 增量迭代开发
  • 抽象模拟分支
  • 特性隐藏

    0 O/ U" u% `- ~8 U
5 b4 d5 ~3 H: m" j/ K; m. _
规范化、自动化核心步骤
" b9 C* D0 G; A8 F
粘贴上传202112251733523391..png

+ C5 S" X: N- F3 p; D* c3 c+ K
提高开发环境的效率:环境获取的服务化、自助化;环境的一体化、一致性:
6 H' }, j0 \( t
1、本地开发环境
- v5 D/ |+ w8 P: M# ^6 s  S4 |
  • 共享机器池
  • Git提交日志插入截图:Share Bucket+Google Drive
  • 远程开发机器/Web IDE
  • 依赖的服务

    % A4 w  A# d/ y+ D, r
    • 维护一个单独的环境,让开发环境接入
    • 服务虚拟化工具来模拟依赖的服务,Mountbank、WireMock
      ! n1 A/ G; W6 J
* L. ^& m8 a; w
2、联调环境:提供机器池,确保有两套空闲环境,自助化提供给开发者使用规范化、自动化本地检查:
& X- W: a( f: _) n- u2 A; i
  • 语法检查、规范检查、单元测试:Maven/Gradle插件
    - k$ x3 n/ C1 ]. D
9 `4 |+ x5 H, g' R% j: C5 f
3、建设并自动化代码入库前的检查流程
0 A) E* l( z7 |
  • 持续集成前的必要工作
  • 代码审查
    % q" k* r. p! r6 w% [8 n8 N6 D) w
+ c' |2 @3 B6 S( N
代码审查

, J! i# u9 u3 O3 m3 W人工代码检查:
7 {' T& X  s# e* w
  • 统一并明确代码审查标准
  • 统一并明确日志提交规范
  • 传达团队的代码规则、质量基准
  • LGTM(Looks good to me)

    : v2 w+ S/ `  b9 v0 j

( j( H3 D7 B( z$ J方式:
# C$ P5 {4 {9 n1 L" I% s  T& n  H
  • 代码入库前的设计时检查:在设计阶段进行代码审查

    " m+ ?: i, T& ]4 E" d+ P& b4 _
    • 代码入库前门禁检查,需要考虑灵活性,提供绕过机制
    • 代码入库后检查
      4 |9 X. O, r8 ], T  {- r( v
  • 工具辅助的线下异步审查:依赖于Gitlab、Gerrit、Code Climate Engines,一对一审查
  • 面对面审查:架构问题、结对编程
  • 代码增量审查/代码全量审查
  • 团队审查:适合专项讨论
  • 代码审查计入工作量和绩效考评
    ) U% P/ _1 l! [4 J- T5 E
( J0 m4 R2 y) |1 L9 G6 g7 B" \
代码提交规范:
' l+ b9 _2 L: |* H1 r! y
  • 原子提交
  • 提交日志规范
    / X/ `4 G& b( y4 U3 H8 v

6 K5 Q! G$ {4 W" ]/ O' r原则:- c# K# ^3 c' ^  t. G
  • 互相尊重
  • 基于讨论
    ) {, H$ {' B3 O. v* M

3 A# n( ~* p' I5 g, e0 o1 F快速反馈、增量开发

6 Y* K! }% e8 R9 t7 F; q3 }边开发边验证
1 b& [7 b2 b5 E
  • 提高运行静态检查和测试的方便性、灵活性:Maven/Gradle插件
  • 提供沙盒环境方便验证和测试

    & [: X1 e$ H$ D
    • 容器
    • 小范围的增量构建和验证?
    • 测试数据:直接使用生产环境、生产数据的导出并脱敏
      3 s% f+ a5 o7 J4 d
  • 实时检验工具:IDE实时检验、Liveload
    ; m, ~$ M2 E; T1 P* [+ y* ^

% Y/ S9 W, n$ z自动化构建/部署流水部署流水线就是对软件交付流程的建模。
! i! r6 A1 k' Q5 L  J4 N7 K" R
粘贴上传202112251734267920..png

1 t- C0 @" x- b4 ?4 L- Y, {( x1 g' w& c$ L, u
实现部署流水线的一些共识如下:
0 M4 r( Q& w! {) R! ?" d/ u
  • 流水线建设原则

    ) C8 X5 B* @2 e/ }- [( l
    • 测试尽量完整,保证产品质量->完备的测试机制
    • 运行速度够快->尽早反馈、提高交付速度
    • 使用的所有环境尽量和生产环境一致->复现问题

      8 W! o& Y( ^) b; a$ x( ]
  • 所有相关角色提供构建状态可视化:持续交付流水线大屏显示
  • 存储构建结果报告
  • 只要有环节失败,就停止整个流水线!
  • 制品库是特殊的版本控制系统,不需要保存所有版本。
  • 为部署流水线的每个阶段创建脚本:脚本是系统中的一等公民
  • 增量式实现流水线:如果流程中有手工操作部分,就在流水线中为它创建一个占位符。

    " ^, F% c( S% [. [0 f' h5 Z

, E* w* J! I/ P: S7 n) A$ X: Q- [接下来从流水线的各个阶段分别说明。
) j) ~6 X  C3 q8 b2 D% g1 f
提交阶段
* S2 e7 W+ p/ f- |& q# R: N从技术角度上断言整个系统是可以工作的。
* T0 ~! b! V9 I, G5 V( F
  • 编译、单元测试、组装打包、代码分析
  • 少于五分钟,一定不要超过十分钟
  • 提交测试:单元测试、组件测试
  • 只有在某个错误让提交阶段的其他任务无法执行时,才停下来否则就直至提交阶段全部运行完后,汇总所有的错误和失败报告
  • 此阶段的结果:结果报告、二进制包、元数据
    & W% x% @; ]6 M3 t
4 e/ {- ~6 F/ y4 P0 g
自动化验收测试
验证一个用户故事或需求的验收条件是否被满足。针对业务!
% O% c/ U- |& k' R: f6 v" [
  • 配置环境、部署二进制文件、冒烟测试、验收测试
  • 令验收测试失败的构建版本不能被部署
  • 先部署再测试,重用部署脚本。
  • 类生产环境运行验收测试:大部分是功能验收测试,关注功能正确性
  • 开发人员能够在自己的开发环境中运行自动化验收测试
  • 测试的关注点在系统的行为,而非数据本身。所以抵制使用生产数据的备份做为验收测试
  • 验收测试的性能不是主要考虑问题,重点在测试的全面性。
  • 正确地做验收测试:不要幼稚地对照着验收测试条件,盲目地把所有东西都自动化。
  • 验收测试可以看作所有后续测试阶段(包括容量测试)的某种模板:从部署准备开始,然后核实环境和应用程序都已被正确配置和部署,最后执行测试。

    % m; z) v' A1 L  e  ~  B5 A+ h6 r0 E
0 r- y2 _  y) [3 ^' T
后续测试
2 T6 J, {9 p7 L% j0 T' ^
  • 手工测试:探索性测试、易用性测试
  • 非功能测试:性能、安全、可维护、可扩展
    " J) J% X( z; X4 D2 k0 J  b
' f/ x+ {% }: _/ a7 ]
部署发布
4 a- I2 B5 @* z; e( h! }- k9 p  j$ p0 g此阶段的触发不需要自动,测试或者运维人员可以做到自服务即可。& v5 v% N. K8 \, `5 l
  • 对不同环境采用同一部署方式:使用同样的脚本向所有环境部署,包括开发机器
  • 一键式部署是对环境进行修改的唯一途径。
  • 部署测试:对部署进行冒烟测试,验证部署是否成功,证明其部署的可靠性
  • 确保部署流程是幂等的
  • 只有通过了自动化构建、测试和部署的那些修改才能发布!
  • 明确每个环境的部署和发布都是由谁负责
  • 发布计划:第一次发布,产出一些文档、自动化脚本或其他形式的流程步骤
  • 首次部署:首个迭代的主要目标之一就是在迭代结束时,让部署流水线的前几个阶段可以运行,实现部署流水线的“抽水泵”。
      V: _" Z0 M( }! Q
    • 部署流水线的提交阶段。
    • 一个用于部署的类生产环境。
    • 通过一个自动化过程获取在提交阶段中生成的二进制包,并将其部署到这个类生产环境中。
    • 一个简单的冒烟测试,用于验证本次部署是正确的,并且应用程序正在运行。
      + c: Y! o6 J( s# ?
  • 对发布过程进行建模并让构建晋级
    . L, e$ A& s- U3 H4 i- |/ y
    • 为了达到发布质量,一个构建版本要通过哪些测试阶段
    • 每个阶段需要设置什么样的晋级门槛或需要什么样的签字许可。
    • 对于每个晋级门槛来说,谁有权批准让某个构建通过该阶段。

      ) k4 f8 t( u& V6 D4 Y
  • 将每次已通过验收测试的变更版本部署在试运行环境中
  • 紧急修复:紧急修复版本也要走完标准的部署流水线,与其他代码变更没什么区别。

    ' K9 p& K- W6 E  b- L- ?
    • 结对做!
    • 有时候回滚比部署新的修复版本更划算。

      0 e) c4 k# }+ t8 T6 t0 [# a  R
  • 持续部署:每当有版本通过自动化测试之后,就将其部署到生产环境中。【需要依赖强大的自动化测试机制】

    # S4 ~) ?2 l( Z7 Y8 g, @/ [- c
7 o  C' c5 X4 Z- P  V6 z" J& o! a
度量2 e0 @+ c; }3 q; p3 B2 S
每次提交后都产生关于这些度量的报告和可视化效果并保存起来。! H, O" V  ?4 S$ U
  • 周期时间(cycle time),从决定要做某个特性开始,直到把这个特性交付给用户的这段时间
  • 自动化测试覆盖率
  • 代码库特征
  • 缺陷数量
  • 交付速度
  • 提交版本库次数
  • 构建次数
  • 构建失败次数
  • 构建所花时间
    9 B: Q; J' b3 T, M- ^

$ B* Q' _# Y' n( Q; L其他+ J' ^8 [( b+ j- {( N; ~( O
DevOps  k& c6 i3 k# k0 |6 o$ o/ q& a
DevOps是这些年很流行的一个概念,其目的就是打通研发和运维环节,以达到全员目标一致,保障软件高效交付。

8 k* C  s  d9 B" A
粘贴上传202112251735028875..png

% E& C$ v$ \& r3 w4 k2 C% i; q
  • 职能团队提供平台和工具,让全栈工程师能够自己处理端到端的工作,实现DevOps。
  • 全栈开发:工程师不再只是对某一个单一职能负责,而是对最终产品负责。

    3 Y0 o, H9 A4 j! w
( ]0 q2 L8 b4 w* t
信息溯源
1 P/ {. x% g. O- j' y  e1 E6 |打通研发流程中流动的多种标识信息,以方便相关人员快速获取需要的信息,提高工作效率。包括任务工单、代码提交号、版本号、代码审查ID、测试用例ID、Bug ID。
( O% F( c2 X* v0 c
  • 制品与源代码版本管理:放置在制品包中的元数据,体现源代码版本号。
  • 源代码与需求/Bug的版本关联:提交代码时需要在注释里注明需求ID、测试用例ID等。(转自飒然Hang)
    . W& c" @" l. P, l) p5 d6 b, U

8 H% T' F3 a7 Z, }& k) a: W* `# n: i/ u

2 }" t" W; @. G3 F9 `

% o% a# k2 s7 s3 C4 N( n& |" }




上一篇:DevOps 到底好在哪里?这篇文章告诉你了
下一篇:什么?DevOps 已经是哲学啦?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、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-1-20 18:12 , Processed in 0.115009 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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