×

《持续交付-发布可靠软件的系统方法》读书笔记-持续集成

96
通爸
2017.11.25 22:07* 字数 1371

《持续交付-发布可靠软件的系统方法》全书51.2万字,15章,384页。本次阅读第三章持续集成,大概42页。

持续交付

持续集成最早出现在Kent Beck写的《解析极限编程》一书中,主要思想:既然经常对代码库进行集成对我们有好处,为什么不随时做集成呢?《持续交付》第三章主要讲述如何实现持续集成。

在本书中,对持续集成的定义如下:持续集成是一种软件开发实践。在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以多次。每次集成会经过自动构建(包括自动测试)的检验,以尽快发现集成错误。自从在团队中引入这样的实践之后,Martin Fowler发现这种方法可以显著减少集成引起的问题,并可以加快团队合作软件开发的速度。

1、实现持续集成

1.1 准备工作

1.版本控制

使用SVN或者git免费工具可以进行版本控制。

2.自动化构建

有以下理由持续推进自动化构建:

- 能够在持续集成环境中以自动化的方式来执行整个构建过程,以便出现问题时能够审计。

- 应将构建脚本与代码库同等对待。应该对它测试,不断重构,以便使它保持整洁且容易理解。

- 使理解、维护和调试构建过程更容易,并有利于和运维人员更好的协作。

3.团队共识

团队认同:“修复破坏应用程序的任意修改是最高优先级的任务”。

2 持续集成的前提条件

2.1. 频繁提交

2.2 创建全面的自动化测试套件

三类测试在持续集成构建中使用:单元测试,组件测试和验收测试。

将验收测试按照功能模块分组通常是可取的。这样,当仅修改了系统中的个别模块功能时,就可以单独运行影响系统这部分功能的验证测试。很多单元测试框架都是提供这样的分组功能。

2.3 保持较短的构建和测试过程

2.4 管理开发工作区

三点:1)细心的配置管理 ;2)对第三方以来的配置管理 ;3)确保自动化测试在开发机可以运行。

3 使用持续交付软件

3.1 基本操作

两个部分:每隔一段时间周期运行一次工作流程;提供展示运行结果的视图。

3.2 铃声和口哨

失败可以用灯等设备提示,可以在流程加入圈复杂度,重复代码,静态检查等环节。

4 必不可少的实践

持续集成是一种实践,不是一个工具,他的有效性依赖于团队纪律。

4.1 构建失败后不要提交新代码。

4.2 提交前,在本地运行所有的提交测试。或者让持续集成服务器完成此事。

功能:预测试提交,个人构建。

4.3 等测试提交通过后再继续工作。

4.4 回家之前,构建必须处于成功状态。

4.5 时刻准备着回滚到前一个版本

4.6 在回滚之前要规定一个修复时间

4.7 不要将失败的测试注释掉

4.8 为自己导致的问题负责

4.9 测试驱动的开发

5 推荐的实践

5.1 极限编程开发实践

重构作为高效软件的开发基石。持续改进和测试驱动开发让TDD成为可能。

5.2 若违背架构原则,就让构建失败

5.3 若测试运行变慢,就让构建失败

5.4 若编译告警或代码风格问题,就让测试失败

6 分布式团队

6.1 对流程的影响

信任很重要,同时视频会议相互了解功能和进展。

6.2 集中式持续集成

集中式的持续集成是一种双赢的实践。

6.3 技术问题

推荐Git

6.4 替代方法

两个方式:分解系统为多个组件;使用分布式版本控制系统

7 分布式版本控制系统

介绍github的设计思想。

小结:

总之,一个好的持续集成系统是基石,在此之上你可以构建更多的基础设施:

--一个巨大的可视化指示器,用于显示构建系统所搜集到的信息,以便提供高质量的反馈;

- 结果报告系统,以及针对自己测试团队的安装包。

- 为项目经理提供关于系统质量的数据报告

- 使用部署流水线,可以将其延展到生产环境,为测试人员和运维团队提供一键式部署系统。

读书笔记
Web note ad 1