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

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

提交阶段的原则与实践

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

提交阶段结果

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

制品库

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

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

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

提交测试实践

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