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

提交阶段的运行应该少于5分钟，一定不要超过10分钏
提交阶段的首要目标是创建可部署的产物

提交阶段的原则与实践

• 提供快速有用的反馈
• 何时令提交阶段失败
  • 编译错误
  • 测试失败（包括单元覆盖率低于60%）
• 精心对待提交阶段
  • 提交阶段中有构建用的脚本和运行单元测试、静态分析等脚本。
  • 随着项目的进行，不断改进提交阶段的脚本的质量、设计和性能
  • 确保将脚本做成模块化，将那些经常使用且很少变化的常见任务与需要修改的任务分开
  • 将部署流水线中不同阶段所用的代码分别写在不同脚本中
  • 不要写出与具体环境相关的脚本，即要把具体环境配置与构建脚本分离
• 让开发人员也拥有所有权
  如果必要的话，即使是很普通的变更也都应该由开发人员和运维人员来执行
• 在超大项目团队中指定一个构建负责人
  • 监督和指导对构建的维护
  • 鼓励和加强构建纪律
  • 在团队开始接触持续集成时，构建纪律还没建立起来时，提醒作用
  • 团队成员轮流当，比如每星期轮换一次

提交阶段结果

提交阶段的输入是源代码，输出是二进制包和报告（测试结果和代码分析报告）

制品库

• 制品库仅保存某些版本，而不是全部。如果在部署流水线某个阶段失败，就可以删除该版本
• 制品库中的二进制包能够追溯到具体的代码版本控制库中的版本
• 良好的配置管理策略，二进制文件的构建过程应该是可重复的

提交测试套件的原则与实践

• 提交阶段，测试绝大部分应由单元测试组成
• 设计 能够快速运行的提交测试策略
• 运行的单元测试不应该与文件系统、数据库、库文件、框架或外部系统等交互

提交测试实践

• 避免用户界面
• 使用依赖注入
• 避免使用数据库
  单元测试不应该依赖于数据库，需要把测试的代码与其存储分离开来。这就要求代码实现良好的分层，也需要使用依赖注入。如果实在无法做到，使用内存数据库
• 避免异步
• 使用测试替身
  模拟技术工具集：Mockito、Rhino、EasyMock、JMock、NMock、Mocha等
• 最少化测试中的状态
  降低要构造的测试环境的复杂性
• 时间的伪装
  对于那些需要确保一定延时或者定时的行为，需要对其中的时间系统进行控制。作者团队的经验是，只要代码中需要使用时间，就会抽象到对系统时间服务的请求，而不是直接在业务逻辑中调用它们
• 蛮力（测试阶段运行应该少于5分钟）
  • 将提交测试分成多个套件，在多台机器上并行执行（构建网格）
  • 作为构建优化过程的一部分，将那些运行时间长，且不经常失败的测试放在验收测试阶段