持续交付发布可靠软件的系统方法（部署流水线）第五章：部署流水线解

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

什么是部署流水线

部署流水线是指软件从版本控制到用户手中这一过程的自动化表现形式。
价值流图

产品可行性评估		产品探索		产品计划与评估		开发		最后测试与审核		发布
3天	1周	7天	10天	10天	10天	3天	7周	1周	2天	2小时

• 开发到发布的流水线：会有很多次构建通过这一流程走向最后的发布
• 流水线各个阶段：
  交付团队->版本控制库->构建和单元测试->自动化验收测试->用户验收测试->发布
• 一般而言，只要某个构建使这个流程任一阶段失败，都会停止，不会进入下一个阶段。
  • 提交阶段【自动化测试（主要是单元测试），代码分析】
• 自动化验收测试阶段【功能与非功能测试】
• 手工测试阶段【对自动化测试的补充，探索性测试，集成测试等】
• 发布阶段【部署到生产环境或试运行环境】

最基本的部署流水线

基本的部署流水线

部署流水线的相关实践

• 只生成一次二进制包。对于不需要编译的语言，二制包指的是所有源文件的集合。这些二进制包应保存在文件系统的某个位置，让流水线后续阶段能够轻松访问到，但不要放在版本控制库中。二进制包应与环境无关。
• 对不同环境采用同一部署方式
  • 使用属性文件保存配置信息。比如分别为每个环境保存一个属性文件，并将其放在版本控制库中，部署时，通过本地服务器的主机名来查找到正确的配置，如果环境中有多台服务器，可以将环境变量提供给部署脚本
  • 将配置放在一个目录服务中（LDAP或ActiveDiretory）或数据库中
• 对部署进行冒烟测试
  当应用程序部署时，应用一个自动化脚本做下冒烟测试。这个测试的流程是：
  • 启动用户程序
  • 检查主页面
  • 检查应用程序所依赖的服务，比如数据库，消息队列等
• 向生产环境的副本中部署
  如果预算充足，可以建立与生产环境一样的环境
• 每次变更都要立即在流水线中传递
  对于一些特殊情况，验收测试是比较耗时的，版本在验收测试时可能会产生冲突，这时可以在单元测试结束时，将最近还没构建的所有变更全部拿来进行构建
• 只要有环节失败，就停止整个流水线

提交阶段

• 编译代码
• 运行一套提交测试【单元测试，容易失败的特定测试】
• 为后续阶段创建二进制包
• 执行代码分析检查代码的健康状况
• 为后续阶段准备工作，比如准备后续测试所用的数据库

自动化验收测试之门

• 每次提交后，应立即运行提交测试，提交阶段完成后，立即做验收测试，简单的验收测试为：运行代码，查看主页
• 尽管验收测试非常有价值，但它们的创建与维护成本也非常高，所以牢记不要把所有验收测试条件盲目的自动化

后续的测试阶段

部署流水线应支持测试人员根据自己的需求将任意一个版本部署到自己的测试环境

• 手工测试
• 非功能测试

发布准备

把发布环节视为部署流水线的一个自然结果

• 让参与项目交付过程的人共同创建维护一个发布计划
• 通过尽可能多的自动化过程最小化人的错误发生的可能性
• 在类生产环境中经常做发布流程演练
• 如果事情并没有按计划执行，要有撤销本次发布的能力
• 作为升级和撤销过程的一部分，制定配置迁移和数据迁移策略

自动部署与发布

• 在具有代表性环境上执行自动化验收测试套件
• 对生产环境的任何修改都应该通过自动化过程完成【程序的部署，配置，软件栈，网络拓扑，状态的所有修改）
• 管理生产环境的流程，也应用于测试环境
• 使用虚拟化技术，最佳配置管理降低成本

变更的撤销策略

• 让旧版本仍旧处于可用状态，保持一段时间
• 从头部署旧版本

实现一个部署流水线

• 对价值流建模，创建一个可工作的简单框架
• 将构建和部署流程自动化
• 将单元测试和代码分析自动化
• 将验收测试自动化
• 将发布自动化
  注意以下几点：
• 增量实现整个流水线，如果有手工操作部分，记录开始结束时间，想办法把它自动化
• 部署流水线是构建、部署、测试和发布整个流程中有效，也是最重要的统计数据来源
• 不断改进部署流水线

度量

最重要的全局度量指标是流水线周期时间。用约束理论来对流水线进行优化：

• 识别系统中的约束
• 确保最大限度地提高流程中这部分的产出
• 根据这一约束调整其他环节的产出
• 为约束环节扩容，增加资源
• 理顺约束环节，找到下一个约束点