|
本帖最后由 陈小宝 于 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
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: u5 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 项方法,看完这篇就够了
|