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

软件构成部分：可执行的代码、配置信息、运行环境、数据

  • 不同环境下只进行一次编译
  • 对环境的任何修改都应该作为配置信息管理，配置信息的更改都需要经过测试
  • 如果运行环境需要修改，则修改后的环境也需要进行测试。环境包括：操作系统配置、应用程序依赖的软件集、网络配置及任何基础设置、外部系统
  • 数据结构发生变化，同样需要经过测试

反馈流程：指完全以自动化的方式尽可能地测试每一次变更

  • 创建可执行代码的流程
  • 单元测试
  • 质量检测：测试覆盖率以及其他与技术相关的度量项
  • 功能测试验收
  • 性能、有效性、安全性等非功能测试
  • 探索性测试，给客户/最终应用演示

自动化测试反馈

【commit阶段】

  • 运行速度快
  • 尽可能全面，75%代码库覆盖率
  • 环境中立，相对生产环境简单廉价
  • 如果出现问题，绝不发布
    【commit之后测试】
  • 运行速度慢一些，适合并行执行
  • 即使有些测试问题，也可以发布应用程序
  • 运行环境尽可能与生产相同

不同版本、不同环境的配置放在版本控制中

  • 开发人员都拥有自己的专属开发环境
  • 无论部署在什么目标环境都应采用同一种部署方法
  • 开发环境是特例，可以有多变性部署方法

软件的交付原则

  • 为软件的发布创建一个可重复且可靠的过程
  • 将几乎所有的事情自动化（构建、部署、测试、发布）
  • 把所有的东西都纳入版本控制（需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、数据库创建、升级、回滚和初始化脚本、库文件、应用程序依赖的软件集、工具链及技术文档等)
  • 找到流程中最痛苦的事情，并提交频繁地进行：如果集成最痛苦，那应在开始阶段就不断进行集成、测试；如果发布痛苦，每次提交并通过自动化测试后就进行发布
  • 用户故事只有到了已发布才算完成，交付成果属于每个成员，交付前每个成员都为其负责
  • 持续改进，交付过程中，整个团队召开回顾会议，提出改进方向及方法，每个改进点应该同一个人负责跟踪，确保改进被执行，下一次回顾会议，汇报结果。