【读书笔记】持续集成（软件质量改进和风险降低之道）之一

[SiZapPaaiGwat]

持续集成（软件质量改进和风险降低之道）

第一章 启程

每天吃一个苹果和实际去做是两码事。 by Kathy Sierra

1.1 针对每次变更构建软件

一次构建不止是一次编译。它可能包含编译、测试、代码审查和部署以及其它一些事情。一次构建是将源代码放在一起，并验证软件可以作为一个一致的单元运行的过程。

CI场景中的步骤通常是这样的：

1. 开发者提交代码到版本控制库，CI服务器轮询检查代码变更；
2. CI服务器取出最新的源代码执行构建脚本，对软件进行集成；
3. CI服务器向指定的成员发出电子邮件，提供构建结果的反馈信息；
4. CI服务器继续轮询检查代码变更。

通过一次构建，开发团队可以回答以下问题：

• 软件组成部分是否能协同工作？
• 代码复杂度如何？
• 是否坚持了制定的编码标准？
• 自动测试覆盖了多少代码？
• 是否成功的通过了所有测试？
• 应用程序是否满足性能要求？
• 最近的开发是否存在问题

你之所以希望“持续”地构建，就是为了得到快速的反馈。这样能在开发生命周期找到并修正问题。

1.2 CI的特征

CI需要具备的特征

• 与版本控制库连接
• 构建脚本
• 某种类型的反馈机制（通常是邮件）
• 集成源代码变更的过程（CI服务器）

CI的子过程：

• 源代码编译
• 数据库集成
• 测试 （没有自动化的、持续的测试的CI不能算是CI）
• 审查 （自动化代码审查通过强制遵守规则来增加软件品质）
• 部署 （任何时候都可以拿出能工作、可部署的软件）
• 文档与反馈

一个好的CI系统的关键特征就是“速度”。CI系统的本质是及时向开发者和项目风险承担着提供反馈信息。

第二章 引入持续集成

假定是所有麻烦之母

• 假定一个方法会得到正确的调用参数
• 假定开发者会坚持编码标准
• 假定配置文件不会被覆盖或者修改

持续集成在每次版本控制系统发生变化时就执行构建，这有助于减少项目中的假定。 CI是一些基本实践。它不是软件开发中最炫目的工作，不会有用户说“哇，我真的喜欢你们上一个版本的集成方式”。它是软件开发的幕后工作，只有使用过CI的人才能体会到一致的、可重复的构建过程所带来的好处。

检查软件的品质就是检查最新的集成构建，就这么简单！

2.1 CI生活中的一天

无

2.2 CI的价值是什么

• 减少风险
• 减少重复过程
• 在任何时间地点生成可部署的软件
• 增强项目的可见性
• 对开发团队的软件建立起更强大的产品信心

减少风险

• 缺陷的检测和修复变得更快
• 软件的健康程度可以测量
• 减少假定

增强项目的可见性

• 对当前构建状态和品质指标提供及时的信息
• 观察到一些项目相关的趋势

建立更强大的产品信心

• 如果没有频繁的集成，团队成员会感到压抑，因为他不知道代码的修改所造成的影响。比如罚款！

2.3 什么阻碍了团队使用CI

• 增加了维护CI系统的开销（项目太复杂、额外工作太多）
• 变化太大（增量实现，从日构建开始）
• 失败的构建太多
• 额外的硬件/软件成本

2.4 如何进行持续集成

• 确定：确定需要自动化的过程（编译、审查、测试、部署、数据库集成）
• 构建：创建构建脚本
• 分享：利用版本控制库让其它人用起来
• 持续：在变更之后执行自动化的过程

2.5 项目应该再何时以何种方式实现CI

• 越早越好，越晚越拒绝改变。
• CI最终希望是在每次代码库变更时就执行构建，但是也可以从每日构建开始。
• 早起可以不加入某些功能，比如自动化的回归测试

2.6 集成的演进

它不是突然冒出来的软件开发方法，是集成软件演进的成功。

2.7 如何与其它开发实践配合

• 单元测试
• 编码标准
• 重构
• 小发行版本
• 共同拥有代码，避免知识孤岛

2.8 CI需要多少时间架设

2.9 CI与您

七项最佳实践：

• 经常提交代码（每天至少一次）
• 不要提交无法构建的代码（不能编译、无法通过测试、代码审查失败）
• 立即修复无法构建的代码（优先级最高）
• 编写自动化的单元测试
• 必须通过所有测试和审查（不是90%或者99%，而是100%）
• 执行私有构建（先在本地构建成功）
• 避免签出无法构建的代码（等待新的变更或者帮助修复无法集成的构建）

[SiZapPaaiGwat]

为了避免多处同步的麻烦，如果需要查阅最新版本，请前往https://dataeye.quip.com/zTYkArfufnIh

[Thinking80s]

还有后续持续集成文章吗？

[SiZapPaaiGwat]

@Thinking80s 还有很多 :smile_cat:

[Thinking80s]

继续学习！