持续交付：发布可靠软件的系统方法

 1.书籍介绍

 

 

 

2.笔记

2.1 软件交付问题：

• 部署流水线：应用程序 构建->部署->测试->发布，自动化。
• 常见反模式：①手工部署软件 ②开发完成后才向类生产环境部署 ③生产环境的手工配置管理
• 软件发布应是一个低风险、频繁、廉价、迅速且可预见的过程
• 周期时间：从决定变更的时刻开始，直至用户可以使用本次变更的结果
• 快速交付：验证新特性或修复缺陷是否真的有用，在使用者真正使用前，全是未经验证的假设
• 质量≠完美
• 每次修改都要应该触发反馈流程
• 将几乎所有的事都自动化
• 把所有东西都纳入版本控制：一个新成员可以在新电脑前直接迁出所有代码并成功编译
• 提前并频繁的做让你痛苦的事
• 持续改进
• 将所有的事都自动化
• 尽快的交付可工作的软件
• 自动化的好处：①高效 ②减少人为失误 ③自由度高，随时可部署 ④控制成本

2.2 配置管理

• 配置管理是指一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一定义、修改、存储和检索。
• 对所有内容都进行版本控制
• 频繁提交代码到主干(不用分支)
• 使用分支的问题：1.违背了持续集成的宗旨，推迟了新功能的整合。2.如果多个开发者分别创建了多个分支，合并过程会极其复杂。3.自动合并功能无法解决所有问题(如：语义冲突)。4.让重构更困难。
• 放置提交代码时破坏已有应用：1.提交前运行测试套件。2.增量式引入变化。
• 使用意义明显的提交注释。
• 应始终指定项目所需的外部库的确切版本。
• 组件依赖应是二进制依赖。
• 为配置信息建模
• 环境管理的两个基本原则：1.将二进制文件与配置项分离。2.将所有的配置信息保存在一处。
• 对环境的变更过程进行管理

2.3 持续集成

• 持续集成的准备工作：1.版本控制。2.自动化构建。3.团队共识。
• 持续集成的前提条件：1.频繁提交。2创建全面的测试套件。3.保持较短的构建与测试过程。
• 管理开发工作区。
• 构建与测试失败后不要提交新代码。
• 提交前在本地运行所有的提交测试。
• 回家之前，构建必须处于成功状态。
• 构建失败后，规定一个修复时间，若时间内未成功修复，则回滚。
• 不要注释失败的测试，要不修复代码，要不修复测试，要不删除测试(功能不存在)。
• 最后一个构建失败的人对本次失败负责，哪怕错误出现在其他模块。
• 测试驱动开发。
• 若有编译警告或代码风格问题，就让测试失败。
• 保持一个清晰的开发环境
• 如果影响到其余团队成员，则必须在短时间内解决村务，或回滚